Community
Participate
Working Groups
Eclipse 3.3 M5 When I select "Open With" > "Other..." for any file, it really takes a while before the dialog is showing (~3-5 seconds). In this time the UI is blocked. I think the dialog should load the editors in the background (I am not even sure if thats possible because you are probably using the Program API of SWT?) and/or cache the results for the running session.
Is this different from going to Window->Preferences->General->Editors->File Associations and clicking on the second "Add..." button? (The dialog that will open is the same that is used for Open With->Other...)
(In reply to comment #1) > Is this different from going to Window->Preferences->General->Editors->File > Associations and clicking on the second "Add..." button? (The dialog that will > open is the same that is used for Open With->Other...) > Nope its not. I haven't realized the dialog being present there already. But still, the UI blocks for some seconds until the dialog opens.
Sounds similar to bug 194001 (which only occurs for me after selecting 'External Programs').
Remy is now responsible for watching the [EditorMgmt] component area.
(In reply to comment #0) > I think the dialog should load the editors in the background (I am not even > sure if thats possible because you are probably using the Program API of SWT?) > and/or cache the results for the running session. There seems to be no problems with retrieving the editors on another thread on win32. I'll have to check the other platforms though.
> There seems to be no problems with retrieving the editors on another thread on > win32. I'll have to check the other platforms though. Program.getPrograms() does not throw an invalid thread access exception, so it has to work from non-UI threads on all platforms (otherwise, you should file a bug for SWT).
(In reply to comment #6) > Program.getPrograms() does not throw an invalid thread access exception, so it > has to work from non-UI threads on all platforms (otherwise, you should file a > bug for SWT). From testing, it feels to me as though just the invocation of this method will "hang" the user interface.
(In reply to Markus Keller from comment #6) > > There seems to be no problems with retrieving the editors on another thread on > > win32. I'll have to check the other platforms though. > > Program.getPrograms() does not throw an invalid thread access exception, so > it has to work from non-UI threads on all platforms (otherwise, you should > file a bug for SWT). See bug 47556 - Program.getPrograms() requires a Display.getCurrent() != null and will return empty array in case the display is null.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.