Click this link to check it out in the App Store:

Changelog:

• Updated required runtime to .NET 2.0
• Updated FTP library to v1.3
• Many UI updates
• Added option to keep FTP connection alive or close it after each capture
• Added option to not upload captures (just capture locally)
• Added option to archive captures, both locally and remotely on server
• Added “-capture_and_quit” command line parameter, takes a single capture and then terminates program. Useful for scripting.
• Added license

Installing the program is easy, you simply call wceload.exe and pass the CAB file path as a command line parameter. Uninstalling is also easy, call unload.exe on PocketPC 2003 or invoke the Uninstall CSP on Windows Mobile 5 with the installed application name (i.e. what shows up under “Remove Programs” on the device). However, getting the application’s name isn’t trivial and is the point of this article.

On PocketPC 2003, you can find the application’s name by doing the following:

1. Install the app via wceload
2. Iterate over the registry keys in “HKLM\Software\Apps”
3. Find the key where the CabFile value matches the path you passed to wceload
4. Once you find the key, the application’s name is the name of the key

However, things aren’t so easy on Windows Mobile 5. For whatever reason (and I can’t complain because none of this is documented), the CabFile value is no longer set when the application is installed and the above approach won’t work. After some digging, I came across the CAB format spec at:

http://support.microsoft.com/kb/310618

Using that spec, I came up with the following code to dig into the compiled CAB and find the application name. Jump straight to the example program download if you’d like.

First, declare some variables we’ll need and open a file stream:

private string GetAppName(string file)
{
	Int16 iFlags;
	Int16 iVersion;
	byte cbCFData;
	Int32 iDataBlockOffset;
	Int16 iProviderLength;
	Int16 iProviderOffset;
	Int16 iAppNameLength;
	Int16 iAppNameOffset;
	byte[] buffer;      

	string strAppName, strProvider;      

	// open the file and create a stream reader
	FileStream fs = new FileStream(file, FileMode.Open, FileAccess.Read);
	BinaryReader br = new BinaryReader(fs);

The first four bytes of the file should be ‘MSCF’:

	// make sure this is a CAB
	if (!(fs.ReadByte() == 'M'
		&& fs.ReadByte() == 'S'
		&& fs.ReadByte() == 'C'
		&& fs.ReadByte() == 'F'))
		throw new ArgumentException("File does not have appropriate signature");

Verify the CAB version is 1.3:

	// jump to offset 24 to read the format version
	fs.Seek(24, SeekOrigin.Begin);
	iVersion = br.ReadInt16();
	if (iVersion != 0x0103)
		throw new ArgumentException("Invalid CAB format");

Read the header flags and make sure it’s a header we can interpret. Depending on the version of CabWiz that was used to create the CAB, the flags will be 0 or 4(cfhdrRESERVE_PRESENT). If the reserve information is present then the cbCFHeader, cbCFFolder, and cbCFData fields are present in the header and we’ll need to skip them:

	// jump to offset 30 to read the header flags
	fs.Seek(30, SeekOrigin.Begin);
	iFlags = br.ReadInt16();      

	// we only understand flags 0x0 and 0x4
	if (iFlags == 0)
	{
		// no optional information in this header.
		// jump 4 bytes forward to the beginning of
		// the first CFFOLDER entry
		fs.Seek(4, SeekOrigin.Current);
	}
	else if (iFlags == 4)
	{
		// cbCFHeader, cbCFFolder, and cbCFData fields
		// are present.  We only need to verify that
		// cbCFData is 0, so jump forward 7 bytes and test
		fs.Seek(7, SeekOrigin.Current);      

		cbCFData = (byte)fs.ReadByte();      

		if (cbCFData != 0)
			throw new ArgumentException("Invalid cbCFData");
	}
	else
		throw new ArgumentException("Unsupported header flags");

After reading the header, we should positioned at the beginning of the first CFFOLDER, where the first field is the offset of the CFDATA block (the .000 file). Read the offset and skip the 8 byte CFDATA header:

	// we're now pointing to the start of the first
	// CFFOLDER entry.  Read the position of the CFDATA block, skipping past
	// its 8 byte header.
	iDataBlockOffset = br.ReadInt32() + 8;      

	// jump to the data block
	fs.Seek(iDataBlockOffset, SeekOrigin.Begin);

According to an explanation of the .000 file (http://www.cabextract.org.uk/wince_cab_format/#000_format), the first 4 bytes of the .000 file should be ‘MSCE’:

	// we should now be pointing at the ".000" file, whose
	// signature is "MSCE"
	if (!(br.ReadByte() == 'M'
		&& br.ReadByte() == 'S'
		&& br.ReadByte() == 'C'
		&& br.ReadByte() == 'E'))
		throw new ArgumentException("Invalid .000 format");

84 bytes into the .000 header, we’ll find the application name length and offset and the provider name length and offset:

 	// we're looking at a valid .000 file.  We need to look up the
	// AppName and Provider Length/Offsets.  These values start at
	// position 84 in the .000 header, so jump 80 bytes (we're already
	// 4 bytes into the header).
	fs.Seek(80, SeekOrigin.Current);      

	iAppNameOffset = br.ReadInt16();      

	iAppNameLength = br.ReadInt16();      

	iProviderOffset = br.ReadInt16();      

	iProviderLength = br.ReadInt16();

The final step is to jump to the offsets and read the values:

	// now jump to the AppName offset and read it
	fs.Seek(iDataBlockOffset + iAppNameOffset, SeekOrigin.Begin);
	// convert from ASCII and don't include the null terminator
	strAppName = ASCIIEncoding.ASCII.GetString(br.ReadBytes(iAppNameLength - 1));      

	// jump and read the Provider string
	fs.Seek(iDataBlockOffset + iProviderOffset, SeekOrigin.Begin);
	// convert from ASCII and don't include the null terminator
	strProvider = ASCIIEncoding.ASCII.GetString(br.ReadBytes(iProviderLength - 1));      

	br.Close();
	fs.Close();      

	return strProvider + " " + strAppName;
}

Downloaded a total of 111 times

Here is the CSS and HTML that will exhibit the behavior in IE7:

CSS:

body
{
 font-family: Arial, Verdana, Sans-Serif;
 font-size: 100%;
 color: #000;
 background-color: #fff;
}

.bodycontainer
{
 width: 100%;
 font-size: 0.8em;
}

.menu
{
 width: 100%;
 background: #404040;
 float: left;
}

.menu ul
{
 margin: 0;
 padding: 0;
 list-style-type: none;
}

.menu li
{
 margin: 0px;
 padding: 0.25% .5%;
 float: left;
 background: #404040;
 border-style: solid;
 border-width: 0px 1px 0px 0px;
 border-color: #fff;
}

.menu a
{
 font-weight: bold;
 color: #fff;
}

div.clsBreadCrumbTrail
{
 clear:both;
 padding: 10px 5px;
 border-bottom: solid 1px #999;
 border-top: solid 1px #999;
 font-family: Tahoma;
 font-weight: normal;
 text-align: left;
 background-color: #eaeaea;
 color: #000;
}

HTML:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<link rel="stylesheet" type="text/css" href="style.css" />
</head>
<body>
 <div id="someid" class="bodycontainer">
 	<div id="NavMenuPage" class="menu">
 		<ul id="menuitems">
 			<li><a id="foo" href="somelink">Some Menu Item</a></li>
 		</ul>
 	</div>
 	<div id="bct" class="clsBreadCrumbTrail">
 			<a href="somelnk">Home</a> > <span class="clsCurrentPage">Job Board</span>
 	</div>
 </div>
</body>
</html>

It turns out that Internet Explorer 7 has a bug where a float followed by a clear that has a background specified causes IE7 to add the padding-top value twice. IE6, Firefox, and Safari all work correctly.

There are several ways to work around this bug and get rid of the extra padding, you’ll have to see which works best for you:

• Specify the <div> as “display: inline-block” (credit)
• Nest the <div> that specifies a background inside a <div> that specifies the clear

I went with the second work-around because although the first worked in IE7, it caused the background to be cut off in Firefox.  You could also use conditional comments to give specific CSS to Internet Explorer 7, but it’s best to avoid that whenever possible.

Then, I upgraded to Leopard and found that this particular Sleep Display widget no longer worked.  This was a bummer.  I Googled around and found an application that did what I wanted, but I really wanted a dashboard widget and this was a great excuse to play with both Xcode and Dashcode and make it myself.

You can get the new widget at http://www.chriskarcher.net/software/displaysleeper.

p.s. After writing and publishing the widget, I found that you can easily sleep the display in Leopard by pressing Ctrl-Shift-Eject

So, here’s what it looks like:

At first glance, it doesn’t look intrusive. But when you start updating the HTML regularly and the progress bar pops up every time, it starts to look out of place. It would be nice if MS just exposed an option to disable it, but they don’t. We’re going to have to do some work ourselves to get rid of it.

First, some background. In my application, I created a UserControl named WebBrowserPanel. WebBrowserPanel has a single WebBrowser child control which is anchored Top, Right, Bottom, and Left. It has the following constuctor to make it use all the available space:

public WebBrowserPanel()
{
    InitializeComponent();       

    WebBrowser.Width = this.Width - 2;
    WebBrowser.Height = this.Height;
}

Putting the WebBrowser inside a user control lets us give it a border and, as you’ll see later, will be crucial for this fix to work.

Using the Remote Spy tool that ships with VS 2005, we can examine the window structure of the application on the Windows Mobile 5 emulator:

The “MSPIE Status” window, a child of the “IExplore” window, looks interesting. Inspecting its properties shows us that it’s 23 pixels tall, and likely the progress bar we’re looking to hide. If we can get our hands on its window handle we can try to move, resize, or manipulate it in some other way to hide it. To get its window handle, I wrote the following function:

public static IntPtr FindHwndByClass(string strClass, IntPtr parentHwnd)
{
    StringBuilder sbClass = new StringBuilder(256);
    if (0 != GetClassName(parentHwnd, sbClass, sbClass.Capacity) && sbClass.ToString() == strClass)
        return parentHwnd;       

    IntPtr hwndChild = GetWindow(parentHwnd, (int)GetWindowFlags.GW_CHILD);
    while (hwndChild != IntPtr.Zero)
    {
        IntPtr result = FindHwndByClass(strClass, hwndChild);
        if (result != IntPtr.Zero)
            return result;       

        hwndChild = GetWindow(hwndChild, (int)GetWindowFlags.GW_HWNDNEXT);
    }       

    return IntPtr.Zero;
}

We can pass in “MSPIE Status” as the class name and look for it as a child of the WebBrowser.

Now that we have the handle, we can try to hide it. My initial attempts to hide the progress bar included using SetWindowPos to move the bar off the screen, resize it to one pixel high, and a number of other hacks that didn’t work. As a last resort, I tried the ultimate: DestroyWindow. After initializing the WebBrowser in WebBrowserPanel’s constructor, I would find the status bar window and destroy it. This seemed to work, kind of. As you can see below, there are about 20 pixels of whitespace at the bottom of the browser, noticeable when you have enough content to need scrollbars:

Not good, but easy enough to work around. After we get the progress bar handle we can get its window height. After we destroy the window, we can resize the WebBrowser to be this much taller than its parent panel, thus clipping off this whitespace.  WebBrowserPanel’s constructor now looks like:

public WebBrowserPanel()
{
    InitializeComponent();

    WebBrowser.Width = this.Width - 2;
    WebBrowser.Height = this.Height;

    IntPtr hwndStatus = FindHwndByClass("MSPIE Status", WebBrowser.Handle);
    if (hwndStatus != IntPtr.Zero)
    {
        RECT rectStatus = new RECT();
        GetClientRect(hwndStatus, out rectStatus);

        DestroyWindow(hwndStatus);

        WebBrowser.Height += rectStatus.Height;
    }
}

And we end up with:

Success! You can now set the DocumentText any number of times without the progress bar showing up.

The code presented above makes use of the following PInvokes and enums:

[DllImport("coredll.dll")]
public static extern int GetClassName(IntPtr hWnd, StringBuilder lpClassName, int nMaxCount);

[DllImport("coredll.dll")]
public static extern IntPtr GetWindow(IntPtr hwnd, int cmd);

public enum GetWindowFlags : int
{
    GW_HWNDFIRST = 0,
    GW_HWNDLAST = 1,
    GW_HWNDNEXT = 2,
    GW_HWNDPREV = 3,
    GW_OWNER = 4,
    GW_CHILD = 5,
    GW_MAX = 5
}

[DllImport("coredll.dll")]
public static extern bool DestroyWindow(IntPtr hwnd);

[StructLayout(LayoutKind.Sequential)]
public struct RECT
{
    public int X;
    public int Y;
    public int Width;
    public int Height;
}

[DllImport("coredll.dll")]
static extern bool GetClientRect(IntPtr hWnd, out RECT lpRect);

Downloaded a total of 505 times