Kevin Daly

Overriding project item SubType for Pocket PC .NET CF Forms with non-standard form initialisation code.

Definitely a long and tedious title that one. 'Tis a dark and stormy morning in what passes for late summer here in Wellington (February used to be the best month...today is freezing and there's lashing rain and howling gales...atmospheric but crappy)

One of the recommended optimisations for Compact Framework applications is to customise the code that sets up UI elements in the InitializeComponent method (you know, the bit with the comment saying “ Do not modify the contents of this method with the code editor“). The specific optimisations are detailed in this article on the not-particularly-active Smart Devices Developer Community site. The awkward aspect of this approach is the “we told you not to modify the contents of this method with the code editor” effect - if you ever touch the form in the designer again it resets to default values. Basically your UI disappears. Some would say that is Not A Good Thing.

Fortunately, this can be prevented by changing the SubType of the form entry in the project's .csdproj file (if you're using C#) from “Form” to “Code”. You can't use the designer, but at least your code stays put.
Except...I recently learned from Neil Cowburn of OpenNETCF.org that if you add any new item to your project  the SubType tends to change itself back to “Form”. Not nice.

What's worse is that I've found there is not an obvious, simple pattern to this...sometimes it does it, and sometimes it doesn't.

So I'm creating a lot of dummy projects and fiddling with them. I'm tabulating the results in a spreadsheet...and I hate spreadsheets (while useful tools in themselves, they're on the slippery path that leads to Gantt charts and other crimes of management). I'm determined to get to the bottom of this for the good of mankind.

What would be better of course, would be an add-in that would add a precompile step to the build process for Compact Framework projects to parse the InitializeComponent method and apply optimisations, and then insert the modified version in the input stream to the compiler. That way you'd get the best of both worlds, since you'd compile with the optimised version but work with a VS-friendly version in the designer.

I don't know whether applying the recommended optimisations programmatically is possible, although it seems possible for it to be, er, possible. Multilanguage support would be tricky, but that might be possible through CodeDOM (makes me wish I'd learned something about CodeDOM). The really tricky bit from the standpoint of my vast willful ignorance of the internal workings of Visual Studio.NET is how to insert this extra step into the build process and have its output replace the contents of the actual form. I am pretty certain from what I have read that this would be possible with MSBuild, but then I'd hope that with the Whidbey version of smart device projects the need for it will go away anyway.
So in the meantime I'm back to my icky spreadsheet - the precompiler thing sure would be a neat trick though.