Community
Participate
Working Groups
If I have a long list of variables displayed in the variables view, I should be able to press the first character of the variable I want to select, and have the Tree move the selection to that item. This has regressed in 3.2 and only works if the item is visible. I'm guessing the other items have not been created and therefore can't be searched. This is especially annoying when digging deep into an object, for example, part, "P" for parent, "RIGHT_ARROW" for expand, "P" for parent, "RIGHT_ARROW", "C" children, etc.
We're using a virtual tree, so the labels do not exist. You can use "Find" to search for a variable. Deferred
Please consider for 3.2.1. Is there any way the user can turn off the virtual-ness? Do you really need to use a virtual table, or is it just the second column that needs to be lazily populated?
All the debug views (debug, variables, expressions, registers...) use async virtual technology in 3.2. Communication with the debug target is performed in non-UI threads to avoid blocking the UI if the target becomes unresponsive. We use virtual views to minimize interaction with the target (i.e. retrieving 5000 variables when only 20 are visible). There is no option to turn off the virtual behavior.
Strange, I never noticed any issues with debugging before 3.2. It was always very responsive. And "blocking" the UI was desirable. For example, if I press F6, F6, F5, debug should step over twice and then step into. In 3.2, the behavior is random. Some of your keystrokes just get eaten if the debug thread has not completed processing the previous request. There doesn't seem to be any visual clue as to when the previous one completes. The overall debug experience in 3.2 seems slower IMO. Steve, do you know if there is a common workaround in virtual widgets when the user tries to search for an item? Perhaps items should be realized (by SWT) until a match is found, or the client should hook the key event and perform the search then set selection in SWT?
>Perhaps items should be realized (by SWT) until a match is found ... We can't do this or the entire tree would be realized. The client code needs to do the search or we need to add API to tree and table so that they can implement the search and override the default operating system search. None of this is happening for 3.2.
I don't understand why the SWT.VIRTUAL style is being used at all. The benefit of a virtual widget is to avoid the overhead of creating 10s of thousands of items. In this case, the number of items is relatively small. Also, you obviously have the interesting text available for the children because the items are being sorted alphabetically. So what is the reason that you don't just go ahead and create all of the items and set an initial string? This would solve the problem. If you want to lookup values for primitives or invoke toString() on objects lazily, this can still be done without the use of virtual. Please restore the 3.1 behavior in a maintenance release.
Sorry Randy, this is not going to be restored. This was the major work item for debug in 3.2. Many debuggers have to support 1000's of variables. See the top level plan: Enhance the debug platform. The debug support in Eclipse is increasingly being used in areas that require more flexible mechanisms than those required by simple Java programs. Features will be provided as provisional API subject to change in a future release. Features include: a flexible element hierarchy in debug views to account for different architectures such as multi-core processors, thousands of threads, etc; asynchronous, cancellable interactions when retrieving view content and labels; model driven view updates; a debug context service allowing for retargettable debug actions, flexible view wiring and pluggable source lookup. [Debug] (106205) [Theme: Design for Extensibility, Enterprise Ready]
Please point me to the relevant classes/objects that make up the contents of the tree. I will see if I can provide a patch.
You can start here: AsynchronousViewer.java AsynchronousTreeViewer.java AsynchronousTableViewer.java You'll find that our viewer hierarchy and associated classes were designed to be asynchronous/virtual. It's not a one line patch.... we'd need the ability for a debug model to turn the virtual behvaior on/off dynamically. The views are shared all debuggers, and just because you want virtual "off", doesn't mean others do.
In the mode where you display columns, isn't the first column always available without going back to the running VM and asking for the string? In other words, knowing the "variable name" is cheap, while getting its value for the second column could by done using the background job LabelRequestMonitor. > Many debuggers have to support 1000's of variables. Creating 5000 treeitems does not take very long, and might be faster if SWT grew their treeitem[] by percentages instead of 4. You could create the items up front and call setText(String[]) with an initial version of the string(s), or only the first column in column mode. Then, go back and update the string(s) as you are already doing, just for the items that are visible. On AsychronousLabelAdapter, you could add a new method getQuickLabels() or getSimpleName().
The concern is not about creating widgets/tree items. The concern is the round trip to the debug target to retrieve each label. It can be over a latent connection. It could be a remote embedded target that is slow (compared to a local workstation). Getting "quick" labels is not something that all debuggers can do.
> The concern is the round > trip to the debug target to retrieve each label. It can be over a latent > connection. It could be a remote embedded target that is slow (compared to a > local workstation). Getting "quick" labels is not something that all debuggers > can do. Certainly debuggers that sort their variables alphabetically can support this. So, my suggestion was to provide two versions of the labels, one that is readily available (and worst case that is the empty string), and one that requires a background thread to connect to the runtime. If a debugger does not support "quick" labels, then the behavior is identical to the current 3.2 behavior. i.e., The item appears blank until the string becomes available and the UI job updates the item's label. Instead of using a virtual tree and listening for SetData event, you could use a normal tree, set the quick labels, then listen for EraseItem event and update the labels for items whose EraseItem event has been sent.
Randy, might I suggest that you defer discussions about redesigning components to after 3.2 ships?
Agree with Steve. This is not a stop ship. Randy if you care about this, I would suggest prototyping a solution and providing it as a patch for discussion post R3.2.
Reopening for maintenance or 3.3 stream. This bug is quite frustrating in day-to-day work. Here's a scenario from this morning. Let's say I'm looking at: this= ActionControlEditPart (id=6799) accessibleEP= GraphicalEditPart$4 (id=6805) children= null editableEditPart= DefaultEditableEditPart (id=6801) editingDomain= DiagramEditingDomainFactory$Diagram... elementGuid= null eventListeners= EventListenerList (id=6802) figure= SketchLabeledIcon (id=6803) flags= 0 isResizable= true listenerFilters= null model= ButtonImpl (id=6806) parent= DiagramEditPart (id=6725) policies= Object[8] (id=6804) selected= 0 sourceConnections= null targetConnections= null Then, I expand the treeitem for "Model", and press char P to navigate to the field called "previous" underneath the expanded item "model". What actually happens is that I am scrolled past that location to the field "policies" (sibling to "model"). And even funnier is that "previous" is now scrolled into the visible client area, even though it wasn't selected like I expected. The client area now displays: eContents= EContentsEList (id=6831) eCrossReferences= ECrossReferenceEList (id=6832) eFlags= 257 element= null eProperties= null eProxyURI= null id= "ButtonX" label= "" labelESet= false layoutConstraint= BoundsImpl (id=6836) navigationRules= null persistedChildren= null previous= ButtonImpl (id=6862) <<---NOT selected! sourceEdges= null styles= EObjectContainmentEList (id=6841) targetEdges= null transientChildren= null type= "Button" parent= DiagramEditPart (id=6725)<<---SELECTED----
changing "regression" --> "lost function".
Over the course of 3.3, we're investigating the use of standard JFace viewers displaying an "asynchronous model". The use of the standard viewers should restore this lost function.
Please add "depends on" for the JFace async work if there is some feature request tracking that function. If JFace also uses SWT.VIRTUAL, the problem won't go away, unless JFace re-implements character searching done by the OS. Since debug view has both a short and long version of the treeitem's text, you guys are in a special position to not use Virtual Tree, and just use a normal tree that refines the treeitem's text when it becomes visible to the user. And maybe this is so common that JFace already intends to implement this approach of initial text vs. "eventually-displayed" text.
Will add dependancy when the top level work item appears.
i agree with randy, This is quite annoying that this doesn't work anymore. What i don't get is that you have functionality to do exactly what i want. For example if i press CTRL-F then type the variable and then press enter, i am in on that variable in the view, why can't that behaviour (opening that dialog) not be hidden away but used when i type in the tree? Just call the exact method that the ok button does? Only one thing should then be taken into account i believe and that is the start position where you are now, so only fill the list where you search through with the variables after the selection.
(In reply to comment #20) > What i don't get is that you have functionality to do exactly what i want. > For example if i press CTRL-F then type the variable and then press enter, i am > in on that variable in the view, why can't that behaviour (opening that dialog) The problem here is the unnecessary usage of the VIRTUAL style. The model is not virtual, it is completely available, and small (<10,000), so creating TreeItems is not a performance issue. The only part that is "virtual" is the extra information that must be queried asynchronously. This could be done using the SWT.EraseItem event callback instead of SWT.SetData.
There appears to be different behavior on different platforms. On linux, when you type in a tree viewer, a popup appears at the bottom of the viewer for text entry that seems to search the tree. However, this does not appear in the variables view either (perhaps because it is a vitrual view?).
>This could be done using the SWT.EraseItem event callback instead of >SWT.SetData. Seems bogus and possibly wrong. NOTE: A search window should not pop up on GTK. If it does, it's wrong.
(In reply to comment #23) > >This could be done using the SWT.EraseItem event callback instead of > >SWT.SetData. > > Seems bogus and possibly wrong. NOTE: A search window should not pop up on > GTK. If it does, it's wrong. What is bogus about using EraseItem to detect that column 2 of a table is about to be painted? If the performance hit is in retrieving columns 2's value, why delay the population of column 1 for no reason?
*** Bug 198885 has been marked as a duplicate of this bug. ***
Marking as won't fix. This feature inherently does not work in virtual views (similar to sorting, etc.). The work around is to use the Find action. This translates to some more key strokes: Ctrl-F,<letter>,Enter.
