1. Re: Digest for EUforum at topica.com, issue 4180
> posted by: Derek Parnell <ddparnell at bigpond.com>
>
> I'm thinking of implementing a w32HMenuSelect event in the next
> version. It goes something like this ...
>
> -------w32HMenuSelect ------------------------
> The event handler parameters are
> {ItemId, ParentID, Flags, wParam, lParam}
>
> This event is triggered when the application receives a
> WM_MENUSELECT message from Windows. These are received
> when the user selects a menu or menuitem before clicking it.
>
> ** ItemId, if greater than zero, is the Win32lib ID of the menu
> or menuitem selected. A value of 0 means that the menu has been
> closed. Values less than zero are the negative value of the
> Windows predefined menu item ids of the System Menu items,
> except that -1 is used for the System Menu itself.
>
> ** ParentId. If 'ItemId' is a win32lib id, this is the win32lib
> id of its parent control. If 'ItemId' is zero, this is the
> item id of the last one we received a message for, which is
> -1 if it was the system menu that closed. If 'ItemId' is
> a System Menu item, this is the menu text for that item.
>
> ** Flags. Can be a combination of ...
> - MF_BITMAP Item displays a bitmap.
> - MF_CHECKED Item is checked.
> - MF_DISABLED Item is disabled.
> - MF_GRAYED Item is grayed.
> - MF_HILITE Item is highlighted.
> - MF_MOUSESELECT Item is selected with the mouse.
> - MF_OWNERDRAW Item is an owner-drawn item.
> - MF_POPUP Item opens a drop-down menu or submenu.
> - MF_SYSMENU Item is contained in the window menu. The lParam
> parameter contains a handle to the menu associated with the
> message.
>
> ** wParam and lParam are the raw data items passed by the
> Windows WM_MENUSELECT message.
>
> This event is only triggered for a Window that has a menu attached.
> -------------------------------------------------
>
> All comments and suggestions welcome.
>
> -- Derek Parnell Melbourne, Australia
That's a swift reaction.... :) Well, perhaps it had been in the air before.
I send you two demos tonight:
One is about tracking the selected menu item. It issues w32HChange for menu
items (sent to the menu item itself) and w32HCloseUp for menu closed (sent to
menu). My demo doesn't care about the system menu atm, nor about subclassed
controls.
I guess that the restriction stated at line 12574 will be lifted in the
process, so that getId() and getHWND() are the reverse of each other for any
win32lib control. Right?
The other demo shows how to remove items from a menu dynamically. It may eat
some memory (it creates the whole series of MENUITEMTEMPLATEs), but can be
optimized for a certain class of menus, namely, those created using
LoadMenuIndirect() and subclassed so that win32lib knows about them.
All kinds of slicing are supported, but just keeping a continuous range of
items is quite efficient for the special kind of menus described above. They
are very easy to clone too (just keep a refcount to free the resource common
to the clones when appropriate); that was my original motivation to look into
this matter.
CChris
