Just a post to let you know, that RDM_KeepBusy for WM6.5 has been updated

Hello

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");
      class1.DoSomething();
    }
  }
}

[/codesyntax]

[source: http://social.msdn.microsoft.com/forums/en-US/clr/thread/093c3606-e68e-46f4-98a1-f2396d3f88ca/], may not work without change in CF.

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

Hello

on the wish of the one or other user I extended the RDP AutoLogin code and we now reached level 4.

The new code simply has only one extension, it supports the color depth selection. Also the color depth and other settings are visible on the dialog of Remote Desktop Mobile, the settings itself are done via the Default.rdp file. But you are right, RDP_AutoLogin also controls some of the dialog items directly.

[codesyntax lang=”text”]

...
Domain:s:
ColorDepthID:i:3
ScreenStyle:i:0
DesktopWidth:i:640
DesktopHeight:i:480
UserName:s:rdesktop
...
ServerName:s:192.168.128.5
SavePassword:i:1
...

[/codesyntax]

The color depth setting supports two modes, 8 Bit with 256b colors (ColorDepthID:i:1) and 16 Bit with ~65000 colors (ColorDepthID:i:3).

[codesyntax lang=”reg”]

REGEDIT4

[HKEY_LOCAL_MACHINE\Software\RDP_autologin]
"FitToScreen"="1"
"FullScreen"="1"
"Status"="connecting..."
"Save Password"="1"
"Domain"=""
"Password"="Intermec+2004"
"Username"="rdesktop"
"Computer"="192.168.0.130"
"DesktopWidth"=640
"DesktopHeight"=480
"startOnExit"="\\rdp_keepBusy.exe"
"execargs"="noRDPstart"
"UseMouseClick"="0"	//added with version 3 to switch between mouse and keyboard simulation
"ColorDepth"=1		//added with version 4 to enable switching between 8 and 16 Bit colors

[/codesyntax]

The code changes are small. Some code addition to read the value from the registry and some to write the rdp file:

[codesyntax lang=”cpp”]

void readReg(){
...
        //ColorDepth new with version 4
        if(RegReadDword(L"ColorDepth", &dwTemp) == 0)
            dwColorDepth=dwTemp;
...
}
void writeRDP(){
...
			else if(wcsstr(rdpLines[c].line, L"ColorDepthID")!=NULL){
				wsprintf(szTemp, rdpLines[c].line, dwColorDepth);  //3=HighColor(16Bit) or 1=(8Bit) color
			}
...
}

[/codesyntax]

Additionally I have added a new project to the solution to enable to set all the settings not only via the registry but using a GUI application. RDP_Autologin_Settings is born:

Continue reading ‘Mobile Developement – RDP AutoLogin extended (version 4)’ »

Tasker2 is a tool to launch or kill applications periodically using windows mobile scheduler. It was born to control the running of agent software on windows mobile at specified times. The problem with the agent software was that it does not open/close connections only on usage times but all the time and the device’s battery was drain very fast. We decided to write a helper that would launch and kill the agent to have it running only within a defined time frame.

Background process

We could have written a background process to run external tasks periodically. But the main disadvantage of timers and threads in background processes is that they do not run, if the device is in suspend mode.
To ensure that tasks will be launched also if the device is sleeping, we decided to use the windows mobile scheduler. There are functions inside the notification API to create notifications that will run an application at a specified time. This is what we call a schedule.

The scheduler (notification API)

After a timed schedule has been done by the scheduler, the schedule is removed from the notification database. If you like to have a periodic schedule, you have to ensure that a new schedule is created inside your code.

Pitfalls

During development we found many pitfalls in conjunction with the windows mobile scheduler. This is why I decided to write this post.

The tasks

Tasker2 is a console application without any GUI but it will write a log with all you need to know. Tasker2 supports up to ten tasks. A task is defined using the registry. Every task has an entry for start and stop times, the application to control, an interval for the schedule and a flag for control if a task is only to be run on external power:

REGEDIT4

[HKLM\Software\Tasker\Task1]
"active":DWORD=1
"exe":="\Windows\fexplore.exe"
"arg":="\My Documents"
"start":="1423"
"stop":="1523"
"interval":="2400"
"startOnAConly":DWORD=0;

active: if active is 0, tasker2 will not kill or start the process
exe: name of the process executable to start or kill
arg: arguments to be when launching the executable
start: when to start the executable the next time
stop: when to kill the process the next time
interval: when a start or kill has been executed, tasker2 will create a new schedule using this interval. If the interval is “0010”, the start process will be scheduled for every 10 minutes.
startOnAConly: if 1 and when a process has to be started, the process will only be started if the device is on external power

The scheduler

First, tasker2 is normally only launched one time manually and all future calls are made by the scheduler. Tasker2 will clear and schedule all planned tasks as defined in the registry if it is launched without arguments.

Continue reading ‘Windows Mobile – tasker2 runs and stops applications periodically’ »