Community
Participate
Working Groups
The Debug tab of the launch configuration is repainted multiple times unnecessarily. This causes a flicker and unnecessary delay. From what I can tell from the source, here is the cause: Render #1: The method org.eclipse.cdt.launch.ui.CDebuggerTab.activated() calls "super.activated()", which renders the Debug tab fully. Render #2: The CDebugTab.activated() method then immediately invokes "loadDebuggerComboBox()" without first checking if this call is unnecessary. This call invokes "fDCombo.select()" which fires an event that causes "ModifyListener" to invoke "updateComboFromSelection()". This method indirectly calls AbstractCDebugTab.handleDebuggerChanged(), which re-generates the Debug tab again! Render #3: After "loadDebuggerComboBox()" invokes "fDCombo.select()" it redundantly invokes "updateComboFromSelection()" explicitly! This throws away the previous rendering and regenerates the Debug tab yet again! I don't know the code that well, but it seems like CDebugTab.activated() should not invoke "loadDebuggerComboBox()" unless the "id" has changed. And "updateComboFromSelection()" should be removed after the call to "fDCombo.select()" in CDebugTab.loadDebuggerComboBox(), since the ModifyListener already invokes it.
Deffered.
Created attachment 13668 [details] Patch to reduce the number of repaints of Debugger Launch tab Attached is a copy of the latest CDebuggerTab.java file (from plugin org.eclipse.cdt.launch), with some changes to correct this problem (or, at least reduce the number of repaints). Basically, it remembers the ID of the debugger whose launch dialog is being rendered, and avoids unnecessarily invoking "loadDebuggerComboBox" if the ID has not changed. With this fix, you can select the Debugger tab of the Launch dialog without the tab being re-generated.
Thank you. The Debug tab of the launch configuration dialog currently has bugs and needs changes. I am planning to look at it in the near future and I will use your suggestions and comments.
Fixed. Comment: the render#3 is needed because on some platforms (Motif) fDCombo.select doesn't fire a modification event.
Such a difference in the behavior of combos between SWT ports seems significant. Shouldn't this be reported as a bug in SWT if it hasn't been already?
reopening to assign
putting back
