Hey all,

Im running into some trouble implementing Windy , a GUI kit for windows.

The problem arises when handling the WM_COMMAND messages originating from Menu's.  The event handling now is to associate a HWND with a Wnd class, and have the Wnd class process the message with its own internal map of messages and event handlers.  But the WM_COMMAND generated by menu's doesnt contain a HWND to a Window, so I cant get a Wnd class to handle the message.

There are two ways I can handle this, I can associate a MENUINFO structure with the menu, which will change the generated messages to WM_MENUCOMMAND, with that I can call GetMenuInfo, and I can assocaite a HWND with a menu this way, and leave the message handling system consistent

OR

I can add a function  [ addMenuHandler ] ( on top of the existing addHandler ) , and just keep the menu message handlers in a global map. This will be faster, but requires the user to memorize another function, which could easily cause trouble for users of the lib.

I hate these design / perfornace tradeoff choices, and would like your opinions on what you think is best.

Also the USER32.lib that comes with the Digital Mars CD doesnt have SetMenuInfo function in it, I tried

implib /system USER32.lib USER32.dll

But it still doesnt contain the _function@16 format that is required ( I learned finally that the last number is the total size of the parameters being passed ).

Does anyone have a valid USER32.lib ?  Walter can you update the libs that come with the CD ?

Charles

Charles Sanders wrote:
> Hey all,
> 
> Im running into some trouble implementing Windy , a GUI kit for windows.
> 
> The problem arises when handling the WM_COMMAND messages originating from
> Menu's.  The event handling now is to associate a HWND with a Wnd class, and
> have the Wnd class process the message with its own internal map of messages
> and event handlers.  But the WM_COMMAND generated by menu's doesnt contain a
> HWND to a Window, so I cant get a Wnd class to handle the message.

dfbth (Yet Another Windowing Toolkit coded in D) has an abstract handleCommand method in the base Control class.  Control.WndProc relays the command here.  CompositeCommand overrides and looks for an applicable child, and relays it yet again.  Other subclasses do interesting things depending on what they are. (Button just fires its onClick signal, et cetera)  I hate to blow my own horn, but it works really well. :)

You could first check the attached menu and see if it will handle the command.  If not, fall back on whatever the superclass does.

> There are two ways I can handle this, I can associate a MENUINFO structure
> with the menu, which will change the generated messages to WM_MENUCOMMAND,
> with that I can call GetMenuInfo, and I can assocaite a HWND with a menu
> this way, and leave the message handling system consistent

Internally allocate unique command IDs to menu items.  Then you don't need any weird hacks.

> OR
> 
> I can add a function  [ addMenuHandler ] ( on top of the existing
> addHandler ) , and just keep the menu message handlers in a global map.
> This will be faster, but requires the user to memorize another function,
> which could easily cause trouble for users of the lib.
> 
> I hate these design / perfornace tradeoff choices, and would like your
> opinions on what you think is best.

Performance isn't really critical in this sort of thing.  Nobody's selecting menu items three billion times per second, and, if your dispatching code really does cause a noticible delay, then you're doing something very, very wrong.  Do whatever's easier to implement and use, and forget speed until you have proof that it's not up to par.

> Also the USER32.lib that comes with the Digital Mars CD doesnt have
> SetMenuInfo function in it, I tried
> 
> implib /system USER32.lib USER32.dll

If it's not in the resultant lib, then I would believe that it's not in the DLL either.  Are you sure you're translating the parameter types properly? (C++ long is still only 32 bits on x86)

 -- andy

>  (C++ long is still only 32 bits on x86)

speaking of which, is there a standard Dism for "C++ long" when writing the
interface to a C/C++ library? I made a typdef gmp_long when translating
gmp.h to gmp.d
thanks,
-Ben

Ben Hinkle wrote:
>> (C++ long is still only 32 bits on x86)
> 
> 
> speaking of which, is there a standard Dism for "C++ long" when writing the
> interface to a C/C++ library? I made a typdef gmp_long when translating
> gmp.h to gmp.d
> thanks,
> -Ben

You could use the std.stdint module if you want a specific number of bits.  Failing that, I would use an alias instead of a typedef. Typedefs like that tend to cause many a cast to be required later on.

Personally, I would just call it an int and be done with it. :)

 -- andy

> If it's not in the resultant lib, then I would believe that it's not in the DLL either.

Yes its in the DLL (
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/WindowsUserInterface/Resources/Menus/MenuReference/MenuFunctions/SetMenuInfo.asp )
even though I probably wont  use this approach I'd still like the ability to
use this function.

> Are you sure you're translating the parameter types
> properly? (C++ long is still only 32 bits on x86)

Yea just an example not the actual entry.

> dfbth (Yet Another Windowing Toolkit coded in D)

Aww, we should have teamed up!  I've seen hundreds of individual projects but have not yet seen a team one :/.

C


