Automatische Anzeige der virt. Tastatur unterdrücken

[hotrs02]

Hi *.*.

Wir haben eine Delphi 11 VCL Applikation, die auf einem Tablet-PC mit aktuellem Windows 10 / 11 ohne angeschlossene Tastatur läuft. Für Eingaben verlassen wir uns in der Regel auf die automatisch angezeigte virt. Tastatur. Allerdings haben wir verschiedene Dialoge, die eine eigene, permanent sichtbare und mit speziellen Knöpfen ausgestattete virt. Tastatur anzeigen.

Für diese Dialoge möchten wir nun die automatische Anzeige der virt. Tastatur bei Anwahl einer TEdit-Instanz per Touch unterbinden. Ich bin dabei auf das Interface ITextInputPanel gestoßen, was aber nicht wie gewünscht funktioniert. Eine einfache Testanwendung mit einem Knopf und einem Eingabefeld macht beim Drücken des Knopfes folgendes:

Delphi-Quellcode:

type
  tEditHack = class(tEdit);

procedure TForm1.Button2Click(Sender: TObject);
var
  TIP: IUnknown;
  Value: Integer;

begin
  tEditHack(Edit1).TipMode := tipDontCare; // autom. Anzeige der Tastatur durch die VCL unterdrücken!

  TIP := nil;
  if Succeeded(CoCreateInstance(CLASS_TextInputPanel, nil,
      CLSCTX_INPROC_SERVER or CLSCTX_LOCAL_SERVER, IUnknown, TIP)) then
    if Succeeded((TIP as ITextInputPanel).Set_AttachedEditWindow(Edit1.Handle)) then
      if Succeeded((TIP as ITextInputPanel).Set_InPlaceVisibleOnFocus(Integer(False))) then
        begin
          (TIP as ITextInputPanel).Get_InPlaceVisibleOnFocus(Value);
          if Bool(Value) then
            ShowMessage('Get_InPlaceVisibleOnFocus: TRUE')
          else
            ShowMessage('Get_InPlaceVisibleOnFocus: FALSE')
        end
      else
        ShowMessage('Set_InPlaceVisibleOnFocus failed...')
    else
      ShowMessage('Set_AttachedEditWindow failed...')
  else
    ShowMessage('CoCreateInstance failed...');
end;

Trotzdem wird danach bei Anwahl des Eingabefeldes automatisch die virt. Tastatur von Windows aufgerufen.

Wenn man sich nun die Beschreibung zu ITextInputPanel bei Microsoft anschaut, so findet sich dort bereits der Hinweis, dass das Interface in späteren Versionen von Windows ggf. nicht zur Verfügung steht. Stattdessen wird auf IInputPanelConfiguration verwiesen, was aber laut Dokumentation unter Windows 10 nicht funktioniert.

Man muss doch irgendwie innerhalb einer Anwendung das Verhalten der virt. Tastatur beeinflussen können? Hat jemand vielleicht einen entscheidenden Hinweis?

Gruß

[Der schöne Günther]

Unter IInputPanelConfiguration::EnableFocusTracking wird die Doku etwas genauer:

Zitat:

This method will not work in Windows 10. A user can manually configure settings through the notification center or through the Typing settings to enable pulling up a touch keyboard automatically when focusing on an edit control.

Klartext: "Wir bieten keine funktionierende API an, soll der Benutzer doch selber in der Systemsteuerung (die jedes halbe Jahr anders aussieht) sagen ob global ja oder Nö."

Wir haben uns bei unseren Kiosk-Applikationen schon vor länger von dem Windows-Automatismus verabschiedet und machen immer eigene Eingabe-Dialoge mit stinknormalen VCL-Popups. Die funktionieren wenigstens auch bei der nächsten Windows-Halbjahresversion immer noch.

[hotrs02]

Bei einer Kiosk-Anwendung funktioniert das natürlich. Aber halt nicht, wenn auf dem Tablet-PC nicht nur unsere Anwendung genutzt wird.

Wenn sich keine Möglichkeit finden sollte, dann muss der Anwender wohl den Tablet-Mods deaktivieren und die Tastatur bei Bedarf manuell über die Task-Leiste aufrufen.


(Gibt es in der Richtung eigentlich von Microsoft bereitgestellte Foren, in der man eine offizielle Anfrage zu so einer Schnittstelle stellen könnte?)

[Der schöne Günther]

Ich bin bei Microsoft im "Developer TAP" (Technology Adoption Preview)-Programm, da kann man sich mit den Entwicklern austauschen, kann aber etwas dauern. Ich versuche da diese Woche einmal nachzufragen, hatte da auch einmal Beschreibung für eine undokumentierte API für Touchpads bekommen. Aber ich würde ehrlich gesagt da nicht zu viel erwarten.

[hotrs02]

Vielleicht ist es ein Versuch wert.

Vielen dank schonmal.

[himitsu]

https://stackoverflow.com/questions/...-edit-controls


Da steht notfalls auch, wie man für die eigene Anwendung diese Tastatur komplett deaktiviert.
Selber anzeigen der Tastatur (oder was Alternativem), da wo man sie braucht, müsste man dann noch machen.



Die notmale Bildschirmtastatur ist ja ein Graus.
Im WindowsInstaller, weiß Windows noch, dass keine Tastatur angeschlossen ist und zeigt dort die Virtuelle an,
aber nach dem ersten Start, ist alles wieder vergessen und man muß erstmal wissen, wie man nur per Touch im Startmenü das findet.

Die Option zum Anzeigen ist schnell gefunden, aber die fast versteckte Option die Tablet-Tastatur auch im Desktop-Modus zu nutzen ... damit wird es dann besser, weil Diese Tastatur dann auch Edit/Anwendungen verschiebt, wenn sie auf geht.
(nur Delphi-XE hat noch einen Bug, wenn Tastatur zu und es eigentlich wieder Vollbild wird, aber das Programm dann halb bleibt)
Wenigstens liegt die angedockte Tablet-Tastatur nicht immer ungünstig überm Programm, vorallem immer da, wo man hinklicken wollte.

Auch bissl ungünstig ist, dass man oftmals zwei Mal ins Edit klicken muß, damit die Tastatur auf geht.

