Link Copied
JIMB@GEMINISI.COM:
1) How might I attach Ctrl-C (or others) to my menu commands? In the Windows API example of "Creating a Run-Time Accelerator Table", the example always has a handle for the existing accelerator table which is revised and then (automatically) reloaded. How can I obtain the handle to the accelerator table of QuickWin?
Yes, classic accelerators are out in QuickWin, as you don't have a place to put TranslateAccelerator into. Instead, use a keyboard hook, and just call appropriate menu handler routine when you detect the appropriate key combination. See this old thread for a sample.
To indicate the shortcut in the menu, separate it with a tab ("t") character in menu title. For example:
"&Open Ctrl+O"
2) How do I capture the mouse event click of theclose icon on the caption bar for a safe shutdown?
You have to subclass the frame window (SetWindowLong(GWL_WNDPROC)) and catch the WM_CLOSE. See this thread with a sample.
My MainWndProc only does explicit processing of the WM_INSTALLHOOK message, in which case it returns 0. In the case of any other message, it returns DefWindowProc. Should it instead be returning the call to lpOldWndProc? In any case, why should the SendMessage FUNCTION cause the system to hang?
Yes, it should return CallWindowProc(lpOldWndProc...) indeed. But, are you sure it is ever entered? Place a breakpoint in CASE(WM_INSTALLHOOK) and check it out. Are you sure it doesn't hang in the hook function instead? I can't tell offhand, but I can imagine that it can screw up the application badly; make sure you properly call CallNextHookEx from the hook function. (and don't forget !DEC$ATTRIBUTES STDCALL for the wndproc and the hookproc)
I had not realized that SetWindowsHookEx was only capable of capturing Ctrl+* keyboard events. This is what I need to do, so it is not a problem.
Um, it isn't supposed to be so. You should get all the keyboard messages (actually, all the WM_KEY** messages before they reach the message loop).
Now, about the hanging: don't forget to call CallNextHookEx from your KeyboardProc (see the Return Value section); I kind of recall the problems when I forgot to do it (although it was some 5-6 years ago).The other issue is that you come to get the "Program Terminated with exit code..." message at all. Normally, a QuickWin PROGRAM should end in an infinite loop, like:
DO
CALL SLEEPQQ(0)
END DO
In this way, (and thanks to the two-threaded structure), the program will sit idle in the loop and all the events will happen in the "primary" thread (the one driving menus, your WndProc, KeyboardProc etc.), and the program can be closed only through the
CASE (WM_CLOSE)
SELECT CASE(MessageBox(hFrame,"Save changes to Foo?"C, &
"Close"C,MB_YESNOCANCEL))
CASE (IDYES)
CALL SaveDocument()
FrameWndProc=CallWindowProc(lpfnOldFrameProc,hWnd,Msg,wParam,lParam)
CASE (IDNO)
FrameWndProc=CallWindowProc(lpfnOldFrameProc,hWnd,Msg,wParam,lParam)
CASE (IDCANCEL)
FrameWndProc=0
END SELECTThis works fine for both Ctrl+C and
I still don't know what went wrong with the hook, but you can use it only to emulate "other" accelerators.
As far as getting keyboard messages, you are correct. I do get all input from the keyboard. So how might I capture Ctrl+C as opposed to C.
if (GetKeyState(VK_CONTROL) < 0) then
will tell you if the Ctrl is pressed.
