Archive for the ‘Int*rm*c’ Category.

Mobile Development – Compact Framework: Managed Extension Framework (MEF)


this post describes a way to load class libraries (DLLs) dynamically on demand in your compact framework application.

What is it good for?

Hardware abstraction. Load only matching Libraries.

Organize your development for different devices. You will be able to only load the right hardware (device) dependent libraries. You are able to use a hardware abstraction layer.

Normally, you add a reference to an assembly during development in Visual Studio. Now, when the application starts on the device, it will try to load this assembly. If it contains hardware dependent code, like a barcode scanner library, the load of your application may fail.

Using the techniques described here, you can avoid this and direct your app to only load device matching libraries.

Plugin usage

You can write a Compact Framework application that will load and work with plugins. These reside in DLLs and can be added or removed on demand.

You can for example write an application launcher that will list the installed extensions. In example for a Transport and Logistic application you can have a truck loading and a truck unloading extension. If you have to update one of the plugins, you only need to replace the plugin DLL, the rest of the application (for example Login forms, Information screens, connection management) remains unchanged.

DLL loading in C/C++

Loading libs dynamically is well known in C/C++. You simply use LoadLibrary(dllName) and then you can get the addresses to known library functions and use these.

Static linking: Adding a reference in a compact framework (SmartDevice) application inside Visual Studio is like adding a header and lib file to a C/C++ application.

DLL loading in Compact Framework

You can also use the above in C#/VB.NET.

[codesyntax lang=”csharp”]

namespace ConsoleApplication1
  class Program
    static IClass1 GetIClass1(string filename)
      Assembly classLibrary1 = null;
      using (FileStream fs = File.Open(filename, FileMode.Open))
        using (MemoryStream ms = new MemoryStream())
          byte[] buffer = new byte[1024];
          int read = 0;
          while ((read = fs.Read(buffer, 0, 1024))>0)
            ms.Write(buffer, 0, read);
          classLibrary1 = Assembly.Load(ms.ToArray());
      foreach (Type type in classLibrary1.GetExportedTypes())
        if (type.GetInterface("IClass1") != null)
          return Activator.CreateInstance(type) as IClass1;

      throw new Exception("no class found that implements interface IClass1");

    static void Main(string[] args)
      IClass1 class1 = GetIClass1("ClassLibrary1.dll");


[source:], may not work without change in CF.

Continue reading ‘Mobile Development – Compact Framework: Managed Extension Framework (MEF)’ »

Windows Mobile – the no-go world of Function Keys


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

KeyWedge: Updated


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
                    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);

                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");

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

Remote Desktop Mobile on VGA devices: QVGA applications do not scale well


there are now more and more full VGA rugged devices coming. And some customers are still using Remote Desktop Mobile to run there application on the small screens. Unfortunately some of the coders use application screen layouts hard coded to QVGA (240×320). Now with a VGA capable Windows Mobile device they get weird screens on the device.

The client (Remote Desktop Mobile) sends the server information about there screen sizes. As a VGA device can display 480×640 pixels, the hard coded 240×320 applications only use a quarter of the screen. The texts are very small and more or less unreadable.

Continue reading ‘Remote Desktop Mobile on VGA devices: QVGA applications do not scale well’ »