How do I identify Menu item click in Visual Foxro 9.0?

Well I don't know about your package but the way I did it in mine is I reset the variable when an access privilege or audit trails function gets called. That means the user is active.

If you have a form class, you can reset it in the load or init event of the form class instead of the menu click.

In my case, every time a menu is clicked, instead of directly starting a form, a procedure is called with the form name as one of the parameters.

Actually, its something like this..

Not all menu selections raise a form for me... Some execute prg's...some trigger events..blah blah....So..I need a variable that is SET when a menu selection is made...I would reset it when a form is opened with the menu selection in the form's base class Init() method..This way, by looking at the variable I would know that menu was selected but no form was opened....So..for all this..I need a handler that can capture menu selection using BINDEVET()...Only question is..How do i do that?

I would leave the check on WM_MENUSELECT. When user moves a mouse over the menu items it means he is active, he is on computer, and he can read a message you'll send to his computer.

Inactivity logout should be forced if nobody is on the computer.

When I have to call a PRG or raise an event, I still put it in a forms init event and RETURN .F. at the end. That way I get it in a subclassed form which makes it easy for precisely such updation.

The method seems to have 2 parameters returned. Do the values of MF_HILITE and MF_MOUSESELECT give you any information.

I second pcelba,

if it's all about useractivity, there is no reason to neglect mousemoves hovering over the menu. And your WM_COMMAND solution also seems ok: If a user clicks a Yes/no messagebox, he's active too. So what's your problem with that?

Otherwise you can define your menu with procedures instead of commands and in the procedure for a menu item always call your last activity timer reset code as the first command.

If you don't want to go through all the menu items, search the VFP help for MenuHit scripts.

Bye, Olaf.

Thanks for all your comments...

It seems I have confused all the experts mentioning about my event handler... :(
Actually...WM_COMMAND has nothing to do with the last activity in my scenario. I wanted to explain that there is already an event handler to capture the last activity in my application and that I want to re-use the same for another requirement.

REquirement:
-------------------------
I have set of existing menus. For few menus clicks, a form gets invoked and for a few a prg is exected without any form displayed. So I need a global variable looking at the value of which I should be able to determione if the menu click resulted in a form invoke or not.

So what I did was, in my form's base class Init(), I keep setting a global variable to TRUE say (isFormInvoked = .T.). Suppose a menu click directly invokes a prg without invoking a form I need the variable value (isFormInvoked) .F.

i cannot keep resetting this value in all the prg's that are invoked from menu as it is very tedious and I have some 20-30 programs and this solution is not re-usable.

So what I thought was to capture WM_COMMAND event in my event handler (as per VFP help, WM_COMMAND is fired on a menu click) and reset the global variable isFormInvoked = .F., is not form is invoked with a menu click, this variable value will be sustained as Form's Init() is not executed and just by looking at this variable I can determine if a menu click resulted in a form invoke or not...

The problem here is that WM_COMMAND is fired even while clicking 'Yes/No' buttons on the message box. I want a way to determine if WM_COMMAND that I was capturing was actually fired due to menu click or NOT. How do i do it?? :((

I am confused also. You've been asking for auto-logoff feature...

It sounds strange if the menu click means "user activity" but MessageBox button click does not mean it. What are your criteria for auto-logoff feature? And if you need auto-logoff then how do you solve already mentioned MessageBox sitting on the screen and suppressing any other code execution? Are all your message boxes timed out?

OK, now we are talking about form existence on the screen... I am sure you can do some work around...

E.g. You can store _Screen.FormCount somewhere and if this number changes then you know the form was invoked. Also if your forms are based on your own form class (it is a must in OO environment) then you have just one place where you need to check if the form was initiated or not.

The menu selection shouldn't call the form or PRG directly but it should call your own MenuClickHandler - some PRG with parameters saying what to do next. Such PRG can easily do the work you need and much more, e.g. application auditing.

BTW, WM_COMMAND should send different parameters when called from menuclick or massagebox button click.

I think it would be easier to modify the menu itself like I described: Make all menu items a proceudre instead of a command (at least the ones calling a prg) and in that procedure do set IsFormInvoked = .F. and don't look for a more elegant solution. 20-30 menu items or prgs is not such a big list.

The other way I mentioned with the MenuHit scripts in fact is for the IDE, I haven't investigated, if that is one of the things also working wih a distriuted foxcode.dbf, but if, then it would be what you're searching, something being done at each menu item click.

Bye, Olaf.