Keyboard Hooks and Menu Activation
I have an edit control descended from TCustomPanel. I am using a keyboard hook to process the input (a global variable referencing the currently focused control tells it what to do, if anything, with the input - this is set by the overridden DoEnter and DoExit methods). Everything works as expected until you start dealing with objects outside the parent form.
As a fix for multiple forms, I added a check for Screen.ActiveControl to the hook procedure. I'm not entirely sure how well that works, and there is still a problem with menus / shortcuts. Ignoring the Alt key will allow a menu to activate, but afterwards, the control still gets the input instead of the menu.
I suppose it would be pretty easy to place code elsewhere such as the form of the menu to deal with it, but I want the control to be completely autonomous and not place any such requirements with the user.
As a fix for multiple forms, I added a check for Screen.ActiveControl to the hook procedure. I'm not entirely sure how well that works, and there is still a problem with menus / shortcuts. Ignoring the Alt key will allow a menu to activate, but afterwards, the control still gets the input instead of the menu.
I suppose it would be pretty easy to place code elsewhere such as the form of the menu to deal with it, but I want the control to be completely autonomous and not place any such requirements with the user.
My approach would be to have a routine that sets a global variable to the handle (or name?) of the control that currently has focus. All controls would need to have some code in their GotFocus event.
ASKER
pramodbugudai: I read that article before I started the thing.
aikimark:As you will see from my original post, that is exactly what I am doing (using a global variable to reference the focused object).
You both appear to have missed the point of the question, I want to SUSPEND the hook when something else needs the focus such as a menu. The problem is that Delphi doesnt provide adequate notification of focus changes outside of a form, and I cannot find any decent information on how to do it via the windows api.
aikimark:As you will see from my original post, that is exactly what I am doing (using a global variable to reference the focused object).
You both appear to have missed the point of the question, I want to SUSPEND the hook when something else needs the focus such as a menu. The problem is that Delphi doesnt provide adequate notification of focus changes outside of a form, and I cannot find any decent information on how to do it via the windows api.
I'm still confused about the nature of this problem. I'd done some reading along these lines:
http://delphi.about.com/od/vclusing/a/coloringfocused.htm
http://www.daniweb.com/forums/thread109568.html#
But now I'm not sure whether the focus is transferring to a different form within the same application, a different application, or just some other controls on your form. I'm going to continue monitoring this thread. If I learn enough about your problem, I might be able to contribute to its solution.
http://delphi.about.com/od/vclusing/a/coloringfocused.htm
http://www.daniweb.com/forums/thread109568.html#
But now I'm not sure whether the focus is transferring to a different form within the same application, a different application, or just some other controls on your form. I'm going to continue monitoring this thread. If I learn enough about your problem, I might be able to contribute to its solution.
ASKER
I really don't know how much more simly I can put it.
- The control itself and the associated keyboard hook work perfectly.
- Changing focus to another control in the same form works perfectly because the correct methods are triggered, allowing the global variable to be set to either an instance of my edit control or to NIL.
- Changing focus to a control in another form does NOT result in these methods being invoked (this is an issue with the behaviour of Delphi). Some extra code in the hook function to check Screen.ActiveControl partially solves this problem.
- The one issue that I don't have a solution for is when something like a menu is activated. If, for example I tell the hook function not to process the alt key, then the menu is activated, but from that point onwards, the control still thinks it has focus, so if you select a menu option with the keyboard, you will get a text echo in the control. No events are fired for this and even the Screen.ActiveControl check fails here.
- This control is intended to be redistributable so what I need is a solution that does not require any external code from the user (for example setting the variable in the menus activation would solve the problem right away but this is NOT acceptable - it has to be completely self-contained).
- The control itself and the associated keyboard hook work perfectly.
- Changing focus to another control in the same form works perfectly because the correct methods are triggered, allowing the global variable to be set to either an instance of my edit control or to NIL.
- Changing focus to a control in another form does NOT result in these methods being invoked (this is an issue with the behaviour of Delphi). Some extra code in the hook function to check Screen.ActiveControl partially solves this problem.
- The one issue that I don't have a solution for is when something like a menu is activated. If, for example I tell the hook function not to process the alt key, then the menu is activated, but from that point onwards, the control still thinks it has focus, so if you select a menu option with the keyboard, you will get a text echo in the control. No events are fired for this and even the Screen.ActiveControl check fails here.
- This control is intended to be redistributable so what I need is a solution that does not require any external code from the user (for example setting the variable in the menus activation would solve the problem right away but this is NOT acceptable - it has to be completely self-contained).
ASKER
I should add that it also needs to regain focus when the menu or whatever closes. The only references I have found are to the messages WM_ENTERMENULOOP and WM_EXITMENULOOP. Adding methods to listen for these doesnt seem to work - plus the object in question might not be a menu - it can be anything activated by a keyboard shortcut.
ASKER
Increasing points...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hmm - at first glance it looks like hes just encapsulated the functionality in an object. There are a few things in there that I haven't come across and that I can look into, so I'll cancel the delete request for now and get back to you :)
ASKER
Hmm - at first glance it looks like hes just encapsulated the functionality in an object. There are a few things in there that I haven't come across and that I can look into, so I'll cancel the delete request for now and get back to you :)
ASKER
Sorry for the extreme delay with this - I havent been able to devote any more time to it due to work etc.
Pramodbugudai: Yours has been the most comprehensive answer so the points are yours.
Pramodbugudai: Yours has been the most comprehensive answer so the points are yours.
http://delphi.about.com/od