[einbeliebigername]

Hallo,

Zitat:

Zitat von Der schöne Günther (Beitrag 1509242)

Klartext: "Wir bieten keine funktionierende API an, soll der Benutzer doch selber in der Systemsteuerung (die jedes halbe Jahr anders aussieht) sagen ob global ja oder Nö."

Nö, das stimmt so nicht ganz. Problem ist man muss den Einstieg finden, dann ist die Docu von Microsoft nicht wirklich die beste und dann muss man das auch noch in die Win32/64-Welt bringen (Alle Meinungen sind zwei, drei Jahr alt, als ich mich mit dem Thema beschäftigt habe).

Die Touch-Tastatur läuft bei Microsoft unter dem Thema erleichterte Bedienung. Dazu zählt z.b. auch alles was man braucht um seine Anwendung für Menschen mit eingeschrängtem Sehvermögen zu öffnen. Und das läuft über das UIAutomation.

Ich würde jetzt gern Sourcecode zeigen, aber das ist nicht meiner. Aber schau mal unter https://github.com/jhc-systems/Delph...omatedEdit.pas. Das sieht sehr ähnlich zu dem was ich damals aus dem Internet zusammenkopiert hatte.

Vollständig verstanden habe ich das auch noch nicht. Und mir fehlt noch das Reagieren auf das Erscheinen und Verschwinden der Tastatur.

Steuern, ob die Tastatur automatisch aufgeht, lässt sich nach meiner Errinnerung durch die Funktion

Delphi-Quellcode:

function Get_IsReadOnly(out pRetVal: Integer): HResult; stdcall;

.
Bei mir sieht die auch so aus:

Delphi-Quellcode:

  if ReadOnly then
    pRetVal :=  1
  else
    pRetVal :=  0; // Maybe?
  result := S_OK;

[hotrs02]

Zunächst danke für die Hinweise.

Zitat:

Zitat von himitsu (Beitrag 1509247)

https://stackoverflow.com/questions/...-edit-controls
Da steht notfalls auch, wie man für die eigene Anwendung diese Tastatur komplett deaktiviert.

Über diesen Faden war ich bei meiner Suche ebenfalls bereits gestoßen. Allerdings funktionieren die dort aufgezählten Schnittstellen IPenInputPanel bzw. ITextInputPanel offensichtlich nicht mehr. Ich kann darüber weder die Anzeige unterdrücken, noch eine angezeigte virt. Tastatur wieder ausblenden.

Auch der Eintrag in der Registry, der die Anzeige der virt. Tastatur für eine Applikation unterdrücken soll, funktioniert nicht (mehr).

Eine angezeigte virt. Tastatur kann ich zumindest über

Delphi-Quellcode:

    Handle := FindWindow(PChar('IPTip_Main_Window'), nil);
    if Handle <> 0 then
      PostMessage(Handle, WM_SYSCOMMAND, SC_CLOSE, 0);

zuverlässig wieder ausblenden.

[hotrs02]

Danke für deinen Hinweis.

Zitat:

Zitat von einbeliebigername (Beitrag 1509252)

Hallo,
Die Touch-Tastatur läuft bei Microsoft unter dem Thema erleichterte Bedienung. Dazu zählt z.b. auch alles was man braucht um seine Anwendung für Menschen mit eingeschrängtem Sehvermögen zu öffnen. Und das läuft über das UIAutomation.

Ich habe mir die von dir genannten Quellen einmal genauer angeschaut und in einer Testapplikation eingesetzt. Allerdings kann ich auch damit die virt. Tastatur nicht unterdrücken.

[himitsu]

Gab es am TEdit nicht mal ein Property, wo man einstellen konnte welche Tastatur aufgehen soll?
Dachte eher im FMX, aber auch bei DevExpress grade nichtgefunden, aber mir war so ich hätte mal sowas gesehn. :gruebel:

Also normale Tastatur, oder nur Nummerisch, oder wie Telelefon usw.

Da hätte man mal nachsehen können, was das macht und ob es da auch eine Einstellung "keine Tastatur" gäbe.

[hotrs02]

Embarcadero hat in einer älteren Delphi Version an TWinControl die protected Eigenschaft

Delphi-Quellcode:

  TTipMode = (tipClose, tipOpen, tipDontCare);
  property TipMode: TTipMode read FTipMode write FTipMode default tipDontCare;

eingeführt. Standardmäßig steht diese auf tipDontCare, TEdit und TMemo z.B. setzen Sie auf tipOpen. Die Eigenschaft wird nicht veröffentlicht und ist nicht dokumentiert. Aus den Quellen lässt sich aber entnehmen, dass versucht wird, bei Erhalt des Fokus mittels ITextInputPanel Schnittstelle die virt. Tastatur einzublenden.

[himitsu]

DevExpress sagt "seit XE3"

Zitat:

Delphi-Quellcode:

  {$IFDEF DELPHIXE3}
    property TipMode;
  {$ENDIF}

Ahhhhhh, an der Form war es, wo Delphi es auf published stellt und man es da im OI sieht.
Und bei TCustomEdit's auf tipOpen gesetzt.


Hab mal kurz reingesehn, was sie da machen:

Zitat:

Delphi-Quellcode:

procedure TWinControl.UpdateTIPStatus;
begin
  if Assigned(FTIPIntf) then
  begin
    if TipMode = tipOpen then SetTextInputPanelStatus(Self, True)
    else if TipMode = tipClose then SetTextInputPanelStatus(Self, False);
  end;
end;

procedure SetTextInputPanelStatus(Control: TWinControl; OpenTIP: Boolean);
  procedure InvokeTabTip;
  const
    DefaultTabTipPath = 'C:\Program Files\Common Files\microsoft shared\ink\TabTip.exe';
    DefaultOnScreenKeyboardPath = 'C:\Windows\System32\OSK.exe';
  var
    TabTipPath: string;
  begin
    TabTipPath := DefaultTabTipPath;
    ShellExecute(0, 'open', PChar(TabTipPath), nil, nil, SW_SHOWNOACTIVATE);
  end;

  procedure OPenTip2;
  begin
    (Control.FTIPIntf as ITextInputPanel).SetInPlaceVisibility(1); // True
  end;

  procedure CloseTip;
  begin
    (Control.FTIPIntf as ITextInputPanel).SetInPlaceVisibility(0); // False
  end;

