Software component vendor ComponentOne has released Studio Enterprise 2013 v2.5, the latest in its suite of components, with support for Windows 8.1 and Visual Studio 2013.
The piece that caught my eye is the TouchToolkit for Windows Forms.
Here’s the problem. The Windows desktop is poor with touch control, which is why Microsoft created Windows 8 with its alternate, touch-friendly Windows Runtime platform. However users are resistant to the changed user interface, and it does not help with existing desktop apps.
Developers are also faced with a question of simple mathematics. Develop a Windows 8 Store app, get a market of x. Develop a Windows desktop app, get a market of many times x, since Windows 8 can run desktop apps, but Windows 7 cannot run Store apps.
Embarcadero approached this problem with a framework called Metropolis, for Delphi and RAD Studio. It builds apps that mimic the Windows Runtime look and feel, but which are actually desktop apps. Of course they do not run on Windows RT, the ARM version. It is a confusing solution in my opinion, leading users into what Martin Fowler calls the Uncanny Valley, where stuff works almost but not quite how you expect.
I prefer the thinking behind the TouchToolkit. Take your existing Windows Forms apps, or write a new one, using these controls to make them more touch-friendly. They will never be as well suited to touch control as a Store app, but they might be good enough, and of course will run on Windows 7 and earlier versions.
The controls include a magnifier, support for zoom gestures, and a touch event provider that adds gesture support to any control.
Windows Forms, we all know, is not as good as WPF if you want an application that scales nicely and supports modern design. On the other hand, Windows Forms is pragmatic and easy to use framework that remains popular for line of business apps.
I had a look at C1’s demo and was impressed, but slightly baffled by why you would even try to use data-intensive LOB apps in an environment so clearly hostile to basic data entry, let alone spend time and money converting them for touch-controlled zoom.
On your last point, I am one of those people who don’t know that Windows Forms is not as good as WPF when it comes to making apps that scale well. Once I would have agreed with you, but no longer. The problem is down to Microsoft’s appallingly bad implementation and documentation of the (obsolete) AutoScale and (current) AutoScaleMode properties. They’re supposed to make forms DPI-aware so they recognise they’re not running at the same DPI they were designed in and scale themselves automatically at runtime. This has confused an enormous number of developers for years, particularly since MS has never admitted there was a problem, nor altered subsequent releases of .NET, presumably to avoid a major breaking change. It comes down to realising that when the documentation says what should happen, hasn’t happened, there is nothing to stop an explicit call to a form’s Scale method after detecting a non-design-time DPI at load time. WinForms applications then become the wonderfully scalable things that developers always wanted them to be.