Re: Digest for EUforum at topica.com, issue 4180
Christian Cuvier wrote:
>
> > 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 ...
[snip]
> That's a swift reaction.... :) Well, perhaps it had been in the air before.
No. Your 'request' the other day was the first I'd heard about doing
this sort of thing. I designed and implemented the solution today. But
I'm still in a position to do last minute changes.
> 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.
Okay, well I always send the event to the window that has the menu attached.
I handle menus, sub-menus, menu items, system menu and other built-in
Windows menus. The same event, w32HMenuSelect, is used when a menu (item)
is selected and when it is closed. The accompanying data is used to
tell the difference.
> 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?
Sort of. I changed setId() such that it first tries to use the normal
method of saving the Id for the hWnd. If that doesn't work (for some
things Windows prevents you doing that), I store the linkage locally
within the library. getId() first tries to get the Id in the normal
manner, and if that fails it scans the local storage. However, getHWND()
works differently, as it always gets the hWnd for the Id as it supplied
by Windows when the control was created. A subtle difference, I know.
getHandle() is the 'proper' way to get the handle for an Id, as
getHWND() is a quick & dirty method that uses no error checking.
> 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.
Ok, I'll look at this method. I was going to implement changes to a
menu list just be rebuilding the whole menu from scratch after the update.
--
Derek Parnell
Melbourne, Australia
|
Not Categorized, Please Help
|
|