begin
  if Assigned(Control.FTIPIntf) then
  begin
    if OpenTIP then OpenTip2 // InvokeTabTip
    else CloseTip;
  end;
end;

// das Kompilieren der Vcl.Controls.pas muß aber viele "wurde deklariert, aber wird nicht verwendet"-Warnungen werfen

Ursprünglich hatten sie damit scheinbar "selber" die Tastatur angezeigt.
Der alte Code zu TabTip.exe / OSK.exe haben sie noch drin,
aber jetzt nutzen sie auch ITextInputPanel.SetInPlaceVisibility .

[add]
Das Ganze scheint aber nur bei TApplication.IsMetropolisUI aktiv zu sein, aber ich kann nirgendwo sehen, wo IsMetropolisUI/UseMetropolisUI aktiviert wird. (klingt nach Windows8-Zeugs)

Zitat:

Delphi-Quellcode:

procedure TWinControl.CreateWnd;
...
  if (Touch.GestureEngine <> nil) and (csGestures in ControlStyle) then
    Touch.GestureEngine.Active := True;
  if Application.IsMetropolisUI and (WindowHandle <> 0) and
    not (csDesigning in ComponentState) then
  begin
    FTIPIntf := nil;
    if Succeeded(CoCreateInstance(CLASS_TextInputPanel, nil,
        CLSCTX_INPROC_SERVER or CLSCTX_LOCAL_SERVER, IUnknown, FTIPIntf)) then
    begin
      if Supports(FTIPIntf, ITextInputPanel) then
        (FTIPIntf as ITextInputPanel).Set_AttachedEditWindow(WindowHandle);
    end;
  end;
end;

[hotrs02]

Über die Eigenschaft TipMode war ich letztendlich auf die ITextInputPanel Schnittstelle aufmerksam geworden. Aber wie bereits oben geschrieben, funktioniert die Schnittstelle aktuell nicht mehr wie gewünscht.

[einbeliebigername]

Hallo,

jetzt fällt es mir wieder ein. Als ich das brauchte war es bei mir aber andersrum. Die Tastatur ging bei einem Standard-Edit (bei XE8) nicht automatisch auf. Die Lösungen mit Nachrichten an die Tastaturapp schicken oder die Exe aufrufen fielen wegen undokumentiert aus. In irgendeinem Forum stieß ich auf das UIAtomation mit eine Beispielimplementierung für ein Edit. Damit ging bei mir dann die Tastatur automatisch auf.

Zitat:

Zitat von hotrs02 (Beitrag 1509298)

Embarcadero hat in einer älteren Delphi Version an TWinControl die protected Eigenschaft

Delphi-Quellcode:

  TTipMode = (tipClose, tipOpen, tipDontCare);
  property TipMode: TTipMode read FTipMode write FTipMode default tipDontCare;

eingeführt. Standardmäßig steht diese auf tipDontCare, TEdit und TMemo z.B. setzen Sie auf tipOpen. Die Eigenschaft wird nicht veröffentlicht und ist nicht dokumentiert. Aus den Quellen lässt sich aber entnehmen, dass versucht wird, bei Erhalt des Fokus mittels ITextInputPanel Schnittstelle die virt. Tastatur einzublenden.

Da das bei mir im XE8 nicht funktioniert hat, kann es sein, dass das bei dir im Konflickt mit meiner Lösung steht. Versuche mal dies zu deaktivieren, so dass die Tastatur garnichtmehr automatisch aufgeht. Dann sollte sich die Tastatur wieder über das UIAtomation triggern lassen. Und dort lässt sich ja steuern ob die Tastatur aufgeht oder nicht.

Nach meiner Einschätzung ist die zukunftssichere und vom Microsoft verfolgte Variante das UIAtomation. Mir fehlt aber aktuell die Zeit mich damit zubeschäftigen. Sobalt ich etwas Luft habe (habe bald Urlaub), versuche ich da mal wieder weiterzumachen.

[himitsu]

Aktuell (Delphi 11) scheint dieses Property garnichts zu machen,
denn siehe

Delphi-Quellcode:

if Application.IsMetropolisUI and

in meinem Post #12.

IsMetropolisUI scheint immer False zu sein. (nichts gefunden, was es aktiviert)
Aber man könnte mal versuchen beim Programmstart (also in der DPR, vor Erstellen der Form) das

Delphi-Quellcode:

Application.UseMetropolisUI;

aufzurufen und es so zu aktivieren.

[hotrs02]

Zitat:

Zitat von einbeliebigername (Beitrag 1509307)

Da das bei mir im XE8 nicht funktioniert hat, kann es sein, dass das bei dir im Konflickt mit meiner Lösung steht. Versuche mal dies zu deaktivieren, so dass die Tastatur garnichtmehr automatisch aufgeht.

Wie himitsu richtig bemerkt, wird die Eigenschaft TipMode in aktuellen Delphi Versionen standardmäßig nicht ausgewertet, weswegen es nicht zu einer Beeinflussung kommen sollte. Ich hatte bei meinen Tests aber auch noch aus vorherigen Versuchen Code stehen, der TipMode auf tipDontCare setzt.

Zitat:

Zitat von einbeliebigername (Beitrag 1509307)

Dann sollte sich die Tastatur wieder über das UIAtomation triggern lassen. Und dort lässt sich ja steuern ob die Tastatur aufgeht oder nicht.

Hast du ggf. noch einen Tipp, welche Schnittstelle du genau dafür verwendet hast? Mittels IValueProvider.IsReadOnly habe ich es zumindest nicht geschafft, die virt. Tastatur zu unterdrücken. Allerdings möchte ich nicht ausschließen, dass mir dabei ein Fehler unterlaufen ist. Das UI Automation Framework ist doch recht komplex.

[TurboMagic]

Kann das nicht Auswerten/Funktionieren dieses Properties Mal jemand der sich damit auskennt im QP als Bug melden?

[hotrs02]