"Andy Friesen" <andy@ikagames.com> wrote in message news:bp7c0c$30oh$1@digitaldaemon.com...
> Charles Sanders wrote:
> > Hey all,
> >
> > Im running into some trouble implementing Windy , a GUI kit for windows.
> >
> > The problem arises when handling the WM_COMMAND messages originating
from
> > Menu's.  The event handling now is to associate a HWND with a Wnd class,
and
> > have the Wnd class process the message with its own internal map of
messages
> > and event handlers.  But the WM_COMMAND generated by menu's doesnt
contain a
> > HWND to a Window, so I cant get a Wnd class to handle the message.
>
> dfbth (Yet Another Windowing Toolkit coded in D) has an abstract handleCommand method in the base Control class.  Control.WndProc relays the command here.  CompositeCommand overrides and looks for an applicable child, and relays it yet again.  Other subclasses do interesting things depending on what they are. (Button just fires its onClick signal, et cetera)  I hate to blow my own horn, but it works really well. :)
>
> You could first check the attached menu and see if it will handle the command.  If not, fall back on whatever the superclass does.
>
> > There are two ways I can handle this, I can associate a MENUINFO
structure
> > with the menu, which will change the generated messages to
WM_MENUCOMMAND,
> > with that I can call GetMenuInfo, and I can assocaite a HWND with a menu this way, and leave the message handling system consistent
>
> Internally allocate unique command IDs to menu items.  Then you don't need any weird hacks.
>
> > OR
> >
> > I can add a function  [ addMenuHandler ] ( on top of the existing addHandler ) , and just keep the menu message handlers in a global map. This will be faster, but requires the user to memorize another function, which could easily cause trouble for users of the lib.
> >
> > I hate these design / perfornace tradeoff choices, and would like your opinions on what you think is best.
>
> Performance isn't really critical in this sort of thing.  Nobody's selecting menu items three billion times per second, and, if your dispatching code really does cause a noticible delay, then you're doing something very, very wrong.  Do whatever's easier to implement and use, and forget speed until you have proof that it's not up to par.
>
> > Also the USER32.lib that comes with the Digital Mars CD doesnt have SetMenuInfo function in it, I tried
> >
> > implib /system USER32.lib USER32.dll
>
> If it's not in the resultant lib, then I would believe that it's not in the DLL either.  Are you sure you're translating the parameter types properly? (C++ long is still only 32 bits on x86)
>
>   -- andy
>

"Andy Friesen" <andy@ikagames.com> wrote in message news:bp7c0c$30oh$1@digitaldaemon.com...
> Charles Sanders wrote:
> > Hey all,
> >
> > Im running into some trouble implementing Windy , a GUI kit for windows.
> >
> > The problem arises when handling the WM_COMMAND messages originating
from
> > Menu's.  The event handling now is to associate a HWND with a Wnd class,
and
> > have the Wnd class process the message with its own internal map of
messages
> > and event handlers.  But the WM_COMMAND generated by menu's doesnt
contain a
> > HWND to a Window, so I cant get a Wnd class to handle the message.
>
> dfbth (Yet Another Windowing Toolkit coded in D) has an abstract handleCommand method in the base Control class.  Control.WndProc relays the command here.  CompositeCommand overrides and looks for an applicable child, and relays it yet again.  Other subclasses do interesting things depending on what they are. (Button just fires its onClick signal, et cetera)  I hate to blow my own horn, but it works really well. :)
>
> You could first check the attached menu and see if it will handle the command.  If not, fall back on whatever the superclass does.
>
> > There are two ways I can handle this, I can associate a MENUINFO
structure
> > with the menu, which will change the generated messages to
WM_MENUCOMMAND,
> > with that I can call GetMenuInfo, and I can assocaite a HWND with a menu this way, and leave the message handling system consistent
>
> Internally allocate unique command IDs to menu items.  Then you don't need any weird hacks.
>
> > OR
> >
> > I can add a function  [ addMenuHandler ] ( on top of the existing addHandler ) , and just keep the menu message handlers in a global map. This will be faster, but requires the user to memorize another function, which could easily cause trouble for users of the lib.
> >
> > I hate these design / perfornace tradeoff choices, and would like your opinions on what you think is best.
>
> Performance isn't really critical in this sort of thing.  Nobody's selecting menu items three billion times per second, and, if your dispatching code really does cause a noticible delay, then you're doing something very, very wrong.  Do whatever's easier to implement and use, and forget speed until you have proof that it's not up to par.
>
> > Also the USER32.lib that comes with the Digital Mars CD doesnt have SetMenuInfo function in it, I tried
> >
> > implib /system USER32.lib USER32.dll
>
> If it's not in the resultant lib, then I would believe that it's not in the DLL either.  Are you sure you're translating the parameter types properly? (C++ long is still only 32 bits on x86)
>
>   -- andy
>

Oops, stupid outlook.



> You could first check the attached menu and see if it will handle the command.  If not, fall back on whatever the superclass does.

What attached menu ?  The only paramater that comes with the WM_COMMAMD messages generated from menu's is the control ID you've assigned it.  Can you show me your code ?

