Wieso wurden die hohen Erwartungen enttäuscht? Die Gründe liegen zum einen an der anfangs viel zu schwachen Hardware und relativ hohen Preisen im Vergleich zu herkömmlichen Notebooks. Im Herbst 2003 kam dann die zweite Tablet PC-Generation auf den Markt, die durch die neue Intel Centrino-Technologie wesentlich leistungsstärker geworden ist. So wurde zumindest ein erstes Hindernis behoben. Auch im Hause Microsoft wurde es immer ruhiger in Sachen Tablet PC und zudem fehlte es immer noch an cleveren Tablet PC-Anwendungen. Microsoft hat den Ernst der Lage erkannt und Ende letzen Jahres zur Tablet PC Challenge [1] aufgerufen: Does your code think in ink?, um der Entwicklergemeinde einen Anreiz zu geben. Gesucht und prämiert wurden Anwendungen, die auf intelligente und innovative Weise Handschrift und Stiftbedienung in einer Lösung einsetzen.

Stellt sich die Frage, was eine solche Anwendung ausmacht. Wann ist eine Bedienbarkeit mit dem Stift sinnvoll? Wie gehe ich mit stiftbasierten Eingaben um? Welche davon lasse ich handschriftlich zu? Dieser Artikel soll Ihnen einen Einblick in die Tablet PC-Entwicklerwelt geben - insbesondere in die Bereiche Benutzeroberflächen und Umgang mit digitaler Tinte.

Der Weg zum Erfolg

Es gibt grundsätzlich zwei unterschiedliche Ansätze, wie Tablet PC-Anwendungen gestaltet und aufgebaut werden. Die richtige Entscheidung kann hier den Erfolg oder Misserfolg Ihrer Anwendung bestimmen. Allerdings müssen Sie sich nicht allzu viele Gedanken machen, da der geeignete Ansatz weitgehend durch den Anwendungs- und Einsatzbereich der Anwendung festgelegt ist. Das heißt, dass Sie sich nur darüber im Klaren sein müssen, wie Anwender Ihre Anwendung nutzen werden. Entscheidend ist dabei die Frage, ob diese sowohl auf Tablet PC und Nicht-Tablet PC (also mit Maus und Tastatur) genutzt werden soll oder aber fast ausschließlich für den Einsatz auf dem Tablet PC gedacht ist.

Beispiele für erste Kategorie sind Microsoft Office XP und 2003, der MSN Messenger in der Version 6.1 oder der MindManager von MindJet [2]. Allen diesen Zwittern ist gemein, dass es bekannte Applikationen sind, die um eine Ink-Funktionalität erweitert wurden. Klarer Vorteil, die Bedienung der Anwendung und das UI sind grundsätzlich bekannt, der Nutzer muss sich nur noch mit der Stiftbedienung und Handschrifteneingabe vertraut machen. An der vertrauten Benutzeroberfläche wurde sehr wenig verändert (meist nur ein zusätzliches Menü, um beispielsweise Anmerkungen beim Überarbeiten eines Dokuments auch handschriftlichen eingeben zu können). Ziel ist, die Bedienung der Anwendung bis zu einem gewissen Grad auch auf einem Tablet so angenehm wie möglich zu gestalten und diese um einige nette Möglichkeiten zu erweitern (handgeschriebene eMails mit Herzchen zum Beispiel).

Auf der Gegenseite stehen jene Anwendungen, die vom Ansatz her für die Verwendung auf einem Tablet PC entwickelt wurden und deren Bedienbarkeit per Stift im Vordergrund steht. Meist handelt es sich hier um Anwendungen, die überhaupt erst durch den Tablet PC und dessen Mobilität möglich geworden sind. Häufig sind dies Datensammelanwendungen, beispielsweise die Kundenbefragung auf einer Messe oder die Patientenaufnahme auf einer Notaufnahme im Krankenhaus. In beiden Fällen werden papierbasierte Prozesse durch digitale abgelöst. Es kann aber auch der digitale Notizblock oder Rechenblock [3] sein, den man in Meetings, Vorlesungen und anderen Veranstaltungen nutzt, um schnell ein paar wichtige Punkte mitzuschreiben (Beispiele sind hier Microsoft Journal oder Microsoft Office OneNote 2003).

