Stift Eingabe zum Schreiben auf Tablet

[Der schöne Günther]

Da ich in Delphi überhaupt kein Land gesehen habe war der "Umweg" über eine DLL (die dann auch direkt fantastisch funktioniert hat) ein gangbarer Weg.

So toll wie es jetzt direkt in Delphi funktioniert würde ich den Umweg ehrlich gesagt auch nicht mehr gehen.

Wenn du mit deiner Anwendung fast bei Null anfängst und es sich hauptsächlich ums Zeichnen dreht, dann sicher direkt über VS

[oakley]

Bei null fange ich nicht wirklich an.
Ich wollte eine Möglichkeit bereistellen, handschriftliche Notizen zu einem Datensatz auf einem Tablet machen zu können.
Und dazu auch etwas zu zeichenen also im Prinzip sowas wie one note.

Das Ganze dann noch mit ein paar Fotos aufgepeppt... das wärs.

Sowas könnte man wohl wirklich besser in VB umsetzen und dann in Delphi als ActiveX laufen lassen?

LG

Mirko

[HolgerX]

So, fertig..

Das mit dem Radierer war doch recht einfach..

Musste nur von InkCollector auf InkOverlay umstellen.
Hier dann in der MSINKAUTLib_TLB_HF endgültig alle EXIT rausnehmen.

und die Property EditingMode verwenden

[oakley]

Sehr cool. Funktioniert einwandfrei.
Jetzt guck ich noch wie ich auf das Panel Photos bekomme und dann noch in A4 formatieren.

Richtig gut gemacht !!!

Gruß

Mirko

[ULIK]

Hi,

ich verwende das InkOverlay nun schon seit Jahren. Hat den Vorteil, Selektion, Radierer und Ähnliches gehen out of box. Aber Achtung: Probleme gibt es damit auf Touch-fähigen Systemen insbesondere ab Windows 8. Hier hat MS einen Bug eingebaut, so daß die 2-Finger Gesten zum Zoomen, Drehen nicht mehr funktionieren.
Und auch die reine Scrollgeste mit einem Finger funktioniert generell nicht, da das InkOverlay nicht zwischen Maus, Touch oder Digitizer-Eingaben unterscheiden kann: es wird immer alles als Eingabe betrachtet und entsprechend gelöscht, gezeichnet oder markiert!

Beim Arbeiten immer auch drauf beachten, daß die Reihenfolge von InkOverlay-Events zwar in sich immer gleich ist, aber die entsprechendenen VCL-Mouse-Events mal vor oder nach dem dazugehörigen InkOverlay-Event ausgeführt werden. Hier muß man die beiden Eventtypen funktional strikt trennen, wenn man beide verwenden will/muß.

Ach ja: wenn man damit arbeiten will: eine sehr gute Literaturempfehlung ist 'Building TabletPC Applications' von Rob Jarrett/Philip Su

[oakley]

Wenn MS da den Bug reingebaut hat, wie löst man dann zum Beispiel das Scrolling-Problem?

Ich habe generell übrigens noch Probleme das ich Bilder, die ich mit der Kamera gemacht habe nicht auf den Canvas bekomme.
Ich kann die zwar ablegen aber verschieben und die Größe ändern geht nicht.

Viele Grüße

Mirko

[ULIK]

Im Prinzip läuft es darauf hinaus, daß Du vor der eigentlichen Eingabe erkennst, daß eine Toucheingabe erfolgen wird. Dann setzt man die Stifteigenschaften auf unsichtbar (voll transparent), so daß am InkOverlay bei der Eingabe nichts gezeichnet wird. Die Daten des Stroke werden dann in den Events in Scrollbewegungen umgerechnet und das zugrundeliegende Fenster gescrollt.

InkOverlayCursorInRange: umschalten auf voll transparent wenn Touch (da kann man die Eigenschaften der DrawingAttributes noch ändern - in späteren Events geht das nämlich nicht mehr!. Ob der Cursor des Event eine Toucheingabe ist, frägst Du so ab:

Delphi-Quellcode:

var
  iInkTablet2: IInkTablet2Disp;
begin
  Result := False;

  // Test, ob man TOUCH-Cursor ist
  if Supports(ACursor.Tablet, IID_IInkTablet2, iInkTablet2) then
    Result := (iInkTablet2.DeviceKind = TDK_Touch);
end;

Weiter geht's in InkOverlaySystemGesture: bei ID = ISG_Tap oder ISG_Drag mußt Du nun das Scrollen aktivieren (Merken der aktuellen Ausgangsposition)

In InkOverlayNewPackets wird dann das unterliegende Fenster gescrollt (als Differenz zur Position im SystemGesture)

in InkOverlayStroke mußt Du auf alle Fälle den bis dahin erstellten Stroke wieder verwerfen (Cancel auf True setzen), sonst wird diese gespeichert!

in InkOverlayCursorOutOfRange müssen dann die Drawing-Attributes wieder auf die ursprünglichen zurückgesetzt werden.

Das Problem dabei: NewPackets feuert sehr oft. Hier hilft es nun, auch die Mouse-Events zu benutzen und das Scrollen dorthin zu verlagern; da das MouseMove des unterliegenden Fenstern nicht so oft aufgerufen wird. Klappt deswegen, weil MouseMove IMMER nach InkOverlayCursorInRange und vor InkOverlayStroke / InkOverlayCursorOutOfRange erfolgt.

Ich kann Dir leider keinen fertigen Code dafür geben. Du mußt das an deine Anwendung geeignet anpassen. Aber das Prinzip sollte nun klar sein. Damit kann man das Toucscrolling simulieren, wenn es auch nicht so schön glatt läuft wie ein reguläres Scrollen.

Eine Zoom-Gesture läßt sich leider mit diesem Verfahren nicht simulieren, da immer nur der erste Touch-Punkt erkannt wird. Hierzu hab ich auch keine Lösung.


Grüße,
Uli

[oakley]

Hallo Uli,

danke für die ausführliche Info.
Ich bin im Moment etwas eingespannt, werde das aber nach Ostern wieder angehen.

Viele Grüße

Mirko