Community
Participate
Working Groups
EG (1/24/01 9:46:25 AM) "Open on Selection" support in Console View. The console can show references to resources in the case of a walkback. An open on selection command would allow to open the referenced resource. java.util.MissingResourceException: Can't find resource for bundle java.util.PropertyResourceBundle, key Editor.GotoLine.dialog.title at com.ibm.eclipse.ui.editors.text.GotoLineAction.actionPerformed (>>>>>GotoLineAction.java:69<<<<<<) Open On Selection with "GotoLineAction.java:69" will open an editor on GotoLineAction. NOTES: EG (1/24/01 9:57:02 AM) low priority DW (3/15/01 10:50:59 AM) Could be done with an #editorAction that is dynamically contributed by Java Debug UI. JGS (9/25/01 1:51:22 PM) The implementation of OpenOnSelectionAction depends on internal classes in JDT core via the ICodeAssist interface (which only ClassFile & CompilationUnit implement). Thus there is no obvious path to add this functionality to the ConsoleViewer. JGS (10/4/01 10:38:46 AM) Response from EG: I wouldn't stick to the OpenOnSelectionAction it is based on code select and code select is only helpful inside Java code. Let's assume that this is the output in the console: package.SomeType.someMethod(SomeType.java:89). what does the user have to select to do a Go To (file)? Is it enough to put the cursor on the line and you parse the "SomeType:89" or do you want to use the qualifed method name for navigation. If you go for the file name then you can use the workspace API to find the resource with the name. If the file name is ambigous show a dialog and open the editor via the workbench API. Finally use the ITextEditor API to reveal the line. If you go via the fully qualified type name you can use the search engine and look for a type with the given name (see AllTypesSearchEngine for an example) find the matching package and open the IJavaElement. You can give the search engine the package as a scope to constrain the search.
Have experimented with both approaches outlined, and decided using the java SearchEngine is prefereable to hunting for resources. Within this choice there are several options on how to use the SearchEngine. Decided to use the 'searchAllTypeNames()' method, as this had somewhat better performance than the others.
Implemented. If there is an explicit selection in the console, this is parsed for a package, type and line number. If no selection, the entire line in the console where the cursor is located is parsed. In either case, the package name and line number are optional, the type name is required. In ambiguous situations (e.g., "List" is selected), a selection dialog is opened.
Verified that open on type works in positive cases. Problem I noticed is that if the selection cannot be resolved to a type, then nothing happens, and there is no warning/message. Options are to pop up a dialog, or open an "open on type" dialog (a la toolbar), with an initial selection of whatever was selected. For example, I selected "main" in the conosle and did an open on type and nothing happenned. Instead, could open the "open on type" dialog, and populate the text field with "main". Thoughts?
My thought was that the normal use of this action was with NO selection. I.e., simply place the cursor on a line of output in the console and then choose 'Open on Type' from the context menu. The action will parse the entire line and in the case of a standard Java walkback (and a few other cases), it will 'do the right thing' and open an editor on the referenced type. I only included an option to look at explicit selections because it seemed somewhat useful in the case where a programmer outputs a class name as a debugging aid, and then decides to open that class. 99% of the time, I think such a selection will be done as a double-click, which should select the type correctly, if there are separators around the name. I do see the potential for confusion though and will investigate the suggested fix.
After thinking about it a bit, I'm not sure that bringing up a dialog in the case that no type can be resolved for the 'open on type' action is a good idea. There are two cases: (1) An explicit selection was made, but it was a bad selection that didn't actually get the desired type name. The selection probably missed the desired type name by one or two characters on the beginning or end. If it differs on the end, then bringing up a dialog seeded with the selection probably would save the user a few keystrokes, but if it differs on the beginning, then using the selection as a seed for the dialog is actually not at all what the user wants, and will cause them to have backspace out the initial value, or start over. (2) There is no explicit selection, so the action attempts to parse the entire line. If it cannot parse a valid type out of the line, then the line is not part of a standard Java walkback, in which case we have no idea what it is. In this case, seeding the dialog with the entire line would probably result in nonsense. In general, we could avoid seeding the dialog, but then this is just the same as invoking the standard toolbar action to open a type. I can see that there might be some benefit in having the action try its best to parse a type name and open it, but in case of failure default to asking the user to choose a type from ALL of the types in the workspace. But, is this desireable behavior?
Will leave action as is for now. Fixed.
Verified.
