![]() |
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. |
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. |
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 13:15 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