Ich hatte in QP bereits einen Eintrag bzgl. der Veröffentlichung der Eigenschaft TipMode an TWinControl-Nachfahren wie TEdit und TMemo gemacht. Leider war ich da etwas vorschnell und habe erst später die in diesem Faden zusammengetragenen Unzulänglichkeiten herausgefunden. Ich habe den Eintrag gerade dementsprechend ergänzt.

Der Eintrag ist hier zu finden: https://quality.embarcadero.com/browse/RSP-38718

[einbeliebigername]

Hallo,

ich habe etwas Zeit gehabt selbst nochmal zu testen.

Als ich vor einigen Jahr für ein Kunden ein Modul für ein Windows 10 Handheld implementieren solte, ging die Bildschirmtastatur nicht automatisch auf. Dies hat sich geändet. In der gesammten Anwendung (auch die Module welche nicht für Touch entwickelt sind) geht die Bildschirmtastatur bei den Edits und Memos zu gefühlt 95% automatisch auf. Ich denke das ist das Problem. Lieder streickt aktuel das Remotdebuging.

Einzige Option die aktuell funktioniert ist das ReadOnly-Property. Das wird bei mir berücksichtigt.

[himitsu]

Delphi XE und ohne daß irgendwas im Delphi/Programm aktiviert wurde:

Bei einem PC ohne Tastatur und mit Touch geht inzwischen die virtuelle Tastatur auf,
aber ich finde die "wichtige" Option im Windows nicht mehr.

Allerdings geht Sie (die angedockte Tablettastatur) immer erst beim zweiten Klick/Tippen ins Edit auf, was schon etwas blöd ist, wenn jemand nicht direkt weiß, dass es eine virtuelle Tastatur gibt.



Dagegen ist das "freifliegende" OSK schon bissl blöd, denn beim Verschieben der Tastatur bekommt sie den Fokus und man muß immer erst wieder ins Edit reinklicken, damit die Tastatur funktioniert.
Und da das Drecksding immer im Weg ist, muß man es ständig verschieben.

Außerdem, wer kommt bitte auf die saublöde Idee eine Tastenkombination für das Aufgehen der Virtuellen zu bauen ... wie soll man Die drücken, wenn es keine Tastatur gibt? :freak:
Da steht doch auch noch ganz fett "Gerät ohne physische Tastatur verwenden".
Siehe auch Win 8.1-Video https://support.microsoft.com/de-de/...BD=Windows_8.1

Windows 10 > Startmenü > Einstellungen (links das Zahnrad) > Erleichterte Bedienung > Tastatur (links unten, eventuell erst scrollen) > der oberste Schalter "Bildschirmtastatur verwenden"
> Dann geht die Tastatur als freifliegendes Fenster auf, was ständig im weg ist, wenn man mal oben und mal unten im Programm ein Eingabefeld hat.
> Der Schalter geht wieder aus, wenn man das Tastaturfenster schließt (nicht minimiert).

Das ist die selbe App, welche auch aufgeht, wenn man osk.exe startet, bzw. nach "Bildschirmtastatur" im Startmenü sucht.

Anhang 55257

Oben der fette schwarze Streifen, welcher sinnlos Platz verschwendet, das ist die "Textvorhersage", welche aber standardmäßig irgendwie nie etwas anzeigt. (kann man zum Glück in den Einstellungen ausblenden)

Außerdem verwenden wir im Programm viel die F-Tasten, welche aber in der Tablettastatur komplett fehlen :wall:
und die im freifliegenden OSK grundsätzlich ausgeblendet sind, also sich hinter den Zahlen verstecken (selbst wenn man die Zehnertastatur einblendet).

Zitat:

aber ich finde die wichtige Option im Windows nicht mehr.

Dann fand ich aber noch in irgendwo in einem Untermenü, fast ganz unten, eine Optionen, welche irgendwie sowas hieß wie "Tablettastatur auch im Desktop-Modus verwenden".

Genauso, wie bereits bei der Installation vom Windows, geht nun von alleine die Tastatur auf, wenn man in ein Edit klickt. (jetzt allerdings erst beim zweiten Klick ins Edit)
Diese Tastatur ploppt, von alleine im unteren Teil des Bildschirms, nach oben und verschiebt das Programm so, dass das Edit oben sichtbar bleibt (das Programm wird etwas verkleinert, in der Höhe)

Ja, es ist wirklich krank ... im Windows Setup wusste Windows noch, dass die Tastatur fehlt und machte dort die Virtuelle auf,
aber nach dem ersten Start war das wieder vergessen und man mußte erst selber rausfinden, wie man nun an eine Virtuelle ran kommt.
Und der Shortcut hilft da auch nicht wirklich. :wall:



Die Tablettastatur (vermutlich die TabTip.exe) bekommt man ebenfalls, wenn man im Kontextmenü der Uhr das "Bildschirmtastatur anzeigen (Schaltfläche)" aktiviert und dann auf den Knopf drückt.

Anhang 55258



Unter Windows 7 hatte man noch eine viruelle Tastatur, die flutschte zur Seite raus, man sie schoß, so als kurzer Streifen, über den man sie von links wieder in den Bildschirm aufziehen konnte (mit dem Finger vom Rand in den Bildschrirm rein wischen)



