iHookIE6

this small tool enables you to use Function keys within Internet Explorer Mobile (IEM) web sites.

Normally, most function keys are catched and used by the OS (GWES) to perfom special actions like menu softkeys, phone call, end phone, volume up, volume down and more.

Using a keyboard hook we can catch the function key presses, or better say WM_KEYDOWN and WM_KEYUP messages before the OS can catch them.

One challenge was to find the window that processes normal key presses. The keyboard windows messages are not send to the top level window. Using the Remote Spy Tool I found the Window inside Internet Explorer window that finally processes keyboard messages. Now the tool can hook the keyboard, catch F key presses (F1 to F24) and send them directly to the browser window (class name = “Internet Explorer_Server”). The tool simply uses FindWindow and GetWindow to locate the window handle of this window and then does a PostMessage with WM_KEYDOWN and WM_KEYUP directly to the browser window.

Continue reading ‘Windows Mobile: redirect function keys into Internet Explorer Mobile browser’ »

Before WEH and Windows Mobile 6 it was easy to catch all keys including the function keys in a Compact Framework (CF) application, you simply had to use Allkeys(true) and Form.Keypreview=true.

Actually, with Windows Embedded Handheld (WEH) or Windows Mobile 6.5.3 the above will not work for the F1 and F2 key. There are simply no KeyDown and KeyUp events reaching your CF application.

Windows Mobile 6.1 demo

with IMessageFilter active, F1 and F2 can be captured

After removing IMessageFilter no F1 and F2 keys are being captured

With WEH Microsoft moved the Start button from the taskbar at top to the menu bar at bottom. Further on, the menu bar is now using graphic tiles to display the top menu, the Close and OK/Done option. The OK/Close button also moved from taskbar to menu bar. Additionally the menu bar is higher than in Windows Mobile 6.1. That leaves less space for your client window.

Due to the above changes in the UI, the window messages are routed in another unknown way and normally a CF application does not get F1 and F2 key messages. Possibly the CF main message queue gets notification messages but these are handled internally by the CF runtime, you only see the menus are working.

Continue reading ‘Windows Mobile: CF how to catch F1 and F2 in WEH’ »

Hello

I want to summarize the role of function keys in Windows Mobile, former Pocket PC, as I got several questions each week on how to use or enable Function keys in this or that application.

Here is a simple information about how function keys work in Windows Mobile.

Continue reading ‘Windows Mobile – the no-go world of Function Keys’ »

Hello

at KeyWedge I posted my code that connects to a serial port and then simulates keystrokes into your application.

Now, there were issues where the reconnect did not automatically take place after a Suspend/Resume and you had to invoke the main window and select File-Hide just to let KeyWedge reconnect. This happens on devices that provide the communication port all the time and dont close it during a suspend.

I have added some code to watch the Windows Mobile Power Message Queue for RESUM messages and then do an automatic reconnect. The other option would have been to send some data thru the port periodically to check if it is still working. But this may disturb the attached the device.

The main change is in PowerMsgQueue.cpp. It implements the msg queue to receive power broadcast messages like done in a MSDN example code. If a resume message is encountered, the code sends a WM_USER message to the main window, which will do a SuspendComm/ResumeComm cycle. Very easy.

In PowerMsgQueue.cpp we have code that recognizes the resume:

                case PBT_TRANSITION:
                    nclog(L"Power Notification Message: PBT_TRANSITION\n");
                    //Add2Log(L"Power Notification Message: PBT_TRANSITION\n",TRUE);
                    nclog(L"Flags: %lx\n", ppb->Flags);
                    nclog(L"Length: %d\n", ppb->Length);
                    wsprintf(szPBtype, L"trans.: ");
/*
Flags: 12010000
Length: 6
trans.: ON|PASSWORD|BACKLIGHTON|
*/
                    if(ppb->Flags & 0x12010000)
                    {
                        nclog(L"PwrMsgQueue: got 'ON|PASSWORD|BACKLIGHTON'...\n");
                        //send a message to main window
                        iPost = PostMessage(hwndMain, WM_USER_RESUMECOMM, 0, 0);
                        nclog(L"PostMessage WM_USER_RESUMECOMM returned %i\n", iPost);
                    }
                    break; 

                case PBT_RESUME:
                    nclog(L"Power Notification Message: PBT_RESUME\n");
                    //Add2Log(L"Power Notification Message: PBT_RESUME\n",TRUE);
                    wsprintf(szPBtype, L"resume: ");
                    //send a message to main window
                    iPost = PostMessage(hwndMain, WM_USER_RESUMECOMM, 0, 0);
                    nclog(L"PostMessage WM_USER_RESUMECOMM returned %i\n", iPost);
                    nclog(L"Power: PBT_RESUME\n");
                    break;

To not block the queue, I use PostMessage to inform the main window of the Resume. Here is the simple code block in WndProc of the main window:

Continue reading ‘KeyWedge: Updated’ »