Dag König has posted an example to his blog showing how to add Sms sending to your application using the OpenNETCF.Phone.Sms class and just 4 lines of code – check it out.
Blog
-
New version of .NETCF GDI+ Library
XcrossOne Studio have just released a new v1.2 release of their incredible looking GDI+ library for .NETCF. A key change in this release is a switch to a Shared Source license, similar to what we use with our OpenNETCF projects.
This means that you are no longer restricted to releasing any works using the code in source form, this should have a dramatic effect on the number of people able to use the library. You can achieve some pretty impressive visuals, as demonstrated in the large gallery of samples on the site. This latest version adds the ability to combine raster images and anti-aliased text with the vector based drawing.
-
CLS Compliant WaitForSingleObject
Maartens recent blog post highlighted an issue with the current SDF implementation of Core.WaitForSingleObject when used from VB.NET since this method was not CLS Compliant and used unsigned integer types for both parameters and return type. Because of the values used by this function its very easy to convert it to be CLS compliant, so from the next release you’ll be able to call it just as easily from both C# and VB. The method only accepts a timeout value up to 0x7fffffff which incidently is the maximum positive value for an Int32. The exception to this is a special constant passed when you want to wait indefinately on a handle – 0xffffffff which just happens to be -1 when interpreted as a signed integer. The same transformations are posible on the Wait enumeration which is the return type for the method. The amended code is already up on the online source browser. Therefore to wait with a 1s timeout on a handle in a loop you can now do this from VB:-
While WaitForSingleObject(myWin32Event, 1000) <> Wait.Object
‘do stuff here
End While
-
Toggle Bluetooth on an iPaq device
We can already enable and disable Bluetooth on devices equipped with Microsoft’s Bluetooth stack. In the case of iPaq devices, which use the Widcomm stack, it is possible to toggle the radio state using an API provided in HP’s iPAQUtil.dll. This can be P/Invoked from a .NETCF project like so:-
[DllImport(“iPAQUtil.dll”, SetLastError=
true)]
public static extern bool iPAQSetBlueToothRadio(ref int lpdwValue);
Which you can then call with:-
int
val = 0;
iPAQSetBlueToothRadio(
ref val);
Where val is either 0 to disable Bluetooth, or 1 to enable it. Tested on an iPaq 2210 but should work on any other iPaq device with Bluetooth.
Update:-
The following should also work for devices with WiFi built in:-
[DllImport(“iPAQUtil.dll”, SetLastError=
true)]
public static extern bool iPAQSetWLANRadio(ref int lpdwValue);But I’ve not been able to test this myself. -
From the Mobility Road Show
Thom Robbins posts some Powerpoint slides and code from the recent Mobility Road Shows. Check out “Mobility and Visual Studio 2005” for a good overview of NETCF 2.0 development features.
-
Hosting a Native Windows Control – The desktop approach
Following Neil’s recent post on my control hosting article, I realised that the article had not gone into detail on the differences between the Control class in the full framework and Compact Framework. The Control class in the full .NET framework is incredibly powerful, and when I built the ControlEx class to enable hosting I tried to work to the same model where possible. Generally the Compact Framework follows the design of it’s larger cousin and therefore if the functionality of the Control class is enhanced in future revisions of the Compact Framework it will likely follow a subset of the desktop functionality.
There is a key difference with the Control class on the desktop, than any custom Control derived class on the Compact Framework. On the desktop you can override the protected CreateParams property to force the control to create any window class (remember that in Win32 terms any control is considered a window with it’s own unique handle and based on a specific window class). It’s possible to create an intrinsic windows control like the SysAnimate32 with almost no need to resort to Platform Invoke. If you view the running program with a tool like Spy++ you’ll see the SysAnimate32 window is a direct child of the form it sits on. We can pass it messages entirely in managed code by simply calling it’s WndProc method. The Handle property for the control is the handle for the SysAnimate itself.
On the Compact Framework this behaviour is only true for the standard set of Controls in System.Windows.Forms. For all other controls a standard window class is created (and this we have no control over), any native window class we wish to use must be added as a child to this window. However the next main hurdle with the .NETCF Control class is that there is no WndProc method we can override, so if we create a window as a child of this control, we have no way of capturing it’s window messages (Unless we capture them in the application message loop itself using ApplicationEx). Therefore to implement a WndProc for the control we use an additional layer.
The MessageWindow class is specific to the Compact Framework and serves only one purpose, it allows us to receive messages within managed code. By default the MessageWindow is a hidden 0x0 pixel window. With some P/Invoke magic it is possible to alter the size and position of the MessageWindow to make it a visible control – this is our empty canvas. We now create the native window as a child of this window and we have a native control, housed within a managed control with the ability to both send messages to the control and, most importantly, receive notification messages and process them.
There are a few house-keeping chores required to keep this three-layer solution working. Whenever the control is resized we must resize both the child (MessageWindow) and grandchild (native control) to fit. In order to hide as much of this plumbing as possible, and to avoid re-inventing the wheel, the ControlEx class was built to do all this work for you. Like the Control class on the desktop it exposes a CreateParams property which you can override with your class type. Notification messages received from the native control by the MessageWindow are passed to the OnNotifyMessage method of the ControlEx. It’s not quite as powerful as the full WndProc of the desktop but it allows us to receive events such as item selections within the native control. The WebBrowser sample within the article download uses these to expose events when the user taps a link.
The HtmlViewer, MonthCalendar and InkX controls within SDF v1.2 are all built using this technique, however they use a less transparent approach to the new ControlEx class. I’ll be upgrading these to use the ControlEx class, and of course you can use the class yourself to wrap other native windows controls of your choice.
You can download a sample “Trash It!” project here which is a desktop .NET project which wraps the SysAnimate32 control to display a delete animation. The only P/Invoke required is LoadLibrary / FreeLibrary to load the dll containing the AVI animation resource. This should provide some contrast with the WebBrowser class in the article.
-
Hosting a Native Windows Control – Live on MSDN
My latest .NETCF article is now live in the MSDN library. This is an update of the control hosting article previously published here at OpenNETCF.org. The process has been simplified so that there is now a standard base class (ControlEx) which does most of the hard work for you, the process of hosting a control is therefore much closer to the desktop experience. The article contains a sample using the WebBrowser control, which shows not only setting properties and calling methods for the control, but also reacting to notifications from the native control.
-
Virtual Bob
Virtual PC is a great tool when testing and developing as you run multiple OS versions and configurations on a single machine. However Ben Armstrong has found a more unusual use for Virtual PC – to run Microsoft Bob, the short-lived home oriented shell around windows 3.11 / 95. See the full story including nostalgic screen-shots here on Ben’s blog.
-
Open All Hours
Sometimes you want to ensure that the system will not automatically close down your application when it goes into the background. You can achieve this by handling the Closing event of your main form, the event arguments passed to your handler will allow you to Cancel the close. Therefore you can set a boolean member to ensure that the operation only succeeds once you decide it’s okay to close:-
bool keepopen = true;
private
void Form1_Closing(object sender, System.ComponentModel.CancelEventArgs e)
{
if(keepopen)
{
e.Cancel = true;
}
}
Then based on some pre-determined action in your program you can set keepopen to false and the form will close down.
-
The Naked Emulator
If you want to display the standard Pocket PC emulator without the regular skin, so just the screen itself is shown you can modify a couple of the settings files and skin bitmaps. For the default Pocket PC 2002 emulator you’ll find the files here by default:-
C:Program FilesMicrosoft Visual Studio .NET 2003CompactFrameworkSDKConnectionManagerBinImagesPocketPC20021033
Make a backup before you alter anything!
Then replace the ppc2002.xml file with this one. Finally add this image to the folder which is the null skin, necessary in order that the emulator window is sized correctly. The finished result should look like this:-
In The Hand Ltd 
