Smartphone files article gone live

Thanks to Geoff Schwab for the heads up. My article on working with files covering Storage Cards and File Dialogs is now up in the MSDN library.


Free space on Storage Cards

You can determine the total size of a Storage Card and available free bytes using the GetDiskFreeSpaceEx API function. Below is a “mini-wrapper” around the function which returns a structure with the three return values. You’ll notice in this example I’m marshalling longs (64bit Integers), values greater than 32bit cannot be marshalled by value but can be marshalled by reference as in this case. The DiskFreeSpace struct contains three long members to hold the accessible free bytes, total bytes and total free bytes.

public static DiskFreeSpace GetDiskFreeSpace(string directoryName)
DiskFreeSpace result = new DiskFreeSpace();

if(!GetDiskFreeSpaceEx(directoryName, ref result.FreeBytesAvailable,

        ref result.TotalBytes, ref result.TotalFreeBytes))
throw new Win32Exception(Marshal.GetLastWin32Error(), “Error retrieving free disk space”);
return result;

public struct DiskFreeSpace
public long FreeBytesAvailable;

public long TotalBytes;

public long TotalFreeBytes;

private static extern bool GetDiskFreeSpaceEx(string directoryName,
ref long freeBytesAvailable,
ref long totalBytes,
ref long totalFreeBytes);


Or if you prefer Visual Basic:-

Public Function GetDiskFreeSpace(ByRef directoryName As String) As DiskFreeSpace

    Dim result As New DiskFreeSpace

    If GetDiskFreeSpaceEx(directoryName, result.FreeBytesAvailable, result.TotalBytes, result.TotalFreeBytes) = False Then

        Throw New System.ComponentModel.Win32Exception(Marshal.GetLastWin32Error(), “Error retrieving free disk space”)

    End If

    Return result

End Function

Public Structure DiskFreeSpace

    Public FreeBytesAvailable As Long

    Public TotalBytes As Long

    Public TotalFreeBytes As Long

End Structure

Private Declare Function GetDiskFreeSpaceEx Lib “coredll.dll” (ByVal directoryName As String, ByRef freeBytesAvailable As Long, ByRef totalBytes As Long, ByRef totalFreeBytes As Long)

A day of upgrades

I followed Neil and Alex‘s lead and upgraded my blog to dasBlog too. Luckily because dasBlog is an evolution of BlogX the migration was pretty smooth. I may well tweak the theme slightly yet though because I miss my roadsign 🙂

I’ve also flashed my iPaq 2210 with the latest 1.10 ROM (Thanks to Ed at Pocket PC Thoughts for the heads up). This includes a number of previous patches, sadly it has .NETCF SP1, not SP2 so that will still require a RAM install. However doing a ROM flash is always a good time to clean out the crud so my iPaq is nice and tidy (for the moment at least)

New Controls article posted

I’ve posted a new
to about hosting Native windows controls from within the
.NET Compact Framework. The approach used allows you to host the control within a
Control object and receive notification back from the control thus supporting Events.
The first control to use this technique was the HTMLViewer in the Smart Device Framework
v1.0, but this has already been supplemented with InkX and MonthCalendar controls
in our latest source code. The
bulk of the work required is encapsulated in the ControlMessageWindow so it is a fairly
quick process to implement new controls in this way.

I sincerely hope that we get some extra power in the .NET Compact Framework v2.0 such
as the ability to override the WndProc of the control itself, and built in support
for the Handle property. Of course it is only a week until the Mobility
Developer Conference
when more should become clear… I can’t wait!

A consistent way to get native window handles (HWND)

In the full desktop framework all Controls and Forms expose the Handle property which
represents the native window handle of the control – this can be passed to API functions.
In the Compact Framework this property is not implemented. In the Smart
Device Framework
 we have created the OpenNETCF.Windows.Forms.IWin32Window interface
which matches the equivalent interface on the full framework. You can implement this
interface in your custom controls and forms to provide a standard way of exposing
the window handle.

Getting the handle to any control requires just one P/Invoked API function – GetCapture
which returns the window handle of the control with capture (able to receive mouse/stylus
input). First Capture is set on the control, then this API call will return the HWND
of the control, finally capture is optionally release from the control. The GetCapture
function is implemented in the OpenNETCF.Win32.Win32Window class,
or you can P/Invoke it directly. The following code illustrates adding IWin32Window
support to your control:-


Imports OpenNETCF.Windows.Forms
Imports OpenNETCF.Win32

Public Class MyControl
    Inherits System.Windows.Forms.Control
    Implements IWin32Window

    Overridable ReadOnly Property Handle() As System.IntPtr
            Me.Capture = True

            Dim thishandle As IntPtr
            thishandle = Win32Window.GetCapture()
            Me.Capture = False
            Handle = thishandle
        End Get
    End Property
End Class


using OpenNETCF.Windows.Forms;
using OpenNETCF.Win32;

public class MyControl : Control, IWin32Window
   public IntPtr Handle
           this.Capture = true;
           IntPtr thishandle = Win32Window.GetCapture();
           this.Capture = false;
           return thishandle;

By using the Interface approach rather than adding in support for handles on an ad-hoc
basis you have a garunteed signature for your handle implementation. Therefore
if you have a method which requires a native window handle you can accept an IWin32Window
as an argument. We will be ensuring that all our OpenNETCF controls in the future
implement this interface so you can rely on the Handle property to get the native
window handle.