I didn’t do much today with Project Resistance, but that didn’t stop progress. Alex got all of the background paionting ironed out today while I was screwing around with paying work. It looks pretty nice (well, except for the lower workspace, which is awaiting artwork):
I did do some thinking on the broader process of developing WinMo apps, though. One thing that most Windows developers (as well as a great many devs for other OSes) have come to rely on is the good old WYSIWYG editor for Form/Screen/View layouts. Generally speaking, they’ve been around for a good while now and not counting that major backslide called Visual InterDev, they’ve done a pretty good job of presenting a design time what you see at runtime.
Well for everything except Smart Device projects. We at OpenNETCF have been building controls and libraries for devices since before we were a company. We’ve seen all the iterations of Microsoft’s tools (all the way back to the add-in for VB 6 in fact). Never has designing a Form in the tool been easy once you go past the basic Label, Textbox and Button UI.
Since Studio ’03, to get any form of custom control to render properly you had to do a whole load of extra work. And to make matters worse, how you had to do it seems to have changed with every new release of Studio, meaning you have to re-do a lot of the work for existing controls to get the new tools to support them. I think this is one of the reasons there are so few 3rd-party vendors doing nice controls (especially with any sort of designer support). To make thigs even worse, trying to support just the current tool runs into bugs almost immediately.
So what do those of use who build these apps day-in and day-out do? Well we live with a rectangle, or a series of them, in the designer and do all of the actual layout by iterating with a device or the emulator. So the run-time view you see above looks like this in the designer:
Fancy, eh? And what, you ask, is the upper “DeckWorkspace”? Well it’s a container object from the OpenNETCF.IoC framework. It basically holds a UserControl, which is what that resistor image is. It, similarly, gives you very little as design time:
Yes, this is the state-of-the-art. If you’re coming to device development from the desktop, be prepared to be a bit frustrated. Could we have added designer support for the resistor to this project? Sure. But I bet it would take more than twice the time we have already into the entire project just to get it to render, and even then it would come with caveats (like it would work with CF 3.5 but not 2.0 projects or similar silliness).
So the moral of the story is that you just get used to it. Unless you plan to be a control vendor don’t bother wasting your time even trying to get designer support working. You’ll only end up frustrated, behind schedule, and with a load of convoluted code that you’ll have to rewrite the next time Microsoft releases a new version of Studio. Maybe things will change in VS10, but based on the track record I seriously doubt it.
Don’t take all of this as being completely down on Studio though. As far as a development tool it’s still the best thing out there (well it’s not so great for C++, but that’s another diatribe – just do yourself a favor and get SourceInsight for that). I’ve used a lot of tools, and Studio, by far, is the most stable and feature-rich tool that I’ve ever used. It’s just that there’s still a lot of room for improvement.