VB6 - Detect Tablet PC Capabilities

Why Care?

While Windows XP Tablet Edition wasn't very popular and even Windows Vista's intrinsic support for the Tablet PC Platform wasn't enough to drive sales, hardware is beginning to catch up in the Windows 7 era. This means developers will be writing software they can expect to "encounter" Tablet hardware more often.

In many cases being able to detect and take advantage of this can give your commercial applications a competitive edge: while the other guys only handle keyboard/mouse input your next WhizBang could enable touch and drawing features when available.


The Focus Here

I won't go into the new controls available on a Tablet PC here. Instead I'll write about how to do the necessary detection.


Levels of Support

Windows systems can support "Ink" at varying levels. As Windows uses the term "ink" refers to a new data type that can be represented as a new embeddable OLE/COM type (InkObj or Ink Object), ISF (Ink Serialied Format, an image format based on GIF), GIF, XML, and others.

Often we'll care less about Ink itself and more about Ink-after-recognition as a text input mechanism.

Support Levels:

• None at all. Windows 2000 prior to SP4, and all of Win9x.
• Ink display. Windows 2000 SP4 and later with the Tablet PC Runtime deployed to it.
• Ink entry and recognition. Windows XP Tablet Edition and later Windows Premium or better Editions.
• Pen and Touch input entry and recognition. A Tablet PC running XP Tablet Edition or later, or any PC with an internal or external Touch or Pen digitizer and XP Tablet Edition or later Windows Premium or better Editions.

You might wonder how the 3rd level above works givien that it has no form of digitizer (touchscreen, pen, etc.). In enabled systems Ink can be "drawn" (and perhaps recognized as text) using the mouse!


Another Way of Looking at it

On a system like Windows 2000 SP4 your program could use a control like the InkEdit control (an "inkable" TextBox, actually RichTextBox) but the user cannot mouse-draw into it or even pen-draw into it if they have a pen device plugged in. As far as I can tell they can't even draw Ink into an InkPicture control, though your program can display Ink in one.

The same restrictions apply to Windows XP until Tablet Edition.

But on a system running Windows Vista Home Basic the user can draw Ink using the mouse into the InkPicture control (a PictureBox that can accept and display Ink input).

A user with Windows Vista Home Premium can draw Ink into the InkPicture control, save and load it, etc. They can also "write" text using the mouse in an InkEdit control and have it recognized and replaced by the recognized text.

And a user with XP Tablet Edition, Vista Home Premium, etc. can use an external pen or digitizer to enter Ink or have Ink writing recognized. If they have a Pen screen or Touch screen that can use Ink fully.

Some laptops with a touch-panel meant as a mouse alternative may even accept Ink via that device when enabled through the right drivers.


So How Does This Impact Me?

If you have an application designed primarily for use with a keyboard and mouse you probably don't care about any of this... much.

But what if some of your customers have a full Tablet device they might want to use your program with? You might want to offer the ability to use "writing" into your TextBoxes using a pen, touch-stylus, or even finger. If you've used a Tablet PC much you'll understand what a pain the on-screen keyboard alternative can be.

Who knows, you might even want to allow Ink (drawing) input since the InkEdit control can accept and display a mix of text and InkObj "pictures."

But here's the kicker:

The Tablet PC Runtime can be awkward to deploy and offers limited usefullness on a non-Tablet system. So you probably won't even want to consider deploying it. But if you don't deploy it your programs cannot use those controls even in their crippled form.

You need to detect some things about the platform before even loading a Form that uses these controls!


What's Worth Detecting?

In many cases it will come down to a simple question: "What can I do to let Tablet PC users write text into TextBoxes?"

It turns out that this is simple to handle via a single GetSystemMetrics() API call.

If the system is a Tablet PC, load and use InkEdit controls. if not, load and use TextBox or RichTextBox controls.

Easy.


So Why Even Write About This?

Well remember, some non-Tablet PCs can use InkEdit and InkPicture controls (and other Tablet/Ink classes) to display and even to enter Ink, with or sometimes without recognition.

This means you might want to do more than just allow a Tablet to "hand write" text into TextBoxes. Perhaps you'll want to allow drawing (and at least viewing of drawing) where capable. And maybe systems that can't accept Ink at all might at least be able to display Ink drawings.


Detection

There are three GetSystemMetrics() calls of interest here:

• SM_PENWINDOWS. Obsolete, appears to apply only to old Win9x, NT 4.0, and Win2K tablet devices not supported by the Tablet PC Platform.
• SM_TABLETPC. New with XP Tablet Edition. Appears to guarantee that the Tablet PC Platform is installed, the Ink controls are available, recognition of handwriting is supported, and some type of on-screen Pen/Touch digitizer is present.
• SM_DIGITIZER. New with XP Tablet Edition. Returns a bitmask listing the kinds of digitizers avaialble.