Die erste und entscheidende Frage lautet also: Handelt es sich um eine mehr oder weniger reine Tablet PC-Anwendung oder nicht? Sollen eine existierende Anwendung um Stift-Funktionalität erweitert, ein ganz neues Bedienkonzept entwickelt oder aber eine neue Anwendung erstellt werden, die in einem Bereich zum Einsatz kommt, den man aufgrund Hardware-technischer limitierender Faktoren zuvor noch nicht ansprechen konnte? (Anmerkung hierzu: Auch jede reine Tablet PC-Anwendung sollte auch noch komfortabel mit Maus und Tastatur bedient werden können, schließlich verfügt jeder Tablet PC grundsätzlich auch über diese.)

Praxisbeispiel: Der Feedback-Bogen

Jeder kennt ihn: den beliebten Feedbackbogen, den auszufüllen man auf jeder Entwicklerkonferenz aufgefordert wird. Entweder liegt er in Papierform vor, steht auf Feedbackterminals oder im Web zum Ausfüllen online bereit - oder (wesentlich angenehmer) nette Hostessen fragen den Teilnehmer nach der eigenen Meinung und den Bogen für ihn aus.

Ziel ist es natürlich, den papierenen Feedbackprozess durch einen digitalen zu ersetzten. Zentrale Anforderungen liegen darin, dass der Tablet PC-basierte Feedbackbogen so komfortabel und effizient ausgefüllt werden können soll wie sein Vorgänger und dass die Korrektheit der erfassten Daten gleichzeitig zunimmt. Dass die gesammelten Daten schneller für eine Auswertung bereitstehen, versteht sich von selbst.

Ausgangspunkt stellen der papierene Feedbackbogen und sein im Web existierendes Pendant dar. Die schnelle und einfach Bedienbarkeit ist hier eines der wichtigsten Kriterien. Bei einer rein Maus-basierten Anwendung entscheidet dabei der Klick. Obgleich die Verwendung des Stifts der Verwendung einer Maus ähnlich ist, kann sie viel schwieriger sein: Dateneingabe und Bedienung bzw. Menüsteuerung müssen mit dem Stift erledigt werden. Die Treffgenauigkeit mit dem Stift spielt ebenfalls eine wichtige Rolle. Und: Wie schnell können Sie mit dem Stift die Farbe Gainsboro im Menü Format-Hintergrund auswählen oder haben den gesamten Text markiert (im Gegensatz zu Strg+A)?

Fazit: Machen Sie es dem Nutzer so einfach wie möglich und so deutlich wie möglich, wo und wie er den Stift einsetzten kann, um Menübefehle auszuführen, und wo er handschriftliche Eingaben vornehmen kann. Eventuell gehen Sie auch so weit, zwischen Stift- und Mausmodus klar zu unterscheiden (wie z.B. beim bereits erwähnten MindManager von MindJet).

