Community
Participate
Working Groups
3.6 and latest builds. 1. start with new workspace 2. set Launching preference to always launch the previous one 3. start an Eclipse workbench 4. immediately start a second one ==> 'Workspace Cannot Be Locked' dialog is not brought to front and hence not seen by the user. NOTE: Sometimes this works.
The two dialogs are just looking similar, but they are completely different. A) - You quickly launch twice with the same workspace - When the host Eclipse launches the second runtime instance, the first instance did not yet lock the workspace => PDE doesn't detect a conflict => The second runtime's launcher shows a dialog "Could not launch the *product* ..." => That dialog has the splash screen as parent and does not come to front when you clicked into the host window again after launching B) - You only launch the second instance after the first one is up and running => PDE detects that the workspace is already in use *before* launching the second instance => You get a dialog "Could not launch the *application* ..." with the path to the workspace and (since I20101206-1800) with the Edit... button. I don't think there's anything to do in the launcher, but PDE could be made smarter: It could fill the gap between launching and the creation of the workspace lock, e.g. by keeping a list of workspaces that have been launched but are not yet locked (and also show the PDE dialog in that case).
*** Bug 331989 has been marked as a duplicate of this bug. ***
I'll look into this for M5. I guess the changes will be too big to fix it for M4. The underlying problem is old. Before M4, it was mainly a focus issue for the user, but now it also causes missing functionality (missing Edit... button).
Houston, we have a little problem here: PDE JUnit launch configurations have a workspace field, but depending on the Product/Application that is selected on the Main tab, that field is not used at all. E.g. with Application: "[No Application] - Headless Mode", no workspace is ever created, so showing the dialog just based on conflicting locations in the launch config will actually block test runs that never cause a problem. A better solution would be to let the launcher detect the conflict but then it shouldn't show a dialog but report the failure back to the host workbench, so we can show the more useful dialog there. Unfortunately, I have no idea how the launcher could be tweaked to not show its dialog.
Created attachment 190378 [details] Fix
Curtis, I can release the change in IDEApplication if you release the LaunchListener.
+1 Applied changes to LaunchListener to HEAD.
Thanks, released to HEAD.
Raksha, could you please verify this bug during the test pass? Bug 331989 is your dup.
Verified for 3.6 M6 with I20110307-2110.
Verified in 3.6 M6.
