Windows CE Programming

Recently I stumbled about this great article about ASCII, 7 and 8 Bit, codepages, Multi byte, Wide byte and unicode: http://www.joelonsoftware.com/articles/Unicode.html

If you ever get in trouble with wrong encoding display of chars, give this article a try to know the backgrounds.

As you know, Windows CE and Windows Mobile  is always unicode except for serial and socket communication. But the truetype fonts available on Windows Mobile devices mostly support only common chars, there file size is about 600K. The file size of Arial Unicode MS is about 22MB.

regards

Bookmark It

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’ »

Bookmark It

If you are running a kiosk mode app but need to provide the camercapture dialog on Windows Mobile 5 or later, you may need to disable the one or other click in the CameraCapture dialog.

This article uses a technique known as subclassing as already used and decribed in my StartButtonHookWM65 article. For the CameraCapture dialog the code has been revised and you can now subclass any known window class and disable clicks within the Windows Mobile menu bar.

        private string _winClassName = "HHTaskbar";
        public string winClassName
        {
            get { return _winClassName; }
            set {
                if (this.oldWndProc == IntPtr.Zero) //only allow change before subclassing
                    _winClassName = value;
            }
        }
...
        /// <summary>
        /// SubClassing: Install the wndproc hook
        /// </summary>
        /// <returns></returns>
        private bool hookWindow()
        {
            //find the window to hook
            IntPtr hWndHooked = FindWindow(_winClassName, IntPtr.Zero);
            if (hWndHooked == IntPtr.Zero)
                return false;
            //enable the taskbar, not realy necessary
            EnableWindow(hWndHooked, true);
            //already installed?
            if (oldWndProc == IntPtr.Zero)
            {
                //find the menu_worker window
                IntPtr hwndMenu_Worker = FindWindow("menu_worker", IntPtr.Zero);
                if (hwndMenu_Worker != IntPtr.Zero)
                {
                    //get the child window which has the buttons on it
                    IntPtr hwndToolbar = GetWindow(hwndMenu_Worker, GetWindow_Cmd.GW_CHILD);
                    if (hwndToolbar != IntPtr.Zero)
                    {
                        _mHwnd = hwndToolbar;       //store to remember
                        SubclassHWnd(hwndToolbar);  //subclass the wndproc
                    }
                }
            }
            return true;
        }

As the call to CameraCaptureDialog will block and you can not subclass it before it is launched, I use a timer that will subclass the dialog assuming it will show after the call to .ShowDialog().

        private System.Windows.Forms.Timer timer;
        hwndutils subClassUtils;
        private void ShowCamera()
        {
            CameraCaptureDialog cdlg = new CameraCaptureDialog();
            cdlg.DefaultFileName="picture.jpg";
            cdlg.InitialDirectory = "\\My Documents";
            cdlg.Mode = CameraCaptureMode.Still;
            cdlg.Owner = this.pictureBox1;
            cdlg.StillQuality = CameraCaptureStillQuality.High;
            cdlg.Title = "Take a picture and Select";
            cdlg.Resolution = new Size(240, 320);
            cdlg.VideoTypes = CameraCaptureVideoTypes.All;

            //subclass main window with delay
            subClassUtils = new hwndutils();
            timer = new Timer();
            timer.Interval = 1000;
            timer.Tick += new EventHandler(timer_Tick);
            timer.Enabled = true;

            DialogResult dRes = cdlg.ShowDialog();
...
        void timer_Tick(object sender, EventArgs e)
        {
            subClassUtils.winClassName = "Camera View";
            subClassUtils.CloseButtonDisabled = true;
            System.Threading.Thread.Sleep(500);
            if(subClassUtils.CloseButtonDisabled)
                timer.Enabled = false;

        }

In the line “subClassUtils.CloseButtonDisabled = true;” the subclassing (or the hook) will be activated and clicks on (OK) will not be accepted.

Code subclassing.cs download: DOWNLOAD:subclassing.cs - subclassing code for C# compact framework (Hits: 156, size: 2.4 kB)

Bookmark It

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:vectors.py - (Hits: 173, size: 570 bytes)):

[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’ »

Bookmark It