Compact Framework and the Visual Studio Designer

Lately it seems that I’m been doing a lot of posts referring to “a customer”.  Often they are different customers, but it really sounds impersonal, so in this one I’m going to name names and point fingers – in a friendly way, of course.

Last week Nicolas emailed me to get some advice on the Visual Studio 2008 Forms designer and the Compact Framework.  Specifically he wanted to know if it’s possible to get a custom TabControl to be designable.  My assumption is that either he’s inheriting from the stock version or they’ve created a fully custom control inheriting from ContainerControl – I didn’t ask because in either case the answer is simple: it’s not going to work in the designer.

I told him that it won’t work, but in retrospect I feel I’ve short-changed him a bit.  As a developer, I like to hear a bit more than an “abandon all hope, ye who sail here for there be sea monsters” kind of response.  Why doesn’t it work?  More importantly, what are my options for a workaround?

In this case it’s interesting to note that even if he could get the designer to work for this control, I’d recommend that he not do it.  And they why to that recommendation is far more interesting.

So, Nicolas, here’s the longer answer to your question.

First, you have to understand that the Studio Designer is very, very brittle.  Any little quirkiness tends to send it into fits, and once broke you often spend large amounts of time unloading things, resetting the toolbox, restarting Studio or even restarting the PC.  This is a huge time drain, so avoiding situations that break the designer is the first order of business.

Getting the designer working for a CF component is even worse.  CF controls often make use of things that the desktop doesn’t even have, which the designer really hates.  You also have to build the Controls for both versions of the CF (for Nicolas this is important since, at least last time I was with his team, they had versions of the application targeting CF 2.0 and CF 3.5).  A control built against CF 3.5 will never show up in the designer of a CF 2.0 project.  There’s also a major bug in the designer that limits CF 3.5 controls that I’ve written about before.

For designer support you also have to maintain an XMTA file and often end up having condition compiler statements which really make the code less readable.  Workarounds for most of these issues exist.  You can create separate set of “designer” assemblies that provide only stuff for the designer and minimal actual control logic.  The problem with this is that you then have to maintain these things, which sucks up developer time that should be spent actually solving your business problem.

You can’t create a desktop assembly and use it for the designer because the designer will then suck in the full .NET framework as a reference and attempt to deploy that to the device when you want to debug.

So if the designer is so brittle and worthless, what’s a developer to do?  Well, my general attitude is to provide “support” only for basic Controls, and by “support” I mean the inherent capability of the designer to show a box with the location and bounds of your control.  No rendering.  No styling.  No collection editing. 

Really the designer’s primary use for me is to aid in basic layout.  I need to put a Control on a Form, set it’s location and Size and that’s it anyway.  Anything else is done via code, and there’s nothing wrong with this.  Embrace it as how you must work and your life becomes much simpler.

That’s all well and good for a simple Control, but what about a container like Nicolas is after?  His team would like to be able to drop on a Tab control and design each individual Tab, right?  So what are they to do?

Well, I think they’re looking at the problem wrong to begin with.  I don’t blame them, people have been looking at this wrong for some time, and the simple existence of the TabControl tend to push people to look at it wrong.  In general, my recommendation is to not use the TabControl in the first place. 

First of all, it’s 2011.  That ass-looking TabControl would have been ok back in 1995 (if the devices had existed then) since it looks just like the ass-looking Windows 95 interface. 

It’s was an ok solution in 2000 when these devices were new and people thought of them as just “mini PCs” so extending the desktop paradigm to the device was what we did.    Yes, we wished we could do a little more to make it pretty by adding icons and custom drawing, but it worked and users really didn’t expect anything more.

But it’s 2011.  Users don’t use a stylus if they can avoid it.  They know an elegant UI when they see one because they’ve been using a smartphone.  Just because they have no choice in the app they use (this is an LOB app, so the user is locked in) is no excuse to not deliver something that is actually nice to use.  The TabControl does not meet that.  It’s tiny, it scrolls weird, and it’s ugly with no options to make it non-ugly.  Plus it’s  Tab motif.  Name the last mobile app you used on a phone that used tabs.  That’s what I thought. Abandon the piece of crap.

So what would I use?  Obviously this will be subjective, as it’s what I would personally do given a blank slate.  Nicolas is trying to put something into an already-existing, very large code base, so his mileage may vary, but I’m betting it won’t be too bad, and implementing this might actually do a lot toward getting other gains they really need like better transition time between views.

I’d start using the OpenNETCF IoC project.  I’d split each of the existing “tabs” into individual SmartParts, which are now fully designable since they’re just UserControls.  So there you are – the designer requirement is solved.  I’d then place on the Form a pair of DeckWorkspaces.  One would display the “selected” view and the other would replace the “tabs” of old with buttons or clickable images that would be used to select the current view.  It would look something like this in the designer for the Form:

tabs

And then the SmartPart that goes into the bottom workspace might be something like this in the designer (well it would probably be a bit different, but you get the idea):

tabs2

See, the designer works.  It meets the business requirement that it provides a “tab-like” capability where the user selects an item across the bottom and the upper view changes.  But now it’s not just usable with a stylus but it’s also likely to be usable with a finger (gasp!) and aesthetically it doesn’t make my want to poke my own eyes out.  It’s a win-win.  Plus now you can lazy-load the views *on demand* rather than loading up every damned control on every tab when the Form is brought up, so the user is going to be pleasantly surprised there too.  Oh, and now it’s easy to change out “tabs” based on user rights or workflow and probably other benefits that I’m not thinking of.

Occasionally we’ve got to break out of the “what we know” and the “what we’ve always done” routine and look out at the horizon.  By doing so we can often make some simple changes and make things easier for both the developer and the user, and that is how we make progress.

4 thoughts on “Compact Framework and the Visual Studio Designer”

  1. Totally agree, the best way of using Tab control on mobile device is just avoid using Tab. But what about ListView control? Usually we set View property to View.Details and when there are a lot of items into the ListView it is also very uncomfortable to scroll the list by fingers due to it is designed for stylus. Do you have any ideas how to improve the ListView and make its using as comfortable as it is for smartphones?

    Like

  2. @wince: ListViews are a different beast. They really are more suited to stylus/mouse usage than they are for a touch type interface. For apps that would need something along those lines we typically just use a layout of custom controls that make each row a custom "button" of sorts, which can contain aligned data to simulate columns. We then have an up and down button for scrolling (a gesture would also work). An owner-drawn listbox might also work.

    Like

  3. I agree, using buttons instead of row lines might be OK when we need one-column ListView.
    You said "a gesture would also work", do you mean that there is a possibility to use gestures with Windows CE 5/6? Do I need any third-party library for gestures support?

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s