🚀 go-pugleaf

Kris wrote:

> However, I can't seem to figure out which function to call when I 
> actually need to display the popup-menu I just created 

Problem solved. I completely overlooked the TrackPopupMenuEx() call.

"Kris" <test@test.com> wrote in message
news:46a9b224$1@newsgroups.borland.com...

> However, I can't seem to figure out which function to
> call when I actually need to display the popup-menu I just created

TrackMenuPopup() or TrackMenuPopupEx(), which is clearly stated in
CreatePopupMenu()'s documentation.


Gambit

Remy Lebeau (TeamB) wrote:
> 
> TrackMenuPopup() or TrackMenuPopupEx(), which is clearly stated in
> CreatePopupMenu()'s documentation.

Thanks. I can now properly display a Unicode menu and detect when menu 
items are clicked. However, I'm still wondering about one thing...

#define IDM_MENU_ITEM1 0x00001234
AppendMenuW(MyPopUpMenu,MF_STRING,IDM_MENU_ITEM1,MyWideString);

So, intercepting WM_COMMAND in WndProc when the menu item is clicked 
results in WParamLo containing 0x1234. Based on this value I can 
determine which menu item was actually clicked.

This works great. But I'm wondering if my arbitrary 0x1234 WParamLo 
value that isn't going to potentially run into conflicts with other UI 
actions (e.g. menu items generated by VCL).

Are there any rules as to which values I can use safely use for WParamLo  ?

Thanks,

Kris

"Kris" <test@test.com> wrote in message
news:46a9e711$1@newsgroups.borland.com...

> I'm wondering if my arbitrary 0x1234 WParamLo value
> that isn't going to potentially run into conflicts with other
> UI actions (e.g. menu items generated by VCL).

VCL menu items use their own provide HWND to handle their actions.  The
WM_COMMAND for them will never go through your message handler.  As for the
IDs for them, they start at 0 growing sequentially, and then when an item is
destroyed, its ID is reused for the next item that is created.


Gambit

"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message
news:46aa2786$1@newsgroups.borland.com...

> As for the IDs for them, they start at 0 growing sequentially

Or maybe they start at 1, I'm not sure which.


Gambit

Remy Lebeau (TeamB) wrote:

>> I'm wondering if my arbitrary 0x1234 WParamLo value
>> that isn't going to potentially run into conflicts with other
>> UI actions (e.g. menu items generated by VCL).
> 
> VCL menu items use their own provide HWND to handle their actions.  The
> WM_COMMAND for them will never go through your message handler.  

However, my WndProc() does receive WM_COMMAND messages other than the 
one that I am explicitly generating when my pop-up menu item is clicked.

My test application has, besides a button that triggers the pop-up in 
question, also some additional buttons that generate some output in a 
TMemo. Clicking on those buttons does generate several other WM_COMMAND 
events such as:
Message=00000111 - WParam=0000064E - LParam=0004064E

While clicking my Unicode Popup menu with 0x1234 WParamLo (the value is 
set via AppendMenuW) generates a WM_COMMAND like this:
Message=00000111 - WParam=00001234 - LParam=00000000

As you can see I am going to have potential problems with distinguishing 
between events from my own popup menu and from other events.

I am hoping you can clarify this behavior.

Thanks,

Kris

"Kris" <ks@ks.com> wrote in message news:46aa2e75@newsgroups.borland.com...

> However, my WndProc() does receive WM_COMMAND
> messages other than the one that I am explicitly generating
> when my pop-up menu item is clicked.

As it should be.  WM_COMMAND is used for many things besides menus.  That is
why you need to look at the HIWORD(wParam) and lParam values to know what
the message actually relates to.

> My test application has, besides a button that triggers the
> pop-up in question, also some additional buttons that generate
> some output in a TMemo. Clicking on those buttons does
> generate several other WM_COMMAND events such as:
> Message=00000111 - WParam=0000064E - LParam=0004064E

That LParam contains the HWND of the button that is sending the message.  In
this case, the HIWORD(wParam) value is the BN_CLICKED notification.  So the
VCL will automatically forward the message to the appropriate button
component for handling, which will then cause that button's OnClick event to
be triggered.

> While clicking my Unicode Popup menu with 0x1234 WParamLo
> (the value is set via AppendMenuW) generates a WM_COMMAND
> like this:
> Message=00000111 - WParam=00001234 - LParam=00000000

That LParam does not contain an HWND, so it is a message from a menu, and
the HIWORD(wParam) value contains the ID of the menu item.

> As you can see I am going to have potential problems with
> distinguishing between events from my own popup menu
> and from other events.

No, you will not.  You just need to learn how to read the messages
correctly.  Not to mention that if you allow the VCL to do its default
processing first, you can detect if a message has already been processed so
you can ignore it.  You only have to focus on messages that are not
processed automatically.

Of course, you can simplify that greatly by doing the same thing TMenu does
for itself - create a separate HWND specifically for menu messages and
nothing else.  You don't need to send them through your TForm's message
handler at all.  That way, there is no way for any conflicts to occur at
all, as your HWND will only need to look for the IDs of your particular menu
items and discard everything else.


Gambit

Remy Lebeau (TeamB) wrote:
> "Kris" <ks@ks.com> wrote in message news:46aa2e75@newsgroups.borland.com...
> 
>> However, my WndProc() does receive WM_COMMAND
>> messages other than the one that I am explicitly generating
>> when my pop-up menu item is clicked.

Thanks for clarifying this. Everything is making much more sense now :-)

I assume it is OK to call my event handler (the one that does some 
processing due to the menu click) from within WndProc() itself ?

Or should I be exiting WndProc() as soon as possible ? And e.g. only set 
a flag that the menu-item has been clicked, exit WndProc() and call the 
event handler from within e.g. ApplicationEventsIdle ?

Thanks,

Kris

Kris <ks@ks.com> wrote:

>I assume it is OK to call my event handler (the one that does some 
>processing due to the menu click) from within WndProc() itself ?

That's the way it's normally done. If the work in question is going to
take so long that the UI freezes for too long, then you may wish to kick
off a thread to do its work.

Alan Bellingham
-- 
Team Browns
<url:http://www.borland.com/newsgroups/> Borland newsgroup descriptions
<url:http://www.borland.com/newsgroups/netiquette.html>      netiquette

Alan Bellingham wrote:
> That's the way it's normally done. If the work in question is going to
> take so long that the UI freezes for too long, then you may wish to kick
> off a thread to do its work.

Thanks for the confirmation.

Kris