PS: ich weiß jetzt, warum manchme PCs einen USB-Port mit aufgedruckter Tastatur haben.
z.B. die kleinen Lenovo ThinkCentre, welche man hinter den Monitor schrauben kann.
-> mit Alt+P (oder war's Strg+P) kann man den Rechner dann anschalten (das BIOS UEFI reagiert dort darauf)
Anhang 55259

[hotrs02]

Erstmal danke, dass du dir dafür die Zeit genommen hast.

Zitat:

Zitat von einbeliebigername (Beitrag 1509454)

Hallo,
Einzige Option die aktuell funktioniert ist das ReadOnly-Property. Das wird bei mir berücksichtigt.

Meinst du damit die Eigenschaft TEdit.ReadOnly oder IValueProvider.IsReadOnly?

TEdit.ReadOnly auf TRUE zu setzen bringt mich leider nicht weiter, da ich eine Eingabemöglichkeit benötige. Dann macht es ggf. mehr Sinn, ein eigenes Steuerelement zu entwickeln, welches das Verhalten von TEdit nachbildet.

[einbeliebigername]

Hallo,

Zitat:

Zitat von hotrs02 (Beitrag 1509461)

Meinst du damit die Eigenschaft TEdit.ReadOnly oder IValueProvider.IsReadOnly?

Es ist TEdit.ReadOnly welche von Windows beachtet wird. Bei ReadOnly-Edits wird die Tastatur nicht geöffnet.

Zitat:

Zitat von hotrs02 (Beitrag 1509461)

TEdit.ReadOnly auf TRUE zu setzen bringt mich leider nicht weiter, da ich eine Eingabemöglichkeit benötige.

Das verstehe ich jetzt nicht. Man kann bei einem Touch-Gerät doch nur mit der Bildschirmtastatur was eingeben. Bei separaten Buttons in der Obrfläche kann man ja an dem ReadOnly vorbei das Edit ändern.

[hotrs02]

Unsere virt. Tastatur arbeitet momentan so, dass sie Tastendrücke mittels keybd_event simuliert. Für ein TEdit (und ein TMemo) mit der Eigenschaft ReadOnly = TRUE müsste man also anders vorgehen und das Eingabeverhalten nachbilden.

Dazu kommt, dass die Anwendung optional auch mit angeschlossener Tastatur bedient werden soll. Die Eigenschaft ReadOnly darf also nicht grundsätzlich auf TRUE gesetzt werden, sondern in Abhängigkeit einer angeschlossenen Tastatur im Desktop-Modus bzw. durch den Anwender konfigurierbar.

Aber du hast recht, beides sollte sich mit vertretbaren Aufwand umsetzen lassen.

[himitsu]

Zitat:

Abhängig setzten

Da muß man auch bissl aufpassen, ob die "Abhängigkeit" auch funktioniert, bzw. zuverlässig geprüft werden kann.
z.B. kann man im WMI zwar alle Eingabegeräte sehen, aber ob Eines davon eine physische Tastatur ist, lässt sich garnicht so leicht prüfen.

Und manches geht plötzlich nicht mehr, wenn man z.B. einen RDP dazwischen hat, bzw. es ist dort plötzlich unverständlicher Weise andersrum.


z.B. haben wir ein TEdit, da werden standadmäßig nur Großbuchstaben/Zahlen eingegeben.
Beim Edit aber das UpCase zu aktivieren geht nicht, weil es noch ein paar seltene Sonderfälle gibt, wo man alles klein schreiben muß.


Ich hatte vor Kurzem mal ausprobiert im OnEnter/OnLeave das CapsLock zu aktivieren, damit es autoatisch standardmäßig Groß ist,
dann noch der Kampf, den blöden BallonHint loszuwerden (Capslock-Warnung von Windows)
und als alles ging, dann kam jemand mit RDP und es stellt sich raus, dass dort in dem Edit alles klein ist.
Gut, es wäre nicht so schlimm, wenn DORT nur das Aktivieren nicht funktionieren würde (über keybd_event auf CapsLock drücken), aber beim rausgehn wird es DORT auch noch groß, also genau andersrum, wie es eingebaut ist. :wall:

[hotrs02]

Ich habe noch einen weiteren Lösungsansatz gefunden: mir war aufgefallen, dass ein TEdit.SetFocus die virt. Tastatur nicht anzeigt.

Also habe ich zunächst versucht, in TEdit.OnClick oder TEdit.OnEnter die Eigenschaft ReadOnly auf FALSE zu setzen. Die Tastatur wurde aber leider weiterhin angezeigt. Dann habe ich mit einem Timer experimentiert, der in TEdit.OnClick / TEdit.OnEnter gestartet wird und nach einer Zeitspanne (250ms) die Eigenschaft ReadOnly auf FALSE setzt. Leider ebenfalls Fehlanzeige.

Was aber funktioniert ist, einfach zwei TEdit übereinander zu legen und die Sichtbarkeit zu steuern. Das obere TEdit hat die Eigenschaft ReadOnly auf TRUE gesetzt, das darunter liegende auf FALSE. Das obere ist zunächst sichtbar, das untere nicht. In OnEnter des oberen TEdit wird dann die Sichtbarkeit beider TEdit umgeschaltet, was letztendlich zu dem gewünschten Verhalten führt. Elegant finde ich die Lösung allerdings nicht.

Ich werde mir jetzt auch mit Hinblick auf den Aufwand für die Anpassung älterer Dialoge überlegen müssen, welche Lösung ich umsetze.

[einbeliebigername]

Hallo,

ich habe weitergeforscht und bin etwas weitergekommen.

Wenn man der Seite https://docs.microsoft.com/de-de/win...touch-keyboard Glauben schenkt, sollte das UiAutomation noch funktionieren. Desweiteren fand ich im Internet eine Hinweis auf die Funktion

Delphi-Quellcode:

SetInputScope(hwnd: HWND; inputscope: TInputScope): HRESULT;

mit der man das Tastaturlayout beeinflussen kann.

Ich habe mal Delphi 11 installiert und meine Änderungen bzgl. UiAutomation aus dem Kundenprojekt raus gelöst und in ein Testprojekt (Anhang 55275) gebracht. Einiges von dem Sourcecode ist Copy/Past aus dem Internet. Woher kann ich nicht mehr ermitteln. Auch habe ich SetInputScope eingebaut.

Das UiAutomation-Zeugs wird noch durchlaufen. Mit dem SetInputScope lässt sich die automatisch eingeblendete Tastatur bzgl. des Layouts auch beeinflussen (z.B. nur Zahlen). Wenn man das ReadOnly des Edits auf True setzt und bei dem Get_IsReadOnly eine 0 zurück gibt, geht die Tastatur auch automatisch auf. Dann aber immer mit dem Standartlayout. Also das SetInputScope gehört zu dem Standartverhalten. Und wenn man kein Standart-Control hat, hilft das UiAutomation.

Vieleicht findet ja jemand mit den Infos noch den richtigen Einstieg in die Doku. Ich finde die Dokumentation bei Microsoft mittlerweile als nervend, weil man bei der Suche viel zu oft bei dem XAML-Zeugs landet. Und damit kann man in der VCL absolut nichts anfangen.

Aber jetzt noch zu Embarcadero. Was ich nicht verstehe, wieso haben die das SetInputScope nicht schon längst eingebaut. Für einen Entwickler ist das eine halbe Stunde.

Zitat:

Zitat von hotrs02 (Beitrag 1509475)

Ich habe noch einen weiteren Lösungsansatz gefunden: mir war aufgefallen, dass ein TEdit.SetFocus die virt. Tastatur nicht anzeigt.

Bei einem TEdit.SetFocus wird zwar auch das Ui-Zeugs durchlaufen, aber die Tastatur wird dadurch nicht beeinflusst. Also sie bleibt eingeblendet wenn sie eingeblendet war und bleibt ausgeblendet wenn sie ausgeblendet war. Wie man dann aber den Focus logikgesteuer versetzen kann mit automatischen ein/ausblenden der Tastatur ist mir ein Rätsel.

Zitat:

Zitat von hotrs02 (Beitrag 1509475)

Also habe ich zunächst versucht, in TEdit.OnClick oder TEdit.OnEnter die Eigenschaft ReadOnly auf FALSE zu setzen. Die Tastatur wurde aber leider weiterhin angezeigt. Dann habe ich mit einem Timer experimentiert, der in TEdit.OnClick / TEdit.OnEnter gestartet wird und nach einer Zeitspanne (250ms) die Eigenschaft ReadOnly auf FALSE setzt. Leider ebenfalls Fehlanzeige.

Was aber funktioniert ist, einfach zwei TEdit übereinander zu legen und die Sichtbarkeit zu steuern. Das obere TEdit hat die Eigenschaft ReadOnly auf TRUE gesetzt, das darunter liegende auf FALSE. Das obere ist zunächst sichtbar, das untere nicht. In OnEnter des oberen TEdit wird dann die Sichtbarkeit beider TEdit umgeschaltet, was letztendlich zu dem gewünschten Verhalten führt. Elegant finde ich die Lösung allerdings nicht.

Das klingt für mich mehr nach Hacken. Das wird dir bestimmt in ein paar Jahren um die Ohren fliegen.

Zitat:

Zitat von hotrs02 (Beitrag 1509475)

Ich werde mir jetzt auch mit Hinblick auf den Aufwand für die Anpassung älterer Dialoge überlegen müssen, welche Lösung ich umsetze.

Vieleicht ist ja das SetInputScope und der Verzicht auf eine eigene Tastatur die bessere Variante.

Zitat:

Zitat von himitsu (Beitrag 1509455)

Bei einem PC ohne Tastatur und mit Touch geht inzwischen die virtuelle Tastatur auf,
aber ich finde die "wichtige" Option im Windows nicht mehr.

Ich glaube die gibt es nicht mehr, wie im nicht Tabletmodus das Tastaturicon zum manuellen einblenden der Tastatur (*). Aber im Tabletmodus ist die Taskleiste leer, obwohl mehrere Anwendungen offen sind. Ich kann ja verstehen, dass man im Tabletmodus einiges anders macht, aber wie kann man da zwischen den laufenden Anwendungen wechseln. Manchmal frag ich mich, was für Zeugs die bei Microsoft konsumieren.

Zitat:

Zitat von himitsu (Beitrag 1509455)

Allerdings geht Sie (die angedockte Tablettastatur) immer erst beim zweiten Klick/Tippen ins Edit auf, was schon etwas blöd ist, wenn jemand nicht direkt weiß, dass es eine virtuelle Tastatur gibt.

Bei mir zum Glück nicht immer. Aber beim Notepad ist es genauso. Und beim Paserver-Fenster habe ich schon beinahe den Finger durchs Display gedrückt, weil die Tastatur absolut nicht aufgehen wollte.

Zitat:

Zitat von himitsu (Beitrag 1509455)

Dagegen ist das "freifliegende" OSK schon bissl blöd, denn beim Verschieben der Tastatur bekommt sie den Fokus und man muß immer erst wieder ins Edit reinklicken, damit die Tastatur funktioniert.
Und da das Drecksding immer im Weg ist, muß man es ständig verschieben.

Die Tastatur welche man im Startmenu bzw. den Einstellungen aufmachen kann, ist eine andere. Die ist echt unbrauchbar. Die automatisch Eingeblendete kann man ja auch freifliegend machen und die verhält sich schön smooth.

Zitat:

Zitat von himitsu (Beitrag 1509455)

Außerdem, wer kommt bitte auf die saublöde Idee eine Tastenkombination für das Aufgehen der Virtuellen zu bauen

Ja die sollten weniger konsumieren.

Zitat:

Zitat von himitsu (Beitrag 1509455)

Außerdem verwenden wir im Programm viel die F-Tasten, welche aber in der Tablettastatur komplett fehlen :wall:

Doch die gibt es auch.
Anhang 55276


*

Zitat:

Zitat von himitsu (Beitrag 1509455)

Die Tablettastatur (vermutlich die TabTip.exe) bekommt man ebenfalls, wenn man im Kontextmenü der Uhr das "Bildschirmtastatur anzeigen (Schaltfläche)" aktiviert und dann auf den Knopf drückt.

Jetzt schau ich nochmal durch, ob ich zu allem, wo ich Antworten wollte, auch was geschrieben habe und sehe da steht ja die Lösung. Vielen Dank. Ich suche in den Einstellungen zu der Tastatur und versuche jeden Buchstaben einzeln zu verstehen. Was macht die Einstellung an dieser Stelle? Sollte man die Drogenfahndung informieren?:-D

[himitsu]

Zitat:

Ich glaube die gibt es nicht mehr

Vor vielleicht 2 Monaten hatte ich ein Windows 10 zurückgesetzt (auf einem PC mit Touch und ohne Tastatur).

Nach bissl verzweifeltem mehrmaligem rumgeklicke in den Tastatur-Einstellungen war ich über diese Option gestoßen.
Ich glaube die war ganz weit unterhalb der anderen Option, zum Einblenden der Tastatur,

aber als ich für die Doku später nochmal danach sehen wollte ... seitdem finde ich die Option nicht mehr. :freak:

Zitat:

Was ich nicht verstehe, wieso haben die das SetInputScope nicht schon längst eingebaut

Die brauchen bekanntlich immer 10-20 Jahre, bis sie das Neue finden und eingebaut haben.

SetThreadDescription und sogar GetThreadDescription gibt es auch schon seit über 7 Jahren
und dennoch arbeitet TThread.NameThreadForDebugging immernoch ausschließlich mit einer Exception.
Echt blöd, denn wird der Debugger erst später angehängt, sind die Namen verloren und auch im Programm kann man die Namen nicht auslesen.


Für Unicode hatten sie auch 9 ähh 16 Jahre gebraucht. (WinNT/Win2000)
64 Bit (Windows) kam 10 ähh 18 Jahre zu spät.
Für macOS/OSX kam es fast genau 10 Jahre nach der Veröffentlichung.
Bei iOS brauchten sie dafür nur 4 Jahre.
64 Bit iOS/OSX kam auch wieder 1-2 Jahre zu spät. (viele konnten nicht mehr oder mußten mit der Beta kämpfen)
Und Linux ... da haten sie schonmal nach nur 2 Jahren ein Kylix ... aber der jetzige Linux-Compiler kam ebenfalls 16-17 Jahre zu spät.



[edit]
Ohhh, ich seh grade, dass SetInputScope gerade mal erst 21 Jahre alt ist. :oops:

[Der schöne Günther]

Ich wollte nur dalassen dass sich bei MS noch keiner dazu geäußert hat, aber vielleicht kommt da ja noch was...

[einbeliebigername]

Hallo,

Zitat:

Zitat von himitsu (Beitrag 1509721)

SetThreadDescription und sogar GetThreadDescription gibt es auch schon seit über 7 Jahren
und dennoch arbeitet TThread.NameThreadForDebugging immernoch ausschließlich mit einer Exception.
Echt blöd, denn wird der Debugger erst später angehängt, sind die Namen verloren und auch im Programm kann man die Namen nicht auslesen.

Das ist doch auch wieder so einfach und schnell umsetzbar. Ja, Ok, Debugger ist vieleicht etwas aufwendiger und beim Remotedebugger muss etwas mehr gemacht werden. Aber das ist doch kein Ding wo gesamt Embarcadero Wochen, Monate dran arbeitet.

Zitat:

Zitat von Der schöne Günther (Beitrag 1509729)

Ich wollte nur dalassen dass sich bei MS noch keiner dazu geäußert hat, aber vielleicht kommt da ja noch was...

Hoffentlich bekommst du da eine Antwort. Vielleicht kann man da auch Antworten auf die anderen offenen Fragen zur Bildschirmtastatur bekommen. Obwohl das ja eigentlich Aufgabe von Embarcadero wäre.

[himitsu]

Im Notfall macht man einfach Beides, so lange bis man fertig ist.
Da diese Funktion ja erst seit Windows 10 existiert, bräuchte man eh ein IF-WinVer im Programm. (gut, man könnte jetzt auch sagen, dass die anderen Windowse eh tot sind, also egal :stupid:)

Und sie haben ja bereits im Debugger/RemoteDebugger/PAServer eine Stelle, wo sie den Stacktrace auslesen, dafür haben sie bereits das Handle des Threads und können somit ohne Probleme auch GetThreadDescription aufrufen.
Und die andere Stelle, wo die Threads aufgelistet werden, da haben sie bestimmt auch die Handles und können das ebenfalls machen.
:roll:

[hotrs02]

@einbeliebigername
Zunächst danke für deine Bemühungen. Vielleicht kann ich mich irgendwann einmal revanchieren.

Zitat:

Zitat von einbeliebigername (Beitrag 1509719)

Das UiAutomation-Zeugs wird noch durchlaufen. Mit dem SetInputScope lässt sich die automatisch eingeblendete Tastatur bzgl. des Layouts auch beeinflussen (z.B. nur Zahlen). Wenn man das ReadOnly des Edits auf True setzt und bei dem Get_IsReadOnly eine 0 zurück gibt, geht die Tastatur auch automatisch auf. Dann aber immer mit dem Standartlayout. Also das SetInputScope gehört zu dem Standartverhalten. Und wenn man kein Standart-Control hat, hilft das UiAutomation.

Tatsächlich lässt sich damit die automatische Anzeige der virt. Tastatur so unterdrücken, wie wir es benötigen würden. Allerdings bleibt hier noch das Problem der Auswertung der Tastatureingaben, welche ein TEdit mit der Eigenschaft ReadOnly = TRUE natürlich einfach ignoriert. Und da wir die virt. Tastatur nur gezielt unterbinden möchten, könnte ich hier einfach direkt auf ein TEdit mit der Eigenschaft ReadOnly = TRUE zurückgreifen und auf das UIAutomation Framework verzichten.

Bis auf weiteres haben wir uns für die Lösung mit den doppelten Steuerelementen und der Steuerung der Sichtbarkeit entschieden. Damit erreichen wir in unserem Fall die größte Flexibilität.

Zitat:

Zitat von einbeliebigername (Beitrag 1509719)

Vieleicht ist ja das SetInputScope und der Verzicht auf eine eigene Tastatur die bessere Variante.

In unserem Anwendungsfall ist das leider wenig zielführend. Unsere virt. Tastatur verfügt über zusätzliche Funktionalität (Auslösung bestimmter Aktionen), die jederzeit erreichbar sein muss.

[hotrs02]

Zitat:

Zitat von Der schöne Günther (Beitrag 1509729)

Ich wollte nur dalassen dass sich bei MS noch keiner dazu geäußert hat, aber vielleicht kommt da ja noch was...

Danke für das Update!

[himitsu]

Zitat:

Zitat von einbeliebigername (Beitrag 1509719)

Doch die gibt es auch.
Anhang 55276

OK, aber auch erst nach Umschalten.
Kein Direktdrücken für eine Schnellwahlfunktion.

Für F-Tasten immer stichtbar und Zahlen als Zehnerblock wäre mehr als ausreichend genug Platz. :cry:

[himitsu]

Joar, also bezüglich SetInputScope gibt es noch garkeine Meldungen auf https://quality.embarcadero.com


und beim Anderen .... joar, hatte schon wieder ganz vergessen, aber da hat sich eh nichts getan :freak:
https://quality.embarcadero.com/brow...Description%22

[einbeliebigername]

Hallo,

ich habe noch weiter geforscht. Mir fehlt ja noch das Reagieren auf das Ein-/Aus-blenden der Tastatur. Ich habe mit den Schlagwörtern und Bezeichnern von der Seite https://docs.microsoft.com/de-de/win...touch-keyboard die Suchen gequält.

Bei einer Suche für dieses Thread bin ich mal auf den Blogbeitrag (https://blogs.embarcadero.com/de/delphi-winui-3-demo/) von Embarcadero zum Thema Win UI 3 gestoßen. Dort geht es eigentlich mehr um XAML, aber man ist ja schon etwas verzweifelt und greift nach dem kleinsten Strohhalm. Ich hatte auch schon das Demo-Projekt aus GetIt auf der Platte und bin mit einem Bezeichner fündig geworden.

In der Unit

Delphi-Quellcode:

Winapi.UI.ViewManagement

gibt es die Klasse

Delphi-Quellcode:

TCore_CoreInputView

mit der Klassenmethode

Delphi-Quellcode:

GetForCurrentView

. Diese gibt ein Interface vom Type

Delphi-Quellcode:

Core_ICoreInputView

zurück, welches unteranderem zwei Funktionen

Delphi-Quellcode:

TryShowPrimaryView

und

Delphi-Quellcode:

TryHidePrimaryView

kennt. Ich habe das mal ausprobiert (aktualisiertes Projekt im Anhang). Bei mir geht mit den Funktionen die Bildschirmtastatur auf und zu.

Bloß mit dem OcclusionsChanged werde ich nicht ganz warm. Die Liste, welche man da bekommt, ist sehr oft leer. Und bei dem OcclusionKind hab ich bis jetzt nur Floating gesehen.

Nun gilt es an die richtigen Interfaces zu kommen. Mich interessiert z.B.:

Delphi-Quellcode:

  Core_ICoreInputView4 = interface(IInspectable)
  ['{002863D6-D9EF-57EB-8CEF-77F6CE1B7EE7}']
    function add_PrimaryViewShowing(handler: TypedEventHandler_2__Core_ICoreInputView__Core_ICoreInputViewShowingEventArgs): EventRegistrationToken; safecall;
    procedure remove_PrimaryViewShowing(token: EventRegistrationToken); safecall;
    function add_PrimaryViewHiding(handler: TypedEventHandler_2__Core_ICoreInputView__Core_ICoreInputViewHidingEventArgs): EventRegistrationToken; safecall;
    procedure remove_PrimaryViewHiding(token: EventRegistrationToken); safecall;
  end;

[Der schöne Günther]

Du warst schneller, den IInputView hatte MS jetzt auch:

Zitat:

Emily Bender

Howdy, I believe this may help: CoreInputView.PrimaryViewShowing Event (Windows.UI.ViewManagement.Core) - Windows UWP applications | Microsoft Docs

There's a function called TryCancel, so when the SIP wants to show, in your handler you call TryCancel

LMK if there's more help i can provide, a thread over mail may be helpful as I can loop in relevant text input devs who can help debug

[hotrs02]

Vielen Dank an euch beide für eure Mühen.

Das kommt genau richtig, der Ansatz mit dem doppelten, schreibgeschützten Eingabefeldern hat nämlich leider doch einen Haken. Wir nach auf von TEdit.SetFocus das Eingabefeld erneut angeklickt, so öffnet sich letztendlich doch leider noch die Tastatur.

Ich werde mir die Tage die genannte Schnittstelle genauer anschauen.

[einbeliebigername]

Hallo,

Zitat:

Zitat von Der schöne Günther (Beitrag 1509897)

Du warst schneller,

Ach, ich schnell ... ne.

Zitat:

Zitat von Der schöne Günther (Beitrag 1509897)

den IInputView hatte MS jetzt auch:

Ne, MS hat das bestimmt schon länger. Wir haben es jetzt teilweise auch. Es fehlt noch vieles.

Zitat:

Zitat von Der schöne Günther (Beitrag 1509897)

Zitat:

Emily Bender

Howdy, I believe this may help: CoreInputView.PrimaryViewShowing Event (Windows.UI.ViewManagement.Core) - Windows UWP applications | Microsoft Docs

There's a function called TryCancel, so when the SIP wants to show, in your handler you call TryCancel

LMK if there's more help i can provide, a thread over mail may be helpful as I can loop in relevant text input devs who can help debug

Ich habe bei meinem Testprojekt weiter gemacht (aktualisierte Version im Anhang) und soweit vollständig vorhanden die Events implementiert. Für das enthaltene Memo habe ich das TryCancel beim PrimaryViewShowing mal umgesetzt.

Es funktioniert wenn man die Bildschirmtastatur generell nicht aufgehen lassen will (also immer ein TryCancel macht, aber ich habe das bei Anwendungswechsel noch nicht getestet). Das Problem ist, dass dieses PrimaryViewShowing bei jedem Focuswechsel gefeuert wird, auch wenn die Bildschirmtastatur schon eingeblendet ist. Wenn man das TryCancel aufruft wenn die Tastatur bereits eingeblendet ist, geht diese nicht zu und kommt etwas durcheinander. Sie schließt sich dann nicht mehr automatisch. Leider fehlt noch eine Möglichkeit abzufragen ob die Tastatur eingeblendet ist.

Beim stöbern in der MS-Doku bin ich auf CoreTextEditContext.InputPaneDisplayPolicy gestoßen. Damit soll man das automatische Einblenden der Tastatur abschalten können. Der nötige Aufzählungstyp ist auch schon in der Unit Winapi.UI.Text vorhanden. Aber das entsprechende Interface fehlt.

[hotrs02]

Ich hatte heute Zeit, mir dein letztes Beispielprojekt einmal genauer anzuschauen. Leider funktioniert die Unterdrückung der virt. Tastatur auf dem verwendeten Handheld auf Grund der Verwendung von Windows 10 Enterprise LTSC (Version 1809) nicht: das Interface Core_ICoreInputView4 wird von dieser Windows Version noch nicht unterstützt, es wurde laut Dokumenation erst in Version 2004 eingeführt.