Community
Participate
Working Groups
1. Create and build new C project. 2. Create new launch config, using "C/C++ Local Application" type. 3. Observe that project and binary were defaulted. Also observe that "Apply" button is grayed out. 4. Switch to debugger tab. Observed behaviour: the Apply button becomes enabled. Expected behaviour: since I did not actually change anything, Apply button should remain disabled. This bug appears to be related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=284251 in that missing call to setDefaults for the debugger page causes some things, like name of debugger, to be not saved in the launch config. Then, after switching to a new tab, performApply on that tab is called, which saves the default name of debugger, "gdb" that initializeFrom used. Therefore, the configuration now differs. I am filing this separately because there are different ways of fixing 284251 and some of them might leave this one still unfixed.
In fact, it seems to be now that no easy fix 284251 will fix this one, and here's why. When a new configuration is created, we call setDefaults for all tabs. At this point, the tabs exists, but UI for them does not. The dynamic tab for the chosen debugger is not created yet. So, while the initial configuration might contain the selected debugger id, it cannot contain any default options for it. When this newly created configuration is loaded via initializeFrom, loadDebuggerCombo sets the debugger combo index to the right value, and then creates page specific for that debugger and then calls setDefaults on it. At this point, the configuration shown by the UI is no longer equal to what setDefaults created, so the Apply button is enabled. The right solution would be to make setDefaults create a complete default config, including options for the selected debugger. Right now, it does not seem possible, because the page is not created yet, and even the debugger combo is not created yet, so the solutions are either: 1. Create enough of UI before calling setDefaults 2. Move initialization of defaults into an UI-independent "Model" class