TabletPC Development Gotchas Part4: Semantics of GetSystemMetrics(SM_TABLETPC)
If your application needs to find out at runtime whether or not it runs on a Tablet PC, it is recommended to call GetSystemMetrics() and pass in the value 'SM_TABLETPC'.
But what does it actually mean for a computer to be a Tablet PC? Is that determined by the installed hardware components? Or the software components? All of the above? Some of the above?
Those are almost philisophical questions and I won't try to give a complete answer here. But instead I want to shed some light on the semantics of the actual implementation of GetSystemMetrics(SM_TABLETPC). So if you decide to use that API call in your app after reading this post, you know exactly what you are getting.
XP vs. Vista - Semantic Differences
On Windows XP, the return value GetSystemMetrics(SM_TABLETPC) is exclusively based on software considerations. It returns whether or not your computer is running Windows XP Tablet PC Edition. Back in the day, that made a lot of sense, because this edition was exclusively available to OEMs, and they could only install it on computers that satisfied strict hardware requirements. So checking for the OS type implied certain hardware capabilities. It caused a little bit of confusion for MSDN subscribers who installed the Tablet Edition on their desktops for development purposes. Moreover, the hardware requirements changed overtime (to allow new form-factors, such as UMPCs). Thus, on Windows XP, you cannot really rely on GSM(SM_TABLETPC) to tell you about hardware capabilities, it only tells you reliably what OS edition the user is running on.
On Windows Vista the return value of GetSystemMetrics(SM_TABLETPC) is determined based on several things. It returns true if all of the following conditions are true:
1) There is an integrated digitizer, either pen or touch, on the system.
2) The computer is running a Premium SKU of Windows Vista (Home Premium and above). Those SKUs include a license for the TabletPC optional components (which are also installed by default on those SKUs).
3) Tablet PC Input Service is running. Tablet PC Input Service is a new service for Windows Vista that controls Tablet PC input.
This obviously provides greater accuracy than the XP implementation. However, it also can potentially cause some confusion as all three conditions may change at runtime on a given piece of hardware. For example, you can stop the input service. Now when you launch an app that checks GSM(SM_TABLETPC) to enable/disable some features (like Microsoft Word does), you will notice that some of the inking tools are not available. So at times the same computer might be considered a Tablet PC, and sometimes it is not. Hmmm…
Detecting the presence of specific components:
In most cases checking the presence of the required components is more appropriate than using GSM(SM_TABLETPC). For example if your application relies on the Chinese handwriting recognizer, then calling GSM will be useless, because the recognizer could be present on non-Tablet systems - and it could be missing on a Tablet system. The right thing here is to inspect the Recognizers collection to see if it includes a Chinese handwriting recognizer.
There are two articels on MSDN that contain more information about this approach:
Tablet PC Platform Independence (by Dr. Neil Roodyn)
Microsoft Sudoku: Optimizing UMPC Applications for Touch and Ink (by Stephen Toub; scroll down to the 'Platform Detection' section)
TIP: If by any chance you want your Vista Premium desktop computer to be considered a Tablet PC without doing any hardware upgrades, all you need to do is install a virtual driver that reports itself as integrated stylus digitizer. This will cause GSM(SM_TABLETPC) to return true and as a result, light up all Tablet-specific features on your computer. Check the websites of popular external Tablet manufacturers for the availability of those drivers.
Previous post in this series: TabletPC Development Gotchas Part3: Coerce to Factoid (XP vs. Vista)