www.digitalmars.com         C & C++   DMDScript  

D - Design Question

reply "Charles Sanders" <sanders-consulting comcast.net> writes:
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
Nov 15 2003
parent reply Andy Friesen <andy ikagames.com> writes:
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
Nov 16 2003
next sibling parent reply "Ben Hinkle" <bhinkle4 juno.com> writes:
  (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
Nov 16 2003
parent reply Andy Friesen <andy ikagames.com> writes:
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
Nov 16 2003
parent reply "Walter" <walter digitalmars.com> writes:
"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


 interface to a C/C++ library? I made a typdef gmp_long when translating
 gmp.h to gmp.d


So would I <g>.
Nov 18 2003
parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bpet6l$1r31$1 digitaldaemon.com...
 "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



 the
 interface to a C/C++ library? I made a typdef gmp_long when



 gmp.h to gmp.d


So would I <g>.

I'm dipping in here without having read the previous postings in the thread (newsreader "issues"), but I think this is a bad move. When porting from an external API, you centralise all the type translations in one place if you define and use the requisite types in the D form. For example, in the D mapping of recls - which will be in D std lib from 0.76 onwards - I use the type recls_rc_t (the return type), rather than int, since it may conceivably change in recls at some point, and I don't want to have to go around the D mapping guessing which int is a return code, and which is just an int. Frankly, I'm surprised to hear counter opinions. This is integration lesson 1. Or am I missing something?
Nov 18 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bpf1c5$21id$1 digitaldaemon.com...
 Frankly, I'm surprised to hear counter opinions. This is integration

 1. Or am I missing something?

I'm not a very orthodox programmer. I tend to use far fewer typedefs than others, usually only for either 1) documentation purposes or if 2) I *know* it will change, rather than worry that it might. The reason for (2) is my experience migrating from the 16 bit world to 32 bits. 16 bit programmers would really load up their code with typedef's for portability reasons, and yet when the code was ported to 32 bits it still broke all over the place and was just as much trouble to fix as code with no typedefs at all. The trouble comes from subtle dependencies on the type of a typedef creeping in from all sides. Another part of my reluctance to use typedefs is I have spent too many hours tracing through too many layers of typedefs, macros, #include's, #if's, etc., trying to figure out just what type foo_x_t_bar_abc__t_my_x_t actually is. Some things I know are going to change? For 64 bits, size_t and ptrdiff_t are not going to be int-sized any more. File sizes and file offsets are going to 64 bits. time_t is going to change. The size of a pointer is going to change. Things that I am sure won't change? sizeof(char) is going to stay 1. The number of bits in a byte is going to stay at 8 (10 bit bytes and 18 bit half-words are machines of the past, and are not going to be resurrected). Ones-complement isn't coming back. IEEE 754 floating point is here to stay. Worrying about these things changing is fruitless because (aside from those changes not happening) despite one's best efforts, one will get it wrong anyway trying to be portable to such architectures without actually testing it on such. I think the 16 to 32 bit conversion proved that <g>.
Dec 26 2003
parent reply Mark T <Mark_member pathlink.com> writes:
In article <bsgv5n$11m4$1 digitaldaemon.com>, Walter says...
I'm not a very orthodox programmer. I tend to use far fewer typedefs than
others, usually only for either 1) documentation purposes or if 2) I *know*
it will change, rather than worry that it might. The reason for (2) is my
experience migrating from the 16 bit world to 32 bits. 16 bit programmers
would really load up their code with typedef's for portability reasons, and
yet when the code was ported to 32 bits it still broke all over the place
and was just as much trouble to fix as code with no typedefs at all. The
trouble comes from subtle dependencies on the type of a typedef creeping in
from all sides.

Of course poorly done typedefs are always a problem partly because C/C++ does not actually create a new type. A few years of Ada programming makes you appreciate what types can be.
Dec 26 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Mark T" <Mark_member pathlink.com> wrote in message
news:bshlgj$25mu$1 digitaldaemon.com...
 In article <bsgv5n$11m4$1 digitaldaemon.com>, Walter says...
I'm not a very orthodox programmer. I tend to use far fewer typedefs than
others, usually only for either 1) documentation purposes or if 2) I


it will change, rather than worry that it might. The reason for (2) is my
experience migrating from the 16 bit world to 32 bits. 16 bit programmers
would really load up their code with typedef's for portability reasons,


yet when the code was ported to 32 bits it still broke all over the place
and was just as much trouble to fix as code with no typedefs at all. The
trouble comes from subtle dependencies on the type of a typedef creeping


from all sides.

Of course poorly done typedefs are always a problem partly because C/C++

 not actually create a new type. A few years of Ada programming makes you
 appreciate what types can be.

I've never programmed in Ada so I'll take your word for it. BTW, D does have strong typedef's unlike C/C++.
Dec 26 2003
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bsicou$cjv$1 digitaldaemon.com...
 "Mark T" <Mark_member pathlink.com> wrote in message
 news:bshlgj$25mu$1 digitaldaemon.com...
 In article <bsgv5n$11m4$1 digitaldaemon.com>, Walter says...
I'm not a very orthodox programmer. I tend to use far fewer typedefs



others, usually only for either 1) documentation purposes or if 2) I


it will change, rather than worry that it might. The reason for (2) is



experience migrating from the 16 bit world to 32 bits. 16 bit



would really load up their code with typedef's for portability reasons,


yet when the code was ported to 32 bits it still broke all over the



and was just as much trouble to fix as code with no typedefs at all.



trouble comes from subtle dependencies on the type of a typedef



 in
from all sides.

Of course poorly done typedefs are always a problem partly because C/C++

 not actually create a new type. A few years of Ada programming makes you
 appreciate what types can be.

I've never programmed in Ada so I'll take your word for it. BTW, D does

 strong typedef's unlike C/C++.

STLSoft does provide strong typedefs, called "True Typedefs". See the file stlsoft_true_typedef.h
Dec 27 2003
prev sibling next sibling parent "Charles Sanders" <sanders-consulting comcast.net> writes:
 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/MenuFunct ons/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


 Menu's.  The event handling now is to associate a HWND with a Wnd class,


 have the Wnd class process the message with its own internal map of


 and event handlers.  But the WM_COMMAND generated by menu's doesnt


 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


 with the menu, which will change the generated messages to


 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

Nov 16 2003
prev sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
"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


 Menu's.  The event handling now is to associate a HWND with a Wnd class,


 have the Wnd class process the message with its own internal map of


 and event handlers.  But the WM_COMMAND generated by menu's doesnt


 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


 with the menu, which will change the generated messages to


 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

Nov 16 2003
parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
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



 The problem arises when handling the WM_COMMAND messages originating


 Menu's.  The event handling now is to associate a HWND with a Wnd



 and
 have the Wnd class process the message with its own internal map of


 and event handlers.  But the WM_COMMAND generated by menu's doesnt


 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


 with the menu, which will change the generated messages to


 with that I can call GetMenuInfo, and I can assocaite a HWND with a



 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



 This will be faster, but requires the user to memorize another



 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


Nov 16 2003
next sibling parent J C Calvarese <jcc7 cox.net> writes:
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 ?

http://ikagames.com/andy/d/ dfbth is listed there. Justin
Nov 16 2003
prev sibling parent Andy Friesen <andy ikagames.com> writes:
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
Nov 16 2003