Understood. Not applicable. Repeat:

>> Different user roles access the software simultaneously.
>> Eg a supervisor may open the cash dawer for a clerk.

Explain further:

The role of the logged-in user is irrelevant.
A transaction is in progress.
The customer is tapping his foot. Retail operations must be quick.
The clerk does not have authority to open the cash drawer.
We cannot suspend the transaction and log in as someone else.
The supervisor needs to enter a password for the clerk to permit a
one-time override of this normally disabled function.

Can we forget the situation and address the question?

Is there a way to intercept the windows WM_COMMAND message, and from that
determine which instance of TMenuItem has been clicked?

When I ask, "or is there a better way", I am wondering if an ActionList
can be applied here, but I have no experience with those, and find the
documentation difficult to grasp.

I understand how to disable and enable menu items. Thank you.

Regards


> What has been suggested is that after login, you change the
> enable/disable  or Visible/Invisible state based on the role of whom
> ever logged in.
> Doug
>
> [EMAIL PROTECTED] wrote:
>> Oh, sorry.
>>
>> This is a retail application.
>> Different user roles access the software simultaneously.
>> Eg a supervisor may open the cash dawer for a clerk.
>>
>> Actions cannot be disabled, they may be used by an appropriate role.
>> Or they may require this one-time authentication which I now seek to
>> add.
>>
>> Menu items are password protected rather than disabled.
>>
>> This is a retrofit job. I am looking to intercept WM_COMMAND in
>> Application.OnMessage and wondering how to map any part of that windows
>> message back into an instance of TMenuItem.
>>
>>
>>
>>
>>> Or, if you prefer, you could hide them: Visible:=False;
>>>
>>> Glenn Lawler
>>> www.incodesystems.com
>>>
>>> -----Original Message-----
>>> From:       Smith David G (Finance) [SMTP:[EMAIL PROTECTED]
>>> Sent:       Monday, September 15, 2008 3:02 PM
>>> To: [email protected]
>>> Subject:    RE: [delphi-en] How to intercept all menu events?
>>>
>>> Why not just disable the menu items the user is not permitted to use --
>>> set the Enabled property to False?
>>>
>>> -----Original Message-----
>>> From: [email protected] [mailto:[EMAIL PROTECTED] On
>>> Behalf Of [EMAIL PROTECTED]
>>> Sent: Monday, September 15, 2008 2:15 PM
>>> To: [email protected]
>>> Subject: [delphi-en] How to intercept all menu events?
>>>
>>>
>>> Existing D5 application now needs security. Most of "security" involves
>>> protecting access to menu items.
>>>
>>> I would like to implement this without bloating the code, adding lines
>>> for every menu OnClick handler.
>>>
>>> There is already an Application.OnMessage handler in the code. I
>>> thought
>>> I might add a handler for WM_COMMAND, intercepting menu clicks at that
>>> point. Yet nothing in the TMsg structure seems to point me back to a
>>> specific menu item.
>>>
>>> I see all menu items have automagically been assigned CMD ids, yet
>>> these
>>> are not available in the data received by Application.OnMessage.
>>>
>>> What do I not understand, or is there a better way to intercept all
>>> menu
>>> clicks for an existing application...?
>>>
>>> Thank you.
>>>
>>>
>>>
>>
>>
>>
>> ------------------------------------
>>
>> -----------------------------------------------------
>> Home page: http://groups.yahoo.com/group/delphi-en/
>> To unsubscribe: [EMAIL PROTECTED] Groups Links
>>
>>
>>
>>
>>
>>
>
>
>


Reply via email to