Windows CE Programming

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 would like to start a series of articles of how you can lockdown your application user in your application. How can you achieve a kiosk mode application, where the user is only allowed to do what you define.

The first article is about the Windows Start and Done Icon in menu bar and about fullscreen. You may already know, how to hide the start and done icon permanently from a Windows Embedded Handheld (Windows Mobile 6.5.3) device: Link

But there is also a temporary way using the same approach. The trick is to change the registry keys, that make the OS believe you have hardware buttons for Start and Done, BEFORE you show your CSharp form.

Before Windows Embedded Handheld (WEH, or Windows Mobile 6.5.3), you are able to use SHFullScreen API calls. But this will not work with WEH. Neither the flags SHFS_HIDESIPBUTTON nor SHFS_HIDESTARTICON will work. The LockDown.cs class also includes code for that and you may test the functions with the Test-Application.

The class I am talking about is called LockDown. There is also a Test-Application (OEMTitleBarHandler, dont ask me about the name selection) to test all functions I will describe.

Continue reading ‘Windows Mobile: Kiosk Mode Series, part 1’ »

Here is a simple application to connect to a serial port. The idea is based on the need of having an application to send demo print files to a virtual comm port connected to a bluetooth printer.

Update 16. March 2011: Added dialog to connect to BT printer by BT Address on Intermec devices. New source and binary at code.google.com.

Update 21. March 2011: Splitted source code and providing three different flavours:
CommAppCFSerial does serial comm only.
CommAppCFbtSearch provides BT connect (Intermec Devices only) and BT discovery
CommAppCF itself is a unstable working release
see code.google.com/p/win-mobile-code … Executables are in bin subdirs.

You can enter and send texts to or send a whole file to the port. Additionally you are able to send ASCII codes by using \xAB syntax, where AB is the hex code of the byte you would like to send.

There is nothing special with the code except the hex decoding/encoding and the possibility to send a file.

Continue reading ‘Mobile Development – Simple serial communication application’ »

Hello Readers

it has been a long time since my last post, I was a little bit busy.

This time I want to present some experimental code to visualize and analyze G-Sensor data. The goal was to achieve a shake detection algorithm. Unfortunately the device under test only provided 1 sample per second and that is not enough for a good shake detection. Beside that the code and classes developed may help you to find your way and they help you at last to determine the current orientation of the device.

left shows general information taken from vector, right shows a log with last vector data

[image SensorScan5_0102.gif]

[image SensorScan5_0304.gif]
left shows graphical of vector and force (length), right shows indicators for detected events

A g-sensor or accelerometer sensor normally gives you the x, y and z-values of a vector. A vector is an imaginary arrow with a direction and length starting from the three dimensional point 0,0,0. The vector direction points to the acceleration of the device. The normal acceleration on earth is 9,81m/s^2. If the device is on the desk, the y-acceleration is about minus 9.81m/s^2. The absolute value of the sensor may vary on the sensor and maybe defined as 1.0 for -9.81m/s^2 or -0.981. If you through the device up to the air, the x,y and z-values will reach 0,0,0 as if the device is weightless. Keep in mind that the acceleration towards the middle of the earth is always there and the device will come back to you.

Here is another visualization of the vector and a device (done with visual python, [Download not found]):

[image vectors.gif]

The device is facing upwards (see y arrow) with the top facing to you (the z arrow). The left side of the device is pointing to the right (the x arrow).

The light green/blue and the yellow arrows demonstrate two different vectors which show the direction (the xyz angles) and the force (the vector lengths) to the device.

Continue reading ‘Mobile Development – Shake that thing’ »