Community
Participate
Working Groups
Place a break point in some class and run it so that you have a thread suspended in the debugger. Open up some other .java files Select text in one of the .java files Note that in the editor of this other file, Inspect, Disply and Run to line are enabled. Likewise in all the .java editors Note that Inspect and Display generally do not do much, typically just stating that the field name could not be resolved. But run to line triggers an action, it causes the selected/suspended thread to run even if you are not in the right editor. NOTES: EG (6/14/2001 7:34:42 AM) the enabling state currently only checks that there is a debugger context. Not critical moving to DUI. DW (6/14/01 12:50:53 PM) Deferred. DW (8/15/01 9:55:57 AM) Duplicate of 1GF7DEK: ITPJUI:WINNT - contextmenu entries do not disappears in editor after snippet evaluation (Closed Dup).
The Run to Line action needs to stay enabled in all circumstances, since there's no way of predicting whether the current cursor location will in fact be encountered in the course of the current execution.
Fixed. Display & Inspect actions in both editor context menu and in Display View are more selective in their enablement. In DisplayView, actions are enabled only when a stack frame is selected in DebugView, and there is a valid selection in the DisplayView. Actions in editor are enabled when there is a valid selection in editor and the editor's input matches the input for the currently selected stack frame. There is currently one case when enablement is incorrect. In DisplayView, if actions are enabled, then stack frame is DE- selected, actions are still enabled. This is because it seems like overkill to have the actions or the DisplayView be a selection listener on the DebugView, which is the only they could could be disabled.
Fixed.
PRODUCT VERSION: 123
I can no longer do evaluations in the display view. I continually get the message "No Java source element context". Test case: * Launch VectorTest with a breakpoint in #testCapacity * When breakpoint is hit evaluate "fFull.size()" in the display view or java editor * error dialog appears
re-assigning to JS.
E-mail from Joe: "Debugging this, it seems that the problem is in EvaluateAction.run() on the call to getJavaElement(stackFrame). This is returning null because the sourceElement found by the source locator is a CompilationUnit, not an IType. Because the java element is null, you see the error dialog. This was working when I finished the work to properly enable the eval actions a couple of days ago. What has changed?" The source locator changed. I fixed up the method #getJavaElement(stackFrame) to return any java element associtated with the stack frame - type, CU, or class file. The method was spec'd to return an IJavaElement, not a Type, so I'm not sure why it was being so specific. I also found that code assist was not working in the display view because it was expecting a type back from the source locator, but wanted a compilation unit. So it too is fixed up. please verify
Verified. Both DisplayView evaluation & code complete are now working.
