Automatische Anzeige der virt. Tastatur unterdrücken

[hotrs02]

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

Zitat von einbeliebigername:

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 von hotrs02:

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 von hotrs02:

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.

[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 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 (Dp211080.AutomatischeAnzeigeDerVirtTastaturUnterdruecken.zip) 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 von hotrs02:

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 von hotrs02:

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 von hotrs02:

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 von himitsu:

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 von himitsu:

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 von himitsu:

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 von himitsu:

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 von himitsu:

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

Doch die gibt es auch.



*

Zitat von himitsu:

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?

[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.

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.

[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 von himitsu:

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 von 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...

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 )

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.