So we have one we can ignore, and two of possible use.

But what if we want to know whether the system has Ink controls available, so that a program using them won't just crash?

Ahh, for this there is no simple call though there could have been. Sadly Microsoft didn't think this far ahead. Instead they say you should try loading one of the objects, and success means the Runtime components are available.


Sample Code

Code:

---

Option Explicit
'
'Requires a reference to Microsoft Tablet PC Type Library, version 1.0.
'

Private Const SM_DIGITIZER = 94
Private Const SM_PENWINDOWS = 41
Private Const SM_TABLETPC = 86

Private Enum DIGITIZERS
    NID_INTEGRATED_TOUCH = &H1
    NID_EXTERNAL_TOUCH = &H2
    NID_INTEGRATED_PEN = &H4
    NID_EXTERNAL_PEN = &H8
    NID_MULTI_INPUT = &H40
    NID_READY = &H80
End Enum

Private Declare Function GetSystemMetrics Lib "user32" (ByVal nIndex As Long) As Long

Private Sub Form_Load()
    Dim Digitizer As DIGITIZERS
    Dim InkObj As MSINKAUTLib.InkRectangle
   
    AutoRedraw = True
    Show
   
    Print "SM_PENWINDOWS = "; CBool(GetSystemMetrics(SM_PENWINDOWS))
    Print "SM_TABLETPC = "; CBool(GetSystemMetrics(SM_TABLETPC))
    Digitizer = GetSystemMetrics(SM_DIGITIZER)
    Print "SM_DIGITIZER = &H"; Right$("0" & Hex$(Digitizer), 2)
    Print "    NID_INTEGRATED_TOUCH = "; CBool(Digitizer And NID_INTEGRATED_TOUCH)
    Print "    NID_EXTERNAL_TOUCH = "; CBool(Digitizer And NID_EXTERNAL_TOUCH)
    Print "    NID_INTEGRATED_PEN = "; CBool(Digitizer And NID_INTEGRATED_PEN)
    Print "    NID_EXTERNAL_PEN = "; CBool(Digitizer And NID_EXTERNAL_PEN)
    Print "    NID_MULTI_INPUT = "; CBool(Digitizer And NID_MULTI_INPUT)
    Print "    NID_READY = "; CBool(Digitizer And NID_READY)
    On Error Resume Next
    Set InkObj = New MSINKAUTLib.InkRectangle
    Print "InkControlsAvailable = "; CBool(Err.Number = 0)
End Sub

---

Are We There Yet?

This leaves us with one more detection issue: Even a system with the Tablet PC Runtime in place might or might not support handwriting recognition.

Determining this seems to involve first checking for SM_TABLETPC, and if False checking for the presence of the Runtime, and if True we must check to see if we are running on a Windows Premium or better Edition machine.

As far as I can tell you'd have to do the latter by first calling GetVersion() or GetVersionEx() to see if you are running on Vista or later. Then you can call GetProductInfo() and look for the values indicating Premium or better.


Recommendations

I think most programs can get by just checking for SM_TABLETPC.

Others can get by checking for the availability of the Ink controls, and if the results for SM_TABLETPC are False but the controls are present go ahead and use the controls and leave their capabilities up to the user. If they can (and really, really want to) handwrite text using the mouse... more power to 'em. It isn't for me. But I might want to support InkPicture wherever it is available.

In extreme cases I might consider deploying the Tablet PC Runtime to systems capable of supporting it. But that would only be for applications that really need to be able to display Ink even when they can't accept it. That sounds like very, very few applications to me.

If need be you can do this using the Installer Merge Modules provided in the Tablet PC Platform SDK. You'll want this SDK anyway.

As far as I know this SDK has not been updated for Vista or Windows 7 yet, so you'd use the same one for now.

a pilot work! thanks.

Most of this should hold true in Windows 8 as well for "real" Desktop (i.e. "legacy" i.e. non-Metro) applications.

If Windows 8 actually takes off it may mean even more touchscreen PCs such as tablets end up in the wild. Of course for our purposes that means x86 or x64 tablets and not the more restrictive ARM-based tablets.

Quote:

---

Originally Posted by dilettante

Most of this should hold true in Windows 8 as well for "real" Desktop (i.e. "legacy" i.e. non-Metro) applications.

If Windows 8 actually takes off it may mean even more touchscreen PCs such as tablets end up in the wild. Of course for our purposes that means x86 or x64 tablets and not the more restrictive ARM-based tablets.

---

Win8 supports both x86 (32bit & 64bit) and ARM CPU,not MIPS. I have installed both Win8 and Win7 on my Win7 PC.