Community
Participate
Working Groups
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) Build Identifier: If you create a ApplicationWindow with a menu bar, the initializeBounds() breaks before it calls getInitialSize() and getInitialLocation(). Please see the attached snippet: It first shows an ApplicationWindow without menu bar. initializeBounds() runs correct. After closing this window, it shows an ApplicationWindow with menu bar. Now initializeBounds() breaks to early and don't call getInitialSize() and getInitialLocation(). The problem is that createTrimWidgets() in ApplicationWindow create a shell resize event which lets initializeBounds() break. Reproducible: Always
Created attachment 146935 [details] Snippet of the problem
This can be worked around by overriding the create() method and setting the location and size of the shell after the fact. The problem itself can be fixed by moving the menu construction code out of createTrimWidgets(Shell) method and into, like above, a new overridden create() method defined in ApplicationWindow. This can however break clients if they were expecting a menu bar to have been set on the shell, say, by the time createContents(Composite) is called.
I don't see us changing the control flow here if there is a workaround. Let us know if Remy's suggested workaround is sufficient. (thanks, Remy).
(In reply to comment #3) > I don't see us changing the control flow here if there is a workaround. Let us > know if Remy's suggested workaround is sufficient. (thanks, Remy). Yes the workaround works, but this is a bug! And there is an easy fix for this. I Can't understand why you don't wana fix this. Yes, it maybe breaks with some current implementations. But this is a major release. If you want to migrate to another major release with you application, you have to test it.
I agree this is a bug. For some of the most mature parts of the SDK (such as JFace), the ease of the fix isn't the only criteria for fixing in the 3.x stream. The possibility of breaking long-standing consumers of the code is also important. Changing the widget creation sequence likely won't happen without votes on this bug to raise the priority. Now, this is the kind of thing that could get fixed in the e4 timeframe, since that release introduces major structural changes in the implementation of the UI.
> Changing the widget creation sequence likely won't happen without votes [..] That would be a breaking change that should never happen, especially since there are easy other ways to fix this. You could e.g. make Window#resizeHasOccurred package-visible and just add code in ApplicationWindow#createTrimWidgets(Shell) around shell.setMenuBar(..) that restores the value from before setMenuBar(..). You could also add a protected hook method Window#blocksInitializeBounds(Event) and call it from the Resize listener. That would also allow to remove the hack in WorkbenchWindow#initializeBounds().
is there a chance that you fix this in the release 4 branch?
In current state, getInititalSize() method is practically totally useless. We still need some fix.
removing milestone (since we didn't look at this for 4.0). We currently have not had to branch JFace for the 4.x stream. If you want to submit a patch and test cases along the lines of comment #6, then that would help things along.
Created attachment 178488 [details] Patch which fixes the bug Here is a patch which fixes the bug the way is was described in comment#6
As of today in Eclipse 4.2 this bug is still there. Another workaround is to set shell size in configureShell: ... Point size = this.getInitialSize(); newShell.setSize(size); ... Thanks.
Released as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=f5158dd77a576504dbf92e2c1f7884ce8d257991 PW
In 4.3.0.I20130311-2000 Please be sure to test it in your own configurations. PW