Aber zurück zum Beispiel: Nehmen wir an, dass wir eine existierende Anwendung Questionaire auf den Tablet PC übertragen sollen. Die Anwendung beinhaltet ein einziges Formular, über das personenbezogene Daten sowie Umfrageantworten erfasst werden. (Die Anwendung finden Sie als C#-Sourcecode auf der beiliegenden CD.) Alle erfassten Daten werden in einem typisierten DataSet gesammelt und der Einfachheit halber tagweise als *.xml auf der lokalen Festplatte gesichert.

Warum haben wir uns nicht entschieden, den papierenen Feedbackbogen direkt auf den Tablet PC zu übernehmen? Aus eigener Erfahrung und bestätigt von zahlreichen Kollegen ist die eigene Handschrift auf einem Tablet PC deutlich größer als auf einem Blatt Papier. Hinzu kommt, dass bei einer Auflösung von 1024 x 768 und einem 10 bis 12 Zoll großen Display ein DIN A4-Format immer kleiner dargestellt wird. Im aktuellen Software Developer Kit (SDK) 1.5 finden Sie ein entsprechendes Beispiel: Scanned Paper Form. Probieren Sie einmal, dies auszufüllen und lassen Sie sich dann die erkannten Werte anzeigen, Sie werden frustriert sein. Eine Lösung hier wäre, ein neues papierenes Formular für die Maße des Tablet PC und durchschnittliche Schriftgröße der Nutzer zu entwerfen und zu programmieren, aber dies wäre Stoff für einen weiteren Artikel.

Im Rahmen eines Rapid Application Developments soll die Fragenbogen-Anwendung ad hoc in eine Tablet PC-Anwendung überführt werden. Eine erste - und gleichzeitig die schnellste - Lösung bestünde darin, jedes Windows.Forms.TextBox-Control durch ein Microsoft.Ink.InkEdit-Control zu ersetzten, ein paar Kompilierfehler zu korrigieren (nicht alle Methoden und Eigenschaften der TextBox werden von InkEdit unterstützt) und die Anwendung neu zu erstellen. Super, funktioniert nur, die jetzt Stift-aktivierten Felder sind zu klein für die Eingabe. Beim Ausfüllen muss ich mich schon sehr konzentrieren und auch dann laufe ich häufig genug aus dem Feld. Also verwerfen wir diesen Ansatz.

Das Tablet PC InkEdit Control - Einschränkungen. Das InkEdit Control ist hervorragend geeignet, um normale TextBox-Controls zu ersetzten und eine Anwendung Ink-aware zu machen. In den Beispielanwendungen wurde gezeigt, wie leistungsstark dieses Control ist. Dennoch gibt es einige Einschränkungen. Die InkCollector- oder InkOverlay-Schnittstellen werden vom InkEdit Control nicht nach außen freigegeben. Dadurch ist es beispielsweise nicht möglich anzugeben, wie InkEdit digitale Tinte einsammeln sollte. Des weiteren gibt InkEdit keinen Zugriff auf den RecognizerContext , ohne den es nicht möglich ist, neben dem einfachen Factoid, die Texterkennung weiter zu beeinflussen. Um an die im Control gehaltene Handschrift zu gelangen, muss zuerst der SelInksDisplayMode des Controls auf Ink umgestellt werden, damit wir über die Eigenschaft SelInks an die Ink-Objekte gelangen.

Das Pen Input Panel (PIP)

Wie löst man dieses Problem zu kleiner Eingabefelder? Hierzu gibt es zwei Möglichkeiten: Zum einen könnte man die Eingabefelder entsprechend vergrößern (unschön) oder aber man nutzt das PenInputPanel (PIP), welches im SDK 1.5 zur Verfügung steht (besser). Mit dem PIP bekommt man ein standardisiertes Input-Panel, das es erlaubt, komfortable handschriftliche Eingaben in die Textbox vorzunehmen. Vor dem SDK 1.5 musste man dies noch mühsam selbst programmieren, jetzt deklariert man schlicht ein PenInputPanel und weist ihm bei der Instanziierung die entsprechende Textbox zu:

1. private Microsoft.Ink.PenInputPanel txtEMailPip;
2. ...
3. txtEMailPip = new Microsoft.Ink.PenInputPanel(txtEMail);

Man könnte auch ein einziges, sozusagen globales PIP deklarieren und ohne zugewiesenes Control instanziieren und jeweils, sobald ein Control den Fokus bekommt, dies der AttachedControl-Eigenschaft des PIP zuweisen. Der Übersicht halber tendiere ich dazu, für jedes TextBox-Control ein eigenes PIP zu deklarieren, auch weil ich Schreibfaul bin, denn mit den Leszynski inTegrate Tablet PC Extensions [4] wird einem diese Tipparbeit komfortabel abgenommen und für jede ausgewählte Textbox der Code für ein PIP eingefügt.

So schön diese Lösung bereits ist, so ist sie dennoch weiterhin mit einigen Schwächen versehen. Falsch erkannte Handschrift ist schwer und nur durch Neueingabe zu korrigieren, die Erkennung der eMail-Anschrift, der Telefonnummer, wie auch des Geburtsdatums lässt zu wünschen übrig. Wechsle ich zu schnell von einem Eingabefeld ins nächste, wird das zuletzt Geschriebene schlichtweg ignoriert. Das Warten auf den Abschluss der Handschriftenerkennung und die Übergabe an die Textbox oder der Klick auf den Senden-Button sind unnötig und stören den Eingabefluss.

Um diesen Fehlern beizukommen, müssen wir ein wenig mehr Code schreiben. Jedes Mal wenn Sie von einem Eingabefeld ins nächste wechseln, ohne auf die Textübergabe zu warten, hat sozusagen eben diese versagt. Genau dieses Ereignis des Versagens fangen wir nun ab und erzwingen es (die Textübergabe an die zuvor aktive Textbox) im Code. Das entsprechende abzufangende Event heißt InputFailed:

1. txtEMailPip.InputFailed += new PenInputPanelInputFailedEventHandler(InputFailed_Event);
2. ...
3. public void InputFailed_Event(object sender,PenInputPanelInputFailedEventArgs e)
4. {
5. // Make sure the object that generated the
6. //event is a PenInputPanel object
7. if (sender is PenInputPanel)
8. {
9. PenInputPanel pip = (PenInputPanel)sender;
10. // Set the text in the previous control
11. pip.AttachedEditControl.Text += e.Text;
12. }
13. }

Korrekte Dateneingabe

Um die korrekte Erkennung bestimmter Eingaben wie Postleitzahlen, Web- und eMail-Adressen, Datumswerten und Telefonnummern zu erhöhen, können wir uns so genannter Factoids bedienen. Mit deren Hilfe teilt man dem PIP mit, welche Eingabe (genauer das Eingabeformat und die zu erwartenden Zeichen, also ähnlich regulären Ausdrücken) wir in einem bestimmten Feld erwarten. Das Tablet PC SDK stellt uns eine Reihe dieser Factoids zur Verfügung (leider könne wir diese noch nicht selbst definieren). Anzumerken ist hierbei, dass in Abhängigkeit von der auf dem Tablet PC aktiven Sprache des Texterkenners unterschiedliche Eingabeformate erwartet werden, d.h. erkennen Sie gerade US-Englisch, so wird das Factoid.Date ein Datumsformat in der Struktur MM/dd/yyyy erwarten:

1. txtBirthDatePip.Factoid = Factoid.Date;
2. txtMobilePhonePip.Factoid = Factoid.Telephone;
3. txtEMailPip.Factoid = Factoid.Email;
4. txtMiddleInitialPip.Factoid = Factoid.OneChar;

Sind diese Hilfen gesetzt, wird jetzt erstmalig das @-Zeichen häufig genug sauber erkannt, sodass die eMail-Anschrift korrekt in die Textbox eingefügt werden kann. Dank .NET DateTime.Parse kann ich im Datumsfeld auch handschriftlich 20. Mai 69 eintragen, sollte hier aber dennoch überlegen, ob im TextChanged-Event das eingetragene Datum auch als solches erkannt. Falls nicht, sollte zumindest ein gewisses Feedback an den Nutzer gegeben werden. Generell sollte man dies bei allen wichtigen Eingabefeldern (beispielsweise den Personendaten) in Hinblick auf die erwünschte Datenkorrektheit tun, ohne jedoch dabei den Eingabefluss zu behindern. Eine Möglichkeit wäre beispielsweise, den erfassten Text rot einzufärben, falls er bestimmten Kriterien nicht genüg. Bleibt noch das Problem, wie ich die Korrektur falsch erkannter Worte unterstützen kann. Bei der jetzigen Kombination aus TextBox mit PenInputPanel bleibt mir nur die Möglichkeit, die fehlerhafte Zeichenkette zu markieren, zu löschen und neu zu schreiben. Geht auch dies schief, bietet mir das PIP noch eine Bildschirmtastatur. Diese Korrekturmöglichkeit als einzige Möglichkeit ist aber definitiv nicht erstrebenswert. Abhilfe verspricht hier wieder das InkEdit-Control, welches neben dem erkannten Text auch alternativ erkannte Wörter sowie die ursprüngliche Tinte (das Handgeschriebene) für uns speichert und bereithält. Generell verfährt die Texterkennung des Tablet PC immer so, dass sie eine Liste möglicher erkannter Worte zurückgibt und standardmäßig jenes mit der höchsten Wahrscheinlichkeit zurückgibt. Diese Wortliste können Sie im Code jederzeit abfragen und ausgeben, das InkEdit-Control kapselt diese Funktionalität bereits. Wenn Sie nun wiederum alle TextBox-Controls durch InkEdit-Controls ersetzt haben, können Sie bei einem falsch erkannten Begriff die Liste der Alternativen anzeigen lassen und das korrekte (sofern enthalten) auswählen (siehe Abb. 2):

1. private Microsoft.Ink.InkEdit txtEMail;

Dennoch enthält auch die jetzige Lösung noch ein paar kleine Schönheitsfehler. In Bezug auf das PenInputPanel wäre es wünschenswert, dessen Höhe und vor allem Breite in Abhängigkeit zu dem einzugebenden Text anpassen zu können und den Namen des jeweiligen Felds für die Eingabe anzuzeigen, um jederzeit sehen zu können, wo man gerade steht. Im Moment lässt sich dies nur dadurch halbwegs lösen, dass ich das PIP in Relation zum Eingabefeld verständlich positioniere. Dies erreichen Sie am besten, indem Sie das Ereignis abfangen, bevor dies angezeigt wird, und die Position neu bestimmen (siehe Listing 1).

Listing 1

1. public void VisibleChanged_Event(object sender, PenInputPanelVisibleChangedEventArgs e)
2. {
3. if(sender is PenInputPanel)
4. {
5. enInputPanel pip = (PenInputPanel)sender;
6. // If the panel has become visible...
7. if (e.NewVisibility)
8. {
9. // Move the pen input panel to
10. // screen position 100, 100
11. pip.VerticalOffset = 20;
12. pip.HorizontalOffset = (pip.AttachedEditControl.Left *(-1)/2 ) + 10;
13. }
14. }
15. }

Alle weiteren Wünsche bleiben jedoch vorerst unerfüllt - es sei denn, man entwickelt ein eigenes PenInputPanel, welches mir dann auch alternative Farben, Formen und so weiter erlaubt. Das aber ist wieder ein anderes Thema.

Der Tablet PC Jegliche Bewegung des Stifts wird vom Tablet PC Digitizer erkannt und mit einer Genauigkeit von min. 1000 Zeilen je Inch gemessen. Dies geschieht bereits, sobald er nur knapp über dem Tablet PC schwebt, ohne ihn zu berühren. Sobald der Stift den Digitizer berührt, werden neben der Position weitere Daten übertragen, zum Beispiel Druckstärke oder Ansatzwinkel. Auch wenn sich der Stift nicht bewegt, werden vom Digitizer fortlaufend Daten weitergereicht, vom Pen Driver aufgenommen und schließlich durch Ink-Objekte des SDKs an eine Anwendung weitergegeben. Dies geschieht ~133 Mal/Sekunde, was sich erst mal nicht besonders schnell anhört. Handschrift auf dem Tablet PC kostet extrem viel Prozessorleistung, ohne dass wir bis dahin eine Texterkennung durchgeführt hätten. Sobald sich der Stift über den Digitizer bewegt, löst der Tablet PC Ereignisse aus, die sowohl Anwendungs- wie auch Systemcode ausführen. Zudem muss mit jedem einzelnen Event die Darstellung neu berechnet werden. Für uns bedeutet dies, die Anzahl des Neuzeichnens (paint/draw) so gering wie möglich zu halten, um einen möglichen Ink-Lag zu verhindern. Besonders in allen Positionen jenseits von Primary Landscape kann es schnell zu einem Hinterherhinken der Tinte kommen, da für diese Darstellungen mehr Berechnungen benötigt werden. Tablet PCs werden zur Zeit noch auf alter Hardware gebaut, die nur für Primary Landscape gedacht war.

Arbeiten mit Gesten

Daneben stört mich noch eine weitere Sache: Ich bin es gewöhnt, ein Auswahlfeld durch einen schnellen Haken zu markieren. Im Moment muss ich sehr genau auf die Checkbox tippen, um sie auszuwählen. Nicht, dass wir dies jetzt nicht mehr erlauben wollten, aber die Möglichkeit, einfach - wie in Abpictureung 3 gezeigt - grob über die Checkbox einen Haken zu zeichnen, um ihre Checked-Eigenschaft auf true zu setzten, sollte zusätzlich gegeben sein. Und wenn ich den Haken falsch gesetzt habe, sollte dieser durch ein Durchstreichen auch wieder entfernt werden können. Die Ink-API biete mir hierfür die Möglichkeit, auf so genannte Gestures zu reagieren und definiert hierfür bereits eine Anzahl einfacher Gesten vor. Hier interessieren uns die ApplicationGesture.Check und die ApplicationGesture.Scratchout. Um auf diese reagieren zu können, benötigen wir ein InkOverlay-Control, welches wir quasi über das CheckBox-Control legen, auf die Gesten warten und dann entsprechend reagieren zu können (siehe Listing 2).

Listing 2

1. //Ink enabling CheckBoxes
2. CheckBox cb = (CheckBox)cont;
3. inkCheck = new InkOverlay(cb.Handle);
4. inkCheck.CollectionMode = CollectionMode.InkAndGesture;
5. //Which gestures to collect and recognize...
6. inkCheck.SetGestureStatus(ApplicationGesture.Scratchout, true);
7. inkCheck.SetGestureStatus(ApplicationGesture.Check, true);
8. //Hook up the gesture and stroke eventhandlers...
9. inkCheck.Gesture += new InkCollectorGestureEventHandler(inkCheck_Gesture);
10. inkCheck.Stroke += new InkCollectorStrokeEventHandler(inkCheck_Stroke);
11. //Set to go, turn ink and gesture collection on...
12. inkCheck.Enabled = true;
13. ...
14. private void inkCheck_Gesture(object sender, InkCollectorGestureEventArgs e)
15. {
16. //Only if pretty sure about a gesture we perform the operation...
17. if((e.Gestures[0].Confidence == RecognitionConfidence.Strong) ||
18. (e.Gestures[0].Confidence == RecognitionConfidence.Intermediate))
19. switch(e.Gestures[0].Id)
20. {
21. case ApplicationGesture.Scratchout:
22. //Erase / Delete
23. UnCheckCheckBox();
24. //MessageBox.Show("Delete");
25. break;
26. case ApplicationGesture.Check:
27. //Check
28. CheckCheckBox();
29. break;
30. default:
31. break;
32. }
33. //Delete the strokes...
34. e.Cancel = false;
35. pnlHandwritingInput.Invalidate();
36. }

Wie Ihnen sicherlich anhand des Beispielcodes aufgefallen ist, wurde an jedes einzelne CheckBox-Control ein eigenes InkOverlay-Control gehängt. Die Checkboxen waren ausreichend groß, um das Zeichnen eines Hakens zu unterstützen. Sind Ihre Auswahlboxen aber zu eng gedrängt, kann es bei dieser Lösung dazu kommen, dass das einzelne InkOverlay-Control die Check-Geste nicht zuverlässig genug erkennen kann. Eine Lösung für dieses Problem bestünde darin, ein InkOverlay-Control an die GroupBox zu hängen und sie vor alle enthaltenen Controls zu ziehen, indem Sie die AttachMode-Eigenschaft auf InkOverlayAttachMode.InFront setzen. Wenn eine Check-Geste erkannt wird, müssen Sie nun im ersten Schritt die BoundingBox des Check-Strokes ermitteln und anhand dieser Daten evaluieren, über welchem Control die Geste ausgeführt wurde und dann entsprechend die CheckBox markieren.

Ein kleines Beispiel im gleichen Kontext: Wie löschen Sie geschriebenen Text auf einemn Notizzettel? Fangen Sie die Geste ScratchOut ab, ermitteln die BoundingBox und bestimmen, welche anderen Strokes sich mit einem bestimmten Prozentsatz innerhalb dieses Rechtecks befinden und löschen alles dann entsprechend:

1. //ScratchOut has been recognized and calls EraseInk
2. private void EraseInk(Strokes scratchOutStroke)
3. {
4. //Get bounding box of scratch-out stroke...
5. Rectangle rectangleToErase = scratchOutStroke.GetBoundingBox(BoundingBoxMode.Default);
6. //Because the scratchOutStroke is horizontal, add some height to it...
7. rectangleToErase.Height = rectangleToErase.Height * 2;
8. //Strokes that where hit must at least be 40% inside the rectangleToErase...
9. Strokes strokesToErase = inkOverlay.Ink.HitTest(rectangleToErase, 40);
10. //Erase the strokes...
11. inkOverlay.Ink.DeleteStrokes(strokesToErase);
12. }

Zur weiteren Verbesserung der Anwendung sollte man noch alle wichtigen Menübefehle auf die Toolbar legen und alle Toolbar-Buttons etwas größer gestalten, um sie einfacher mit dem Stift bedienen zu können.

Des Weiteren besteht die Möglichkeit, Stift-Gesten auszuwählen oder neu zu definieren, die häufig genutzte Befehle, beispielsweise Save und New auslösen - quasi als Keyboard-Shortcut-Ersatz. Hingewiesen sei hierbei wiederum auf Leszynski und das Tool Leszynski inDirect for Tablet PC, das es erlaubt, mit Gesten zu arbeiten [5].

Der Tablet PC und die Zukunft - Lonestar

Microsoft will Mitte 2004 die Windows XP Tablet PC Edition 2004 (Codename Lonestar) auf den Markt bringen. Die neue Tablet PC Edition besitzt eine wesentlich verbesserte Handschrifterkennung, ein neues TabletInputPanel und bietet Entwicklern eine noch bessere Plattform, um die Stift- und Tintenfunktionalität in Anwendungen zu integrieren. Beispielsweise unterstützt das neue Tablet PC SDK 1.7 die Handschrifteingabe in APS.NET-Anwendungen. Bereits jetzt können Sie und sollten Sie mit der neuen Version experimentieren. Seit Ende Dezember steht eine Alpha-Version für Microsoft-Betatester zur Verfügung. Schicken Sie einfach eine eMail an TabAlpha@Microsoft.com mit dem Betreff: Information Request - GDN Team Page. Lonestar ist im wesentlichen ein Update zur existierenden Tablet PC Edition, das in wenigen Minuten durchgeführt ist (im Moment nur die englische Edition). Ist das Update abgeschlossen, lässt sich das neue SDK ohne Probleme installieren.
Joerg Ch. Jasper ist Leiter des DevTeams bei der it-function gmbh & co.kg (www.itfunction.de) . Zusammen mit seinem Kollegen Oliver Hepfner ist er verantwortlich für Mobile Lösungen und Softwareentwicklungen auf .NET. Sie erreichen beide unter devteam@itfunction.de.

Links und Literatur

• [1] Tablet PC Challenge: www.microsoft.com/germany/aktionen/tabletpcchallenge/
• [2] MindJet: www.mindjet.de/
• [3] xThink Caluclator: www.xthink.com/
• [4] Leszynski inTegrate Tablet PC Extensions for Visual Studio 2003 Developer Preview Edition: www.leszynski.com/
• [5] Leszynski inDirect for Tablet PC: www.leszynski.com/
• Rob Jarret et al., Building Tablet PC Applications; MS Press, 2003
• Carlos C. Tapang, Achieve the Illusion of Handwriting on Paper When Using the Managed INK API, Oktober 2003: msdn.microsoft.com/msdnmag/issues/03/10/TabletPC/default.aspx
• Tracy L. Bannon ; Master the Pen Using Ink Controls in Your Tablet Applications; Feb 2003; www.devx.com/dotnet/Article/10820/
• Tablet PC Developer: www.gotdotnet.com/team/tabletpc/
• Tablet PCs.net: www.etabletpc.com/
• Tablet PC Minds: www.tabletpcminds.com/