Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Object-Pascal / Delphi-Language (https://www.delphipraxis.net/32-object-pascal-delphi-language/)
-   -   Delphi Enter oder nicht Enter... (https://www.delphipraxis.net/210759-enter-oder-nicht-enter.html)

Delbor 5. Jun 2022 16:08

Delphi-Version: 11 Alexandria

Enter oder nicht Enter...
 
Hi zusammen

Mein Programm startet Pdfs von Festplatte und zeigt sie in einem Fremdprogramm an. Über eine Eingabemaske, die Edits, Compos, einen DateTimepicker und ein Memo enthält, generiere ich Records für eine DB. Das funktioniert soweit schon mal, aber der Haken ist: Bei allen diesen Feldern frage ich die Entertaste ab; wenn diese gedrückt wurde, ist die Eingabe beendet, der Eintrag wird (noch nicht) erfasst und der Focus weitergereicht. Das 'Problem' dabei ist: die Entertaste erzeugt im Memo einen Zeilenumbruch - ein Verhalten, das User wohl mehr oder weniger erwarten, und deshalb auch nicht geändert werden soll. Also muss ich wohl das Ende der Eingabe anders behandeln. Der erste Gedanke heisst hier: ShortCut, also sowas wie Ctrl(Strg) + Enter.

Ich denke, da komme ich um eine Tastenkombination nicht herum. Wichtig dabei ist mir nur, dass sich der User keine exotischen Kürzel merken oder sogar einen 'wilden Fingertanz' auf der Tastatur aufführen muss (zB. Q+1 und l+_ gleichzeitig drücken)

Hat jemand Vorschläge?

Gruss
Delbor

blawen 5. Jun 2022 16:25

AW: Enter oder nicht Enter...
 
Zitat:

Zitat von Delbor (Beitrag 1506796)
...die Edits, Compos, einen DateTimepicker und ein Memo enthält...

Wieso arbeitest Du nicht mit der Tab-Taste und reagierst auf das verlassen des "Felds"?

Gausi 5. Jun 2022 16:43

AW: Enter oder nicht Enter...
 
Als Denkanstoß: Wird häufiger ein Zeilenumbruch in dem Memo vom User "erwartet", oder das Weiterspringen ins nächste Eingabefeld?

Bei WhatsApp im Browser ist es z.B. so, dass ein "Enter" bei der Eingabe das bisher getippte abschickt. Möchte man in der Nachricht eine neue Zeile beginnen, muss man Shift+Enter benutzten. Das ist im Grunde konsistent zu Word, wenn man "Nachricht" mit "Absatz" gleichsetzt. Das könnte bei dir ggf. auch passen, wenn Absatz = Eingabefeld.

Wäre das eine Option bei dir?

peterbelow 5. Jun 2022 18:21

AW: Enter oder nicht Enter...
 
Zitat:

Zitat von Delbor (Beitrag 1506796)
Hi zusammen

Mein Programm startet Pdfs von Festplatte und zeigt sie in einem Fremdprogramm an. Über eine Eingabemaske, die Edits, Compos, einen DateTimepicker und ein Memo enthält, generiere ich Records für eine DB. Das funktioniert soweit schon mal, aber der Haken ist: Bei allen diesen Feldern frage ich die Entertaste ab; wenn diese gedrückt wurde, ist die Eingabe beendet, der Eintrag wird (noch nicht) erfasst und der Focus weitergereicht. Das 'Problem' dabei ist: die Entertaste erzeugt im Memo einen Zeilenumbruch - ein Verhalten, das User wohl mehr oder weniger erwarten, und deshalb auch nicht geändert werden soll. Also muss ich wohl das Ende der Eingabe anders behandeln. Der erste Gedanke heisst hier: ShortCut, also sowas wie Ctrl(Strg) + Enter.

Ich denke, da komme ich um eine Tastenkombination nicht herum. Wichtig dabei ist mir nur, dass sich der User keine exotischen Kürzel merken oder sogar einen 'wilden Fingertanz' auf der Tastatur aufführen muss (zB. Q+1 und l+_ gleichzeitig drücken)

Hat jemand Vorschläge?

Gruss
Delbor

Benutze doch einen Button mit Default = true, der feuert wenn irgendwo auf dem Form Enter/Return gedrückt wird, soweit das aktive Control die Taste nicht selbst bearbeiten will. TMemo/TDBMemo tut das, da brauchst Du also keine Sonderbehandlung.

Meiner (unbescheidenen) Meinung nach sollten Daten nur gespeichert werden, wenn der Benutzer das explizit anfordert. Das macht es einfacher, Eingabefehler zu erkennen und zu korrigieren bevor sie in der Datenbank landen.

Delbor 5. Jun 2022 18:35

AW: Enter oder nicht Enter...
 
Hi zusammen

Die Tab-Taste als Ersatz für die bisherige Entertaste? Allerdings ist es nicht unbedingt leicht, den bisherigen Code zu ersetzen - zumindest hab ich vorerst nichts gefunden (Embarcadero Wicki). Meine bisherige Umsetzung:
Delphi-Quellcode:
procedure TOfficerAlexMain.AlexFilePropertyFrame1Edi_DokuNameKeyPress(Sender: TObject; var Key: Char); // Dokuname          Key = vkTab
begin
  if Key = #13 {vkTab} then
  begin
    FInsertPdfDocument.DokuName:= AlexFilePropertyFrame1.Edi_DokuName.Text;
    AlexFilePropertyFrame1.Edi_DokuName.Color := clYellow;
    AlexFilePropertyFrame1.Edi_DocThema.SetFocus;
  end;
end;
Dieser vkTab ist allerdings ein Word. Soviel ich weiss, wäre das virtuellle Tastenkürzel in Windows VK_Tab, bin mir dessen aber nicht mehr sicher.
Aber da ist doch noch eine grössere Codesammlung der letzten Jahre...

Ich habe bei Embarcadero aber auch eine key-Liste mit char-werten gesucht, aaber ich denke, das war wohl derfalsche Suchbegriff.


Gruss
Delbor

mmw 5. Jun 2022 19:12

AW: Enter oder nicht Enter...
 
Hallo,

eine Liste bzw. die entsprechende Unit wäre hier

https://docwiki.embarcadero.com/Libr...System.UITypes

Gruß

DeddyH 5. Jun 2022 19:13

AW: Enter oder nicht Enter...
 
Tab ist unter Windows die Standard-Taste zum Fokuswechsel, da muss man im Normalfall nichts selbst programmieren. Aber falls es doch notwendig werden sollte und es unbedingt im Keypress-Event sein muss, versuch es mal mit #9.

Uwe Raabe 5. Jun 2022 21:23

AW: Enter oder nicht Enter...
 
Vielleicht schaust du mal rein: Deutsche CodeRage 2022 am 14. Juni 2022 um 14:00 - 14:45 Uhr

Zitat:

Observer - simpel und elegant
Um auf Eingaben zu reagieren schreiben wir in Delphi üblicherweise Event-Handler. Doch gibt es noch andere Wege, die oft einfacher, flexibler und wesentlich eleganter sind. Egal ob <Tab> oder <Enter>, ob Änderung oder Validierung. Für viele VCL-Controls braucht es dafür nur einen Einzeiler - und alles ganz ohne Events.

jobo 5. Jun 2022 23:13

AW: Enter oder nicht Enter...
 
Wir hatten mal eine Eingabemaske, die zur schnellen Erfassung von eingesendeten Briefen diente, standardisierte Fälle, viele. Dort sollte gemäß Kundenwunsch alles mit Enter funktionieren. Es gab offenbar Mitarbeiter, die es gewohnt waren, so zu arbeiten. Die Umsetzung war dann glaub ich so, dass Enter und Tab irgendwie gleichwertig funktionierte. "Alles" funktionierte mit Enter. Ein Memofeld war allerdings nicht dabei. Und das wäre die Situation die Du umsetzen möchtest?

Es wären Verfahren mit Shift Enter oder Alt Enter wie bei Word oder Excel denkbar. In Excel ist ein Zeilenumbruch innerhalb einer Zelle glaub ich Alt Enter. Also quasi-Standard.

Alternativ fällt mir spontan ein, dass man mehrfaches Enter als Ausstieg definieren könnte, 2x oder 3x. Geht in < 1/3 Sekunde. Daran kann man sich leicht gewöhnen und muss die Finger auf der Tastatur nicht umsetzen bzw. braucht seine Gewohnheit nicht ändern. Und ein Memoeintrag, der 3 Zeilenumbrüche erfordert, wäre vermutlich auch nie nötig.

Die Mitarbeiter sind damals wirklich mit einem Affenzahn durch das Formular gerattert. 2x Enter zum Verlassen der Memobox oder 3x wäre vielleicht eine pragmatische Lösung.

himitsu 5. Jun 2022 23:21

AW: Enter oder nicht Enter...
 
Zitat:

Dort sollte gemäß Kundenwunsch alles mit Enter funktionieren. Es gab offenbar Mitarbeiter, die es gewohnt waren, so zu arbeiten
Bei uns auch noch.
Scheint zu DOS-Zeiten (Turbo Pascal) öfters mal so gewesen zu sein.

Für die Eingabe vieler Zahlen ist es so einfacher, das Enter im Nummerblock zu nehmen (Tab ist dort soooo weit weg),
genauso wie eben das [+] oder [=] bei Taschenrechnern/Rechenmaschinen, welches oft auch an dieser Stelle war.


Am Einfachsten via KeyPreview allgemein in der Form abfangen.
Bei Memos Key auf 0 setzen (außer wenn zusätzlich STRG gedrückt wurde), um die Standard-Behandlung des Enter dort zu unterbinden.
Besser bereits im KeyDown, anstatt im KeyPress.

Uwe Raabe 5. Jun 2022 23:54

AW: Enter oder nicht Enter...
 
Die Standardfunktionalität von <Return> in einem Memo würde ich nicht entfernen (zumindest nicht wenn WantReturn auf True steht). Das wird nach 35 Jahren Windows einfach erwartet. Für die anderen Controls kann man das ja machen und bei <Enter> bzw. <Return> in das nächste Eingabefeld springen. Allerdings würde ich das vorhandene <Tab>-Verhalten dann auch nicht wegnehmen. Viele haben sich ja mittlerweile daran gewöhnt und jüngere würden kaum auf die Idee kommen, mit <Return> oder <Enter> zum nächsten Control zu wandern.

So gesehen ist das Verlassen des Controls - insbesondere des Memos - ein guter Hinweis für den Abschluss der Eingabe in dem Control. Da bietet sich auf den ersten Blick das OnExit-Event an. Der wird zwar nicht getriggert, wenn das Control das einzige mit TabStop = True ist, aber das ist in der Regel ja eher selten der Fall.

Fazit: Bei einem Memo mit WantReturn = True würde ich das <Return> dem Memo überlassen (schließlich fragt es ja explizit danach), während bei anderen Controls bei <Return> das nächste Control angesprungen wird. In allen Fällen sollte die Auswertung im OnExit passieren. Damit bekommt man dann auch die Fälle mit, bei denen der Anwender per Maus, Shortcut oder Accelerator zu einem anderen Control wechselt. Für Spezialfälle wie Wechsel zu einem anderen Form oder einer anderen Anwendung müsste man halt festlegen, ob das als Eingabeabschluss gewertet werden soll oder nicht.

himitsu 6. Jun 2022 00:02

AW: Enter oder nicht Enter...
 
Nja, kann man sich drüber streiten, ob MultiLine-Edits das Enter normal behandeln und z.B. Strg+Enter zum Verlassen,
oder andersrum, damit alle Controls sich konsistent verhalten, als Enter überall gleich und der Zeilenumbruch mit Strg+Enter, so wie es einige Programme ebenfalls machen.
OK, ICQ ist tot, aber da war es auch so, also Enter zum Senden (für Weiter) und Strg+Enter für Zeilenumbruch.

So oder so, es ist vieles Möglich.




Gut, bei "uns" stört es nicht, da Memos nicht direkt zur Eingabe genutzt werden und es demnach nur ein Enter gibt (das wie Tab).
(zum Bearbeiten geht es dafür in ein Edit-Fenster, bei Doppelklick oder beim Drücken von Buchstaben/Zahlen, bzw. F2)




Vermehrt fällt mir auch auf, dass Gerätehersteller (Tastaturen und Notebooks) auch die Tastaturnutzung erschweren ... muß alles nur noch Touch sein.
Die Kontextmenü Taste fehlt der ist nur noch zusammen mit Fn und unmöglichen Fingerverränkungen nutzbar,
sowie auch die Tasten wie Drucken und PageScroll versteckt sind. und ich glaube [Pause] nutzt sowieso kaum noch ein Programm.
Dafür sind die Multimedia-Tasten direkt nutzbar, wobei oft nicht mehr als Einzeltaste, sondern alternativ stantardmüßig aktiv über die F-Tasten gelegt.

Delbor 7. Jun 2022 21:46

AW: Enter oder nicht Enter...
 
Hi zusammen

Ich habe mich nun doch für eine Kombination aus 2 Tasten entschieden: Ctrl->Enter. Was dafür spricht, ist die Bedienung mit zwei Fingern der selben Hand (Zeigefinger [Enter] und Daumen [Control]) oder entspannt mit der rechten und linken Hand. Statt Control wäre mit den selben Bedingungen für den user auch eine Variante mit Shift möglich.

Gruss
Delbor


Alle Zeitangaben in WEZ +1. Es ist jetzt 00:50 Uhr.

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz