Think I better step in and say something here...
Basically, MaxGUI has never officially supported nested child windows. Mark/Skidracer seemed to have looked into the idea of MDI child windows at one point (hence the undocumented WINDOW_CHILD flag that only worked on the old Windows MaxGUI driver). However, I believe that it was quickly decided that MDI child windows weren't very cross-platform friendly (OS X for example, doesn't provide any API for such window management) but it is also considered quite an old-fashioned way of managing multiple documents in favour of tabbed/multiple window layouts. Because of this, only
MaxGUI.Win32MaxGUI behaves differently with
WINDOW_CHILD and the only reason this constant hasn't been removed is for backwards compatibility. However, the trial Windows implementation of WINDOW_CHILD had many inconsistencies/problems (one of which you've found to be an inability to add menus), which is a design constraint imposed by Microsoft in the MDI era.
This is not to say, however, that a window can't have a parent. The latest MaxGUI drivers cause windows (with a
group parameter specified in the
CreateWindow call) to be linked with the parent window. Although they won't move with the parent window, the window will stay-on-top of, and minimize with the parent. These are what I now refer to as child windows and are far more common place than MDI in modern day programs.
OK, onto
MaxGUI.Drivers. You're half right in that
MaxGUI.Drivers imports the correct module for the environment you are running, but this isn't purely OS dependent. Quite simply, it comes down to the version of Common Controls you are using. Although for Windows 9X/ME, the common control version will always fall below the threshold required for the newer
MaxGUI.Win32MaxGUIEx to be used, the behaviour isn't as clear-cut for Windows XP/Vista, as the version of Common Controls your application uses is dependent upon the presence of a manifest file. Fortunately, MaxGUI imports this as an embedded resource automatically on Windows, so on the newer OSs you'll be using the newer MaxGUI driver.
Although that probably sounds very confusing, in practice there's very good reasoning.
MaxGUI.Win32MaxGUIEx is an improved Windows MaxGUI implementation that allows you to build unicode apps for the newer OSs that can support it - without the help of MSLU, apps compiled only with
MaxGUI.Win32MaxGUIEx will not work on Windows 9X.
MaxGUI.Win32MaxGUI is the older ANSI MaxGUI implementation that is now somewhat redundant but kept for maintaining backwards compatibility on the older OSs. Importing
MaxGUI.Drivers sorts out most of the hard-work for you, so that MaxGUI applications should at least do something on legacy operating systems.
You're right - you can circumvent this behaviour by directly importing
MaxGUI.Win32MaxGUI yourself instead of
MaxGUI.Drivers, but you will lose all the advantages
MaxGUI.Win32MaxGUIEx gives on Windows XP/Vista. Here are just a few off the top of my head:
> Unicode support.
> More professional looking applications that are properly themed.
> Better support for gadget colours/pixmaps.
> Generic gadget tooltips.
> Faster resizing of gadgets, and text area highlighting.
> Other misc. bug fixes.
Checkout
my worklog for more info.