Thanks,
C


"Charles Sanders" <sanders-consulting@comcast.net> wrote in message news:bp8fbj$1f4t$1@digitaldaemon.com...
>
>
> "Andy Friesen" <andy@ikagames.com> wrote in message news:bp7c0c$30oh$1@digitaldaemon.com...
> > Charles Sanders wrote:
> > > Hey all,
> > >
> > > Im running into some trouble implementing Windy , a GUI kit for
windows.
> > >
> > > The problem arises when handling the WM_COMMAND messages originating
> from
> > > Menu's.  The event handling now is to associate a HWND with a Wnd
class,
> and
> > > have the Wnd class process the message with its own internal map of
> messages
> > > and event handlers.  But the WM_COMMAND generated by menu's doesnt
> contain a
> > > HWND to a Window, so I cant get a Wnd class to handle the message.
> >
> > dfbth (Yet Another Windowing Toolkit coded in D) has an abstract handleCommand method in the base Control class.  Control.WndProc relays the command here.  CompositeCommand overrides and looks for an applicable child, and relays it yet again.  Other subclasses do interesting things depending on what they are. (Button just fires its onClick signal, et cetera)  I hate to blow my own horn, but it works really well. :)
> >
> > You could first check the attached menu and see if it will handle the command.  If not, fall back on whatever the superclass does.
> >
> > > There are two ways I can handle this, I can associate a MENUINFO
> structure
> > > with the menu, which will change the generated messages to
> WM_MENUCOMMAND,
> > > with that I can call GetMenuInfo, and I can assocaite a HWND with a
menu
> > > this way, and leave the message handling system consistent
> >
> > Internally allocate unique command IDs to menu items.  Then you don't need any weird hacks.
> >
> > > OR
> > >
> > > I can add a function  [ addMenuHandler ] ( on top of the existing addHandler ) , and just keep the menu message handlers in a global
map.
> > > This will be faster, but requires the user to memorize another
function,
> > > which could easily cause trouble for users of the lib.
> > >
> > > I hate these design / perfornace tradeoff choices, and would like your opinions on what you think is best.
> >
> > Performance isn't really critical in this sort of thing.  Nobody's selecting menu items three billion times per second, and, if your dispatching code really does cause a noticible delay, then you're doing something very, very wrong.  Do whatever's easier to implement and use, and forget speed until you have proof that it's not up to par.
> >
> > > Also the USER32.lib that comes with the Digital Mars CD doesnt have SetMenuInfo function in it, I tried
> > >
> > > implib /system USER32.lib USER32.dll
> >
> > If it's not in the resultant lib, then I would believe that it's not in the DLL either.  Are you sure you're translating the parameter types properly? (C++ long is still only 32 bits on x86)
> >
> >   -- andy
> >
>
>

Charles Sanders wrote:
> Oops, stupid outlook.
> 
> 
> 
> 
>>You could first check the attached menu and see if it will handle the
>>command.  If not, fall back on whatever the superclass does.
> 
> 
> What attached menu ?  The only paramater that comes with the WM_COMMAMD
> messages generated from menu's is the control ID you've assigned it.  Can
> you show me your code ?
> 
It looks like Andy posts all of his cool stuff at: http://ikagames.com/andy/d/

dfbth is listed there.

Justin

Charles Sanders wrote:
>>You could first check the attached menu and see if it will handle the
>>command.  If not, fall back on whatever the superclass does.
> 
> 
> What attached menu ?  The only paramater that comes with the WM_COMMAMD
> messages generated from menu's is the control ID you've assigned it.  Can
> you show me your code ?

http://ikagames.com/andy/d/dfbth-15-nov-2003.zip

> Thanks,
> C

I haven't gotten to implementing menus in dfbth just yet.  But, basically, what you'd do is something like this:

class Form : CompositeControl
{
    int handleMessage(int code, int notifyCode)
    {
        if (_menuBar !== null)
        {
            int result = _menuBar.handleCommand(code, notifyCode); // relay the call
            if (result) return result; // we're done if the menu dealt with it
        }

        // if there's no menu, or it didn't recognize the command ID,
        // fall back on the default behaviour. (find a child that
        // will handle it, discard it, whatever)
        return super.handleMessage(code, notifyCode);
    }

    // ...
}

The menubar would just see if any of its menu items will respond to the command code, and dispatch the correct signal if it can. (generate command codes on the fly, make sure each is unique) If not, return 0, let the caller fish around elsewhere for someone that will handle it.

 -- andy

"Andy Friesen" <andy@ikagames.com> wrote in message news:bp88h1$15ja$1@digitaldaemon.com...
> Ben Hinkle wrote:
> > speaking of which, is there a standard Dism for "C++ long" when writing
the
> > interface to a C/C++ library? I made a typdef gmp_long when translating gmp.h to gmp.d
> Personally, I would just call it an int and be done with it. :)

So would I <g>.