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




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>.
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






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>.


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


lesson

 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




*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.


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






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.


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


have

 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




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
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




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
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






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 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 ?
 


It looks like Andy posts all of his cool stuff at: 
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