Running Device Emulator in XP Mode

If the frustration of VS2008 corrupting some of the VS2005 SDKs isn't enough to burn your butt, it's just a warm-up exercise to getting the Device Emulator working in Windows 7's XP Mode.

The first month of isolating VS2008 and VS2005 by installing one of them into XP Mode Virtual PC (VPC) was certainly disappointing. VS2008 didn't want to cooperate at all. So I did the next best thing: installed VS2005 there instead. It was a long and boring process to get VS2005, its service packs and a bunch of SDKs installed, but it worked without much pain. It even compiled some code. But launching a device emulator was a different story.

On connecting to the Mobile 5 Pocket PC Emulator device, which I use regularly for testing, the computer just stared blankly at me for a few minutes before declaring:

Cannot connect to device. Error: 0x8007064a

Try a web search for that. Mwa-hah-ha!

Anyway, the short story and the two-part solution. I finally found some obscure and easily overlooked references from people who had similar experiences.


Part One. Visual Studio won't open the project.

1. Open the solution. Visual Studio complains: "The project file cannot be loaded. The application for project ... is not installed.". Shutting down VS and restarting does nothing.


2. Right-click the project (which offers no information about why it fails. Other than some stupid message about "platform not available" or something moronically insulting like that. It's all BS - the SDKs are installed.


3. Select Reload project.


4. Watch with anger and puzzlement as VS loads the project correctly this time. Shoot me.

Part Two. The device emulator fails when running in XP Mode. I followed Brian Peek's useful guide to replacing the missing Microsoft network adapter, Windows Virtual PC and the Microsoft Device Emulator, which may have helped solved other future problems. For the emulator error, the article Cannot connect to device. Error: 0x8007064a was helpful.

1. Launch the emulator by trying to connect or by executing in with or without debugging. VS complains: "Cannot connect to device. Error: 0x8007064a".


2. Terminate the Device Emulator Manager.


3. Rename the Folder "CoreCon" (in "Documents and Settings\Application Data\Microsoft\") to "xCoreCon".


4. Start the Device Emulator (list of devices is now empty).


5. Terminate the Device Emulator.


6. Rename "xCoreCon" back to "CoreCon".


7. Now the emulator works. Shoot me and the computer.

Is Microsoft running the US Congress? Maybe that's the problem. Well, at least Solitaire still works.

Visual Studio 2005 & 2008 side-by-side incompatibility

The short story:
VS2005 and VS2008 will not co-exist peacefully.

The long story:
After several fruitless days trying to create an environment for developing an application for the Windows CE 5.0 platform using Visual Studio 2008, I had to admit defeat. The reason is, when Visual Studio 2008 is installed on a system that has Visual Studio 2005 already, it clobbers the Windows CE 5.0 platform so it cannot be used by either IDE. No complaints, no warnings, just gone.

Microsoft contends that VS2005 and VS2008 can be installed and will work side-by-side. What they did not document - typical for MS - is that certain platforms not only are incompatible between the two, but are also disabled for both. The Standard Windows CE 5.0 SDK is one of those platforms that is disabled when VS2008 is installed. I haven't had time to find out what additional platforms may be affected.

It's not an operating system issue. I develop on a Windows 7 machine. My co-worker uses Windows XP. Both of us experienced identical problems.

My objective was to install VS2008 to work on a project I had inherited where a back-end database application had already been written as a VS2008 project. I wanted to create a Windows CE 5.0 application using the same IDE. Silly me, always expecting "new and improved" tools to work as advertised.

VS2005 with the Standard Windows CE 5.0 SDK was already installed and working fine, as I had just completed another project with that exact combination. Install VS2008. See Windows CE 5.0 platform disappear. Did installing with Administrator Privileges work better? Nope. Uninstall, reinstall, uninstall, reinstall without Documentation = No joy. Jump up and down on keyboard, smash fist through monitor, throw laptop through front window - *sigh* just wishful thinking.

Last resort, uninstall VS2008. Gee, that worked; now I had my Windows CE 5.0 platform back in VS2005. So I couldn't use VS2008 for my new project. In summary, VS2005 and VS2008 can co-exist, but only if they are on separate machines. :-/ I was burned by Microsoft marketing hype yet again.

And they want me to upgrade to VS2010. Hahahahahahaha!

Using Crystal Reports Basic for VS2008 with VS2005

I had a client for whom I developed a project in Visual Studio 2005. The reports were written for the bundled version 10.2 of Crystal Reports (CR). The application was to be installed on the client's server that already had a number of applications that were using the later Crystal Reports version 10.5 (bundled as Crystal Reports Basic for Visual Studio 2008), a newer version.

Anecdotal evidence showed it was possible to use a version of CR other than what was bundled with VS2005. Unfortunately, no hard documentation existed that defined or instructed one on how to do so. These notes are what I pieced together after a week of intense research and trial & error.

The first thing that must be done is to create and test reports with CR v10.2 that is bundled with VS2005. Easy, right? Of course I'm being sarcastic.

The next step is to install the CR v10.5 runtime package. These can be acquired from several places, the official one being the Crystal Reports page on the SAP Community Network web site. Another source is Visual Studio 2008 Pro, if you have it handy. The x86 package, though, is hidden deep in the bowels of the installation: C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages\CrystalReports10_5\CRRedist2008_x86.msi. Install it on your machine; I've encountered no problems with it co-existing with CR v10.2.

Depending on your architecture, you need one of these setup packages:
   CRRedist2008_ia64.msi (64 bit Itanium)
   CRRedist2008_x64.msi (64 bit Intel)
   CRRedist2008_x86.msi (BootStrapper)

In your project, make a list of all references to the CR assemblies and remove them. Here comes the fun part. You can't simply add references to the new assemblies. From a command prompt, go to your %windir%\assembly directory. You will find GAC, GAC_32, and GAC_MSIL directories there. Inside those are subdirectories for each version of the Crystal Reports assemblies on your machine. Copy the 10.5.* version of the DLLs to a folder you create within your project: I called mine CRRedist2008.

In your project, add references by browsing to your CRRedist2008 folder and selecting the same assemblies as were in your original list. Why the copying? Visual Studio does not allow adding references to assemblies in the General Assembly Cache. You need separate files so VS lets you add them as references to your project.

One more step: if you check the reference properties, you may still see the v10.2 assembly being referenced. Set the Use Specific Version property to True to force VS to use the v10.5 assembly you added as a reference.

Recompile and your reports should now run with the VS2008 version of the Crystal Reports libraries.

Barrel of fun, huh?

Updating the MDI parent menu icon for maximized child form

While working on a C# .NET program recently, I ran up against an infamous (and another apparently long-standing) bug in Microsoft's Multiple Document Interface (MDI) architecture. When a child form has been maximized, and its window icon is updated, the icon that is merged into the MDI parent's menu strip is not updated to reflect the change.

I was using the child window icon to identify the document type being displayed and to mark when it had been modified. Everything worked fine when the window was open in Normal mode, but the icon stopped being updated when the child was maximized to fill its parent's client area.

After literally days of searching the web to see if anybody else solved the problem, I found answers ranging from "impossible" to "keep track of your own windows" (a.k.a. the old roll-your-own interface standby). Digging through the layers of classes with the debugger, I figured out a hack that seems to work.

Here's the basis of my solution: when a child window is maximized, the controls on its title bar are merged with its parent window. The parent menu inserts an image as its first element that is a copy of the child window's icon. The image (a Bitmap image) is copied only at the time the child is maximized, and is never updated afterward, regardless of calling Refresh(), Update(), Invalidate(), etc. So, to get around this missing functionality, my solution was to check the parent menu when I changed the icon of the child window; if it had an image in its first element, I converted the Icon into a Bitmap and replaced the image. It may sound hokey, but it worked.

These are the steps I used for updating the icon. I raised an event to update the parent form.

// Change the child icon according to the document state.
// Called from a method in the child form.
int newState = this.GetChildState();
this.Icon = (newState == 0) ?
myProject.Properties.Resources.savedicon :
myProject.Properties.Resources.modifiedicon;

// ...raise event to notify the parent. sender is the child form.

// Change the parent menu icon when child is maximized.
// Called from an event handler in the parent form.
if (MainMenuStrip.Items[0].Image != null)
{
// Copy the new state icon from the child window.
MainMenuStrip.Items[0].Image = ((Form)sender).Icon.ToBitmap();
}

The MDI architecture has its quirks. This is just a way to get around one of them. I think this is an inelegant solution to an inelegant problem, but sometimes you just have to be practical.

RichTextBox.SelectedRtf property has incomplete documentation

The Microsoft documentation for this property is missing critical information (there's a shock, huh?). It explains use of the property in terms of text. It's not text that is being used here, it is a completely formatted document. That document is extracted from or integrated into the complete document stored within the RichTextBox control.

If used to insert text, the assigned string must be a correctly-formatted RTF document (even a minimal document will work) or it will throw a System.ArgumentException error, with the unhelpful inner message of "File format is not valid", especially maddening when not working with files.

To illustrate an incorrect and correct use of this property, in the example code snippets below, myRtfControl is an instance of the RtfTextBox control.

Example that fails:

myRtfControl.Select(myRtfControl.TextLength, 0); // Set caret to append

text.myRtfControl.SelectedRtf = "\ul underlined text\ul0";

// ^ Throws System.ArgumentException

Example that works:

myRtfControl.Select(myRtfControl.TextLength, 0); // Set caret to append

text.myRtfControl.SelectedRtf = "{\rtf1\ul underlined text\ul0}";

// ^ Adds underlined text as expected.

Note that for an empty selection, SelectedRtf actually contains the following document:

{\rtf1\ansi\ansicpg1252\deff0\deflang1033\uc1 }

The text consists of a single Unicode space character "\uc1 ". It's this "empty" document that assignment will replace.

Gathering this information came at the expense of several days of wasted time poring through tangential examples on the web (and some peeled wall paint from cursing bad documentation). Thanks to those intrepid pioneers.

For further reference, a link to the Rich Text Format Specification, version 1.6 can be found at http://msdn.microsoft.com/en-us/library/aa140277%28office.10%29.aspx.

Happy document bug hunting!

MobileLPR - LPR client for.NET Compact Framework 2.0

I recently wrote a client library for Windows CE/Mobile devices, giving them the ability to print to a network printer. The library and article, MobileLPR - LPR client for.NET Compact Framework 2.0 - CodeProject, are usable under The Code Project Open License (CPOL).

The library allows printing to network print servers implementing the LPR, LPRng, and SocketAPI (direct socket connection) printing protocols. LPR and SocketAPI are venerable and widely-used on all major platforms. Since most contemporary printers offer built-in network printing using one of these protocols, this library is a great addition to your mobile developer's tool belt.

I've been going to the Code Project web site for years. It is a nice place to learn and contribute!