A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
Maybe a simple question, but still I wonder ...
Consider an mdi application, how do you handle the menu and toolbar ?
How do you handle the calls when they need to be redirected by the mdiForm to the child forms (like save/open/undo/...) ?
I've been looking around the internet for the 'better way', but there doesn't seem to be a lot out there about the topic.
How do you generally do it ?
Do you use an enumeration and 1 method ?
Do you have seperate methods ?
Do you have each child have it's own (so you can take the calls directly) menu/toolbar and merge this with the main one ?
How do you handle it when child can't do certain actions (f.i. undo is unavailable at present, so it should be disabled in the menu), how do you redirect that to the menu/toolbar ?
Do you have 1 class that contains the logic ?
Do you have a seperate method on the childforms that take the menu and enabled/disable the menuitems ?
Does the mdiform contain that logic ?
Do you have each child have it's own (so you can set the enabled/disable directly) menu/toolbar and merge this with the main one ?
I'm curious about the ways of the great :)
Tuesday, November 15, 2005
I use a message router object. The menu/toolbar simply notifies that object that event xxx just happened (user clicked "Refresh". The message router then looks up that event in it's collection and examines to see if there are any subscribers for that event. If so, it notifies them. They are responsible for knowing what to do.
I don't know about the ways of the great, and your question borders on being platform/toolkit dependant (although mentioning MDI, you hint at your target platform), so I will try to answer in generalities.
Most people strive to make their GUI logic follow the typical MVC model. Note that the MFC Document/Viewer architecture is far from being an MVC model. Once this is implemented, you have a flexible, and low binding interface for message passing to and from the GUI layer.
Now, how about the container windows and its child windows in an MDI setting?
Well, in a typical application using MDI, the child windows are almost always multiple instances of the same animal. For example, in Excel, the spreadsheet child windows are all spreadsheet windows, and with minor variations will support most of the functionality.
Well, then, the parent would naturally want to send messages to the exhaustive list of its child windows...but how to address them?
You can't send an application specific message to a toolkit window, since by definition, a toolkit window will only support the base and derived operations provided by the toolkit framework...so having the parent send a 'RESIZE' message to its collection of children is fine, but having it send a 'RotateMyCompanyLogo' message will not pan out.
I typically derive all my MDI child windows from a thin class containing all the common application specific methods. The class contains stubs, or logical defaults, in case a child windows chooses not to implement that functionality. The base class then derives from a common container compliant class such as 'control' or 'frame', or 'form', or whatever the MDI windows typically derive from in your framework.
In this way, the MVC framework takes care of addressing the messaging between business logic and the GUI, the parent doesn't care about the specifics of the MDI children aside from the interface provided to it by their base class, and the children only implement what they need.
Note...there are MANY other ways of implementing this. Many deal with common design patterns, but I tend to shy away from using patterns for the sake of using patterns.
Wall Street Programmer
Wednesday, November 16, 2005
I like your solution, just one question about it :
How do you handle things like a menuitem M1 needs to be disabled for child C1 and menuitem M2 needs to be disabled for child C2 but enabled for child C1 ?
Wall Street Programmer :
A typical Mdi Application doesn't need to have multiple instances of the same animal. Most Mdi Applications I have seen are a complete zoo.
Basicily you are saying you use normal inheritance, and define a method for every call that could be made to a child in the baseform. Or am I reading you wrong here ?
How do you handle to problem I address above here to John ?
Wednesday, November 16, 2005
Look at this articles:
Is a great idea for build a very flexible GUI. Consider use a interface more like Firefox, is best ;)
Mario Alejandro M.
Wednesday, November 16, 2005
> Basicily you are saying you use normal inheritance, and
> define a method for every call that could be made to a
> child in the baseform.
> Or am I reading you wrong here?
That's the way I read it.
> How do you handle to problem I address above here
> to John?
When you get the WM_INITMENUPOPUP message, get the pointer to the currently active MDI window and let it handle this message.
Since C1 and C2 will both be derived from some CBaseClass doing somthing like this:
allows you to initialisation the menu based on the type of MDI that is currently active.
Thursday, November 17, 2005
Jussi Jumppanen :
"When you get the WM_INITMENUPOPUP message, get the pointer to the ..."
When you do it this way then the Child has to know of the menu structure, since it needs to manipulate the menu directly. This is a way that I want to avoid, since it ties the child to the menu to much.
Friday, November 18, 2005
I have a menu handler class for each window. All menu logic is routed through that business object which has intricate knowledge of the window it's handling.
So when M1 is created, a call is made to it's menu handler to process security and selection items based on current state.
When a menu item is clicked, the message is also routed through this menu handler class which in turn, depending on the action, either calls a Business Object, or forwards the message onto it's window.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz