How do I add a menu to MenuManager?

[ra89]

I downloaded the trial WindowBuilder for the SWT designer. I ran through the Wizard to create a JFace Application Window. I am trying to add a Cascade Menu but cant figure it out.

I see two bars at the top of the form that say "(Empty MenuManager)" and "(Empty ToolBarManager)". I try to select the Cascade Menu control from the Palette and drop it on the MenuManager bar but all I get is a big "-" sign.

I have reviewed your SWT tutorials but they must be old because they show a "Content" and "Actions" tab that don't exist.

I am using Eclipse 3.5.1 and WindowBuilder 7.2.

[Eric Clayberg]

Start with the JFace App Window docs...

http://download.instantiations.com/D2WB ... indow.html

The menubar in a JFace App Window is composed of MenuManagers and JFace Actions.

[elijah]

Hi,

I am also having the same problem. Eclipse 3.5.1 with the 14 trial period. Watch the video from the link above. The problem is the missing JFace Action Pallete. Can anybody help me on this.

[Eric Clayberg]

It would be helpful if you provided a screen shot and a test case.

I see the JFace Actions palette just as depicted in the earlier screen shot and in the docs.

[awagner]

I also have this problem.
And it took my some hours to find the solution (with the help of the hint in this thread):

"The menubar in a JFace App Window is composed of MenuManagers and JFace Actions."

Aha! But this is far away from being intuitive to find out for a beginner !!!
i tried every drag&drop combination with the widgtes under Menu Controls.
Without success of course.

What makes learning SWT Designer difficult too, is the fact that all your screenshots
and videos look completely different from layout and menus/buttons than the current version of SWT Designer.
For example my SWT Designer Palette has 2 Columns and no Menu Bar Widget anywhere.
So your example at http://download.instantiations.com/D2WB ... iting.html
is not reproducable from the first step. Ihis is a very frustating at the beginning with a new tool.

There are many things which are not explainable and where the user wants to punch in the monitor...
For example now I have a new phenomenon where my ApplicationWindow at once got a very big size, and
the method getInitialSize() is by magic in the source. But changing the values in the method has no effect and
the window in the design-view can not be resized.... ahhhhrrrg!
This are those things which gives my developer-peers acknowledgement to decline a visual editor and makes
it hard for me to defend it. Hard for me to believe in the efficiency of such a tool too.

[Eric Clayberg]

All of the screen shots from the docs are from the current version of SWT Designer, so I am not sure what you mean. The palette is fully configurable as shown in the docs. You can easily adjust the number of columns, the order of the categories and even whether certain categories are shown at all. Some categories, for example, only show up when you are dealing with specific frameworks.



JFace App Windows are are a fairly complex framework and not a good place to start, if you are a beginner. Stick with simple SWT App Windows as those have normal menubars, menus, etc. SWT Designer is not a beginners tool as it does assume that you understand the Eclipse frameworks that you have chosen to use. If you were more familiar with the JFace App Window framework, you would know that it does not use normal menubars and menus, but rather JFace Actions and MenuManagers. SWT Designer's support for that framework is designed to make working with it as easy as possible for an experienced user. As such, we added a JFace Action category to the palette specifically to make this easy and intuitive for someone wanting to use that specific framework. If you have no idea how to use that framework or what its expectations are, I could certainly see how it might seem unintuitive.



The Menu Editing docs you refer to only apply to window types (like SWT App Windows) that support having an SWT MenuBar and Menus. They do not apply to the JFace App Window framework at all.

The getInitialSize() is used to set the initial size of a JFace App Window. That is defined by the framework itself, so it is not "magic" that it should be there. I just tried a JFace App Window example and the size shown in the design view reflected the size shown in the source. I was able to resize the window graphically and adjust the source and both stayed in sync. Please provide an example where this is not working so that we can reproduce the problem on our end (screen shots might help).

[pentastich]

I'm seeing the same resizing behavior as the previous poster. I'm running on a 64 bit Linux system (Fedora Core 12) using an Oracle 1.6.0_17 JVM. I'm on an up-to-date Helios eclipse release the WindowBuilder version numbers all appear to be 6.1.1.r36x201012. I use a Compiz window manager and see the same problem on a Windows Vista install.

The problem occurs both inside WindowBuilder and when running the application. It appears that "getInitialSize" is never called. Looking at the code, reveals that "getInitialSize" is called from Window.initializeBounds as follows:

if (resizeHasOccurred) { // Check if shell size has been set already.
return;
}

Point size = getInitialSize();

It turns out that "resizeHasOccured" is true (it's set by a resize listener), and that the event is being triggered by a call to "resizeBounds" from inside of Shell.setMenuBar.

The stack trace looks like:

Thread [main] (Suspended)
Window$2.handleEvent(Event) line: 491
EventTable.sendEvent(Event) line: 84
Shell(Widget).sendEvent(Event) line: 1258
Shell(Widget).sendEvent(int, Event, boolean) line: 1282
Shell(Widget).sendEvent(int) line: 1263
Shell.resizeBounds(int, int, boolean) line: 1579
Shell.setMenuBar(Menu) line: 1815
XDSView(ApplicationWindow).createTrimWidgets(Shell) line: 355
XDSView(ApplicationWindow).configureShell(Shell) line: 344
XDSView.configureShell(Shell) line: 146
XDSView(Window).createShell() line: 502
XDSView(Window).create() line: 430
XDSView(Window).open() line: 790
XDSView$2.run() line: 130
Realm.runWithDefault(Realm, Runnable) line: 332
XDSView.main(String[]) line: 125

If I override Window.initializeBounds in my application window (an experiment) to eliminate the check for an already resized window, then the application behaves correctly when actually run (but not within WindowBuilder).

Hope this helps.

-- Jim

[Eric Clayberg]

WindowBuilder runs the unmodified code for ApplicationWindow defined in Eclipse itself.