Mar 222005

While Allen waxes poetic about imagining VCL.NET on mobile devices before CF existed, I’ll take credit for being one of the main forces against pursuing VCL.NET/CF.  I continue to be skeptical, but also hopeful.  That combination should keep Allen and Seppy on their toes for awhile.

The biggest reason not to pursue VCL.NET/CF is that it will resemble VCL.NET in name only.  The user interaction model of small devices, phones in particular, is so radically different from the desktop experience that there is no point in even talking about migrating GUI applications from the rich desktop to the skimpy little phone.  It won’t work.  Period.  UI for mobile devices must be built for the device form factor.  Just like WinForms/CF. (And just like Symbian Series 60.  And Series 70.  And Series… well, you get the point)

On the other hand, there is a lot to VCL.NET which is not UI related.  Units such as SysUtils or Classes won’t suffer from the UI form factor differences between desktop and mobile devices, but they will still be affected by OS services that are simply not present on the small devices.  Most of the missing OS bits fall into the “legacy“ bucket.  Things like support for short file name paths on the desktop are only there because 8.3 used to be the limit of everything and some apps still have 8.3 filename assumptions.  It doesn’t make sense for Windows CE to have to support the old MSDOS / 16 bit Windows shortcomings.

I have no doubt that VCL.NET/CF will have just as many caveats and missing pieces compared to VCL.NET as WinForms/CF has compared to WinForms on the desktop.  We might do a better job of maintaining continuity between the desktop and mobile device platforms than WinForms has, and choose different tradeoffs toward that goal.  But that alone is a very weak differentiation point upon which to base sales and woo developers to use VCL.NET/CF instead of WinForms/CF.

So if VCL.NET/CF would have many of the same limitations as WinForms/CF, and won’t benefit by migration of existing VCL applications, why bother implementing VCL.NET/CF?  That is the reason I’ve been against VCL.NET/CF… until recently.

Why the Change of Heart?

The simplest way for Borland to produce GUI design tools for the CF platform is to license existing materials – specifically, license the CF design surface from Microsoft.  As discussed in my earlier post, that doesn’t look like it’s going to happen.  That leaves two options:  Build a WinForm/CF designer from scratch, or adapt the Borland VCL.NET form designer to target a modified VCL.NET built for CF.

This looks like a choice between building one thing (a WinForms/CF designer) and building two thrings (VCL.NET/CF and a VCL.NET/CF designer).  On the surface, it’s natural to assume that building one thing must take less effort than building two things.  But when you consider the complexities of what these things have to tie into, it’s not so simple.

Building a form designer without control of or intimate knowledge of the objects being manipulated is about like adding a bathroom to a house without access to the basement or knowledge of where the plumbing is located in the walls.  Without access to the basement, you can’t run new plumbing to your new fixtures.  Without knowledge of the existing plumbing in the walls, you’ll wind up damaging a lot of wall trying to locate existing pipes, or cutting through a live pipe (or live wire) you didn’t know was there.  As a concession, you’re likely to hang this new bathroom on the side of the house so you can have some limited access to the subfloor and can route the pipes around the exterior of the house (if you bother with pipes at all).  Ultimately, lack of information and control will make this bathroom addition resemble an outhouse in appearance and in odor.

Given the choice between building a WinForms/CF designer from scratch and adapting VCL.NET and the VCL.NET form designer to target CF, the VCL.NET route offers us better control and complete information.  Even though it may require more total effort, VCL.NET/CF offers us a greater chance to succeed and to outperform the WinForms/CF solution.

Enabling the design environment is the reason I’m now open to pursuing VCL.NET/CF.  Not because VCL.NET/CF will enable miracles at runtime, but because it will enable miracles at design time.

Is that a self-serving view?  Of course it is.  But then, VCL itself was created only to provide a framework and component model for a GUI form designer to manipulate.  If Win32 provided the services necessary for a GUI designer to manipulate user-defined controls in a rich and seamless way, Borland would not have needed to create VCL.  And now we appear to be facing a similar situation with the .NET Compact Framework platform.

All that’s fine and good, but if a more economical WinForms/CF design solution were to fall into our laps in the near future, all VCL.NET/CF work would immediately cease and we’d all go back to our regularly scheduled features.  The window for that option is closing rapidly.  If we determine VCL.NET/CF is a viable option, and if we decide to deliver VCL.NET/CF, then we’re in it for the long haul.