Das Notes Forum
Domino 9 und frühere Versionen => Entwicklung => Thema gestartet von: adminnaddel am 30.09.02 - 17:29:09
-
hallo liebe gemeinde,
gibt es eine möglichkeit die Tab-Funktions zu umgehen und mit der Enter-Taste ins neue FIELD zu gelangen?
danke für eure mithilfe
mfg
-
hoy,
ich denke das geht nicht. Die Enter-Taste erzeugt in einem Feld einen Zeilenumbruch. Dazu bedürfte es dann einer ständigen Überwachung des Feldes, daß sobald ein Zeilenumbruch eingegeben wird zum neuen/nächsten Feld gewechselt werden soll...
-
Hi,
wenn Du wie oben beschrieben vorgehst:
Dazu bedürfte es dann einer ständigen Überwachung des Feldes, daß sobald ein Zeilenumbruch eingegeben wird zum neuen/nächsten Feld gewechselt werden soll...
...hast Du Performance einbußen ohne Ende!
Ansonsten kenne ich auch KEINE Möglichkeit dies zu umgehen.....SORRY!
C
Ya
-
trotzdem sage ich danke dür die antworten!
mfg
-
Hallo Forum,
hat sich bei diesem Problem in den letzten zwei Jahren etwas getan?
Ich habe jetzt nämlich auch so ein ähnliches Problem.
Gruß Teletambi
-
Nein, es würde auch Windows-Standards brechen, Enter ist entweder im Textfeld ein Zeilenumbruch oder bei Mehrfachwerten Eingabebestätigung oder löst gemäss UI-Standards die Standardaktion (normalerweise der OK-Buhtong) aus. Damit würde man beim Umbiegen von Enter auf die TAB-Funktion diesen UI-Standard verletzen
-
Jens hat Recht. Solche Kreativlösungen verwirren nur die Anwender.
Frage: Geht das eigentlich mit der C-Api?
<aehem>
In Java-Gui-APIs kann man für einzelne widgets wie Textfelder selektive event listener anmelden, die aus der Event Queue die entsprechenden Events selektiv rausfischen und CallBack-Methoden anbieten.
Callback Methode heisst: Das System bietet Methoden/Funktionen an, die vom System aufgerufen werden, wenn sich bestimmte Stati in der GUI verändern (Maske wird gespeichert, Maske wird geöffnet, etc.)
In Notes sind die meisten CallBack Methoden (queryOpen, queryModeChange, querySave) Masken-Gebunden. Auf Feldebene gibts diese Enter und Exit, sowie Eingabevalidierung und Eingabeumsetzung.
Das ist keine Wertung. Beschränkung auf weniger kann auch mehr Übersichtlichkeit bedeuten.
</aehem>
correct me if I am wrong
Axel
-
Sorry Axel, aber Du wirfst da Callbacks und Events durcheinander. Notes kennt nur einen einzigen Callback, das ist der Timer, alles andere sind Events. Auch wenn sie manchmal änlich aussehen, bestehen da doch wesentliche Unterschied.
Und, nein, mit der Notes-C-Api liesse sich das nicht umbiegen, da müsste man schon die Win-API heranziehen, dort ist das dann aber ohne weiteres möglich, auch wenn der Aufwand, es zu tun, ziemlich gross werden könnte (man müsste die Routine aus der Maske heraus ein- und ausschalten, wobei das durchaus lösbar wäre).
-
Hallo Jens,
kannst du mir bitte den Unterschied erklären?
Ich sehe das so:
Der User klickt einen Button zum Speichern eines Dokuments.
Gegen Domino wird ein Event geschickt, dass Domino anfordert dieses Dokument zu speichern.
Domino ruft die QuerySave-Methode auf. Der code, den der Entwickler da reingeschrieben hat, wird ausgeführt (das sehe ich als eine CallBack Methode an. Das Event selber bekommt der Entwickler nie zu Gesicht).
Domino ruft die PostSave Methode auf (wie QuerySave).
QuerySave und PostSave sind also Methoden, für die ein Kontrakt besteht, dass sie auf ein bestimmtes Event im Lebenszyklus eines Dokuments (eigentlich UIDoc) vom System, sprich Domino, aufgerufen werden.
Der Entwickler hat die Möglichkeit hier code reinzuschreiben und er kann sicher sein, dass sie bei bestimmten Lebenszyklusevents (query-save= vor dem Speichern) vom System aufgerufen werden (call-back)
Was ist daran verkehrt? Möglicherweise habe ich da was falsch verstanden.
Lotus nennt diese Methoden (querySave, etc.) events. Aber sind es nicht eigentlich callBack-Methoden?
Wir wissen alle wie ungenau diese Begriffe von unterschiedlichen Herstellern verwendet werden. Vielleicht überseh ich da auch irgendwelche wichtigen Aspekte.
Gruß Axel
-
Natürlich kann ich Dir den Unterschied erklären.
Wenn Du Events verarbeiten willst, musst Du einen Event-Handler in einem vordefinierten Punkt in den Code der Umgebung einhängen. Der Domino-Designer erledigt das für Dich im Hintergrund. Der Eventhandler wird von der Umgebung in jedem Falle aufgerufen, wenn eines der definierten Events eintrifft. Dein Event-Handler hat eine ganz bestimmte Struktur zu erfüllen und sich an ein eng defiiniertes Protokoll zu halten, so muss er beispielsweise überprüfen, ob das Event überhaupt das ist, was er erwartet (macht wiederum der Designer automatsich) und am Schluss muss er mitteilen, ob das Event abgearbeitet ist oder nicht. Das ist vom Designer teilweise versteckt, sichtbar dort, wo es einen "Continue"-Parameter gibt.
Für einen Callback musst Du eine eigene-weitgehend beliebige-Routine schreiben und per Registrationsaufruf gegenüber der Umgebung registrieren. Siehe im Domino den Timer, da musst Du eine Prozedur schreiben und sie dann als Callback-Prozedur gegenüber dem Timer mit einem Registrationsaufruf ausdrücklich registrieren.
Auch wenn sich manche Sachen mit beiden Technologien realisieren lassen (aber normalerweise nicht in derselben Umgebung) und für den Endanwender kein Unterschied besteht, so sind es doch grundverschiedene Technologien, wobei der "normale" Anwenderentwickler davon in der Regel auch wieder nichts mitbekommt, denn mit Event-Handler kann man mit den meisten Umgebungen etwas anfangen, hingegen die Callbacks sind doch schon ziemlich systemnah (wenn auch nicht zwingend).
Die Begriffe zu verwässern ist unschicklich, das macht die Kommunikation diffus, etwa so ähnlich, wie wenn man ständig den Anmelde-/Anzeigenamen ändert.
-
Einverstanden. Eventhandler ist der gebräuchlichere Begriff.
Aber so eindeutig ist das denn doch nicht.
Z.B. werden in EJB eventhandlern sehr ähnliche Methoden wie z.B. ejbCreate, ejbPostCreate, ejbLoad, etc. allgemein als call-Back Methoden bezeichnet.
In frameworks wird struts z.B. auch.
Ist wohl eine Art babylonische Sprachverwirrung.
Gruß Axel
-
Wenn Du Events verarbeiten willst, musst Du einen Event-Handler in einem vordefinierten Punkt in den Code der Umgebung einhängen. Der Domino-Designer erledigt das für Dich im Hintergrund. Der Eventhandler wird von der Umgebung in jedem Falle aufgerufen, wenn eines der definierten Events eintrifft. Dein Event-Handler hat eine ganz bestimmte Struktur zu erfüllen und sich an ein eng defiiniertes Protokoll zu halten, so muss er beispielsweise überprüfen, ob das Event überhaupt das ist, was er erwartet (macht wiederum der Designer automatsich) und am Schluss muss er mitteilen, ob das Event abgearbeitet ist oder nicht. Das ist vom Designer teilweise versteckt, sichtbar dort, wo es einen "Continue"-Parameter gibt.
wie wenn man ständig den Anmelde-/Anzeigenamen ändert.
Jede eventbasierte Umgebung leistet das. VisualBasic-Masken, swing, swt, ejb, servlets, eclipse-plugin-framework, etc..pp.
-
btw. danke für die Erklärungen soweit. ;)
Nach 6 Stunden zu wissen, die Halbzeit der heutigen Schicht der extrem coolen (Ironie) Aufgabe des Zeichnens von UML-Diagrammen in Rational Rose 2002 (DrecksTool-Kandidat) aus guten aber völlig kommentarlosen Code, macht nicht nur ein bischen genervt.
ES IST DER TOTALE DRECKSJOB.
-
Hallo Forum,
ich hab hier im wesentlichen ein ganz anders Problem und zwar habe ich eine Dialogbox in der der Benutzer ein Passwort eingeben muss. Statt auf den Ok-Button zu klicken, drücken die Benutzer immer "Enter" als Bestätigung der Eingabe, was natürlich zum Zeilenumbruch führt.
Gruß Teletambi
-
Hallo Forum,
ich hab hier im wesentlichen ein ganz anders Problem und zwar habe ich eine Dialogbox in der der Benutzer ein Passwort eingeben muss. Statt auf den Ok-Button zu klicken, drücken die Benutzer immer "Enter" als Bestätigung der Eingabe, was natürlich zum Zeilenumbruch führt.
Gruß Teletambi
Das regele ich immer so: Extra Button mit
@Prompt([PASSWORD]; "Passwort"; "Bitte geben Sie das Passwort ein:")
Ein ENTER schließt dann den Dialog.
Andreas
-
Jede eventbasierte Umgebung leistet das. VisualBasic-Masken, swing, swt, ejb, servlets, eclipse-plugin-framework, etc..pp.
Heute ja, zum Glück, ich habs noch erelebt, dass ich es selber machen musste. Naja, ist nicht besonders kompliziert, besteht zu 70 Prozent aus einem Switch-Statement und Aufrufen der eigenen Handler ......
-
Jede eventbasierte Umgebung leistet das. VisualBasic-Masken, swing, swt, ejb, servlets, eclipse-plugin-framework, etc..pp.
Heute ja, zum Glück, ich habs noch erelebt, dass ich es selber machen musste. Naja, ist nicht besonders kompliziert, besteht zu 70 Prozent aus einem Switch-Statement und Aufrufen der eigenen Handler ......
Das ist kein Privileg der langjährigen Erfahrung. ;D
In folgenden Bereichen in Java begegnet mir das in praktisch gleicher Form relativ oft (eigene Event Handler schreiben):
- XML-Parsing mit der SAX-Api
- Webprogrammierung ohne struts, webwork2, etc.
- Dokumentbasierte Webservices (poste morgen ein paar Bildchen zum Beweis.)
- Scheduler getriggerter code.
- Observer Pattern und MultiThreading in Java-GUIs.
Das heisst dann zwar gerne ActionHandler, ist aber im Prinzip das gleiche.
Nur macht man das nicht mehr mit switch, sondern mit behavioral patterns(?) --> gof.template z.B. und gerne mit der Introspection API. Geht relativ einfach. Man muss nur aufpassen, dass man sich zu einem geeigneten Zeitpunkt ein wirklich gutes Error-Handling für die Konstruktion überlegt.
Wie du gesagt war es vorher nicht so schwierig und so irrsinnig vereinfachen tun es diese Dinge auch nicht.
Hab ein paar einfache Sachen in der Überlegung, wo ich das ein bischen praktisch darstellen kann. Mit source-code.
Es ist in dieser Ökonomie der kleineren, stets gefährdeten Projekte und des ständigen Lernens schwierig Urlaub zu bekommen. :-\
Gruß Axel
-
Nein, es würde auch Windows-Standards brechen
Jens hat Recht. Solche Kreativlösungen verwirren nur die Anwender.
Räusper:
Macht wohl Microsoft auch, also eigene Windows-Standards brechen.
Beispiel:
Ich hatte früher mal mit Navision (mehr als Anwender / Daten per Copy&Paste rausziehen) zu tun. Für die, die es nicht kennen: Navision ist ein Warenwirtschaftssystem und wurde von einigen Monaten von M$ aufgekauft.
Soweit ich weiss wird auch in aktuellen Navision-Releases (heißt ja jetzt wohl "Microsoft Business Solutions") via Enter-Taste (also Return) ein neues Feld angesprungen in einer Maske (und kein Zeilenumbruch eingefügt - wieso auch: Feld lässt Zeilenumbruch nicht zu!).
Erscheint mir auch intuitiv. Mein Entwickler gibt mir als Plain Anwender eine Maske vor. Alles soweit eingeschränkt (in Zahlenfeldern kein Text erlaubt, evtl. noch max. Textlänge, etc.).
Daher erscheint es mir durchaus für sinnvoll, den Anwender mittels ENTER in ein neues Feld zu lotsen, wenn im current Field eh kein Zeilenumbruch erlaubt ist.
Fazit: Ist meines Erachtens kein Brechen eines Standards, sondern wäre eine Bereicherung für User. Auch wenn aktuell wohl in Notes nicht ohne weiteres umsetzbar in Masken.
-
achso Adminade:
Wenn du das aus irgendwelchen seltsamen Gründen wirklich brauchst, kannst du es mit einem Applet implementieren. Vielleicht komme ich dazu, das mal schnell als Beispiel zu posten. Vielleicht auch nicht.
Gruß Axel
-
@Matthias: wir haben parallel gepostet.
Ich kenne solche Anforderungen. Lohnen tut sich der Aufwand nicht.
Sie kommen in 98% aller Fälle von irgendwelchen Projektmanagern, die mit ihrer Aufgabe überfordert sind, und bei sowas dann aber extrem hartnäckig sein können. In völliger Missachtung jeder Kosten-Nutzen-Rechnung.
Man sollte sich von solchen Leuten nicht provozieren lassen und oft kann man sie in ruhiger Form überzeugen.
Gruß Axel
-
Übrigens: Letzte Woche erst erlebt:
Einer Usergruppe neue Notes-DB gezeigt und die Leute darin geschult.
User gibt im 1. Feld was ein und will ins nächste wechseln. Er betätigt intuitiv ENTER.
(jo mei).
Die User sind das auch von Excel gewohnt. Enter = neue Zeile bzw. "springe in die Zelle unter der jetzigen".
Viele User kennen die Tab-Taste leider gar nicht. Das ist leider Realität >:(
-
@Matthias: wir haben parallel gepostet.
Ich kenne solche Anforderungen. Lohnen tut sich der Aufwand nicht.
@Axel: Mein letzter Post war wieder parallel ;)
Anyway:
Du hast natürlich Recht. In irgend einem Domino-Blog war letztens eine 10Punkte-Liste was ein Developer/Projektmanager beachten soll. War gar nicht schlecht die Liste (wenn auch schon alles/vieles bekannt). Wenn ich sie noch finde poste ich diese...
Ein Punkt war: Keine zusätzlichen Features einbauen - wenn nicht explizit gefordert. Hier würde ich das auch noch erweitern um "Nicht von Notes-Standards abweichen". Bringt sonst imho nur Ärger mit sich.
Typisches Beispiel: User will mit F5 (also Win-Standard) refreshen statt mit F9.
Hier muss - denke ich - ein Projektleiter einschreiten und höflich klarstellen, dass wir uns hier in einer Non-MS-Umgebung befinden. F9 wird wohl auch in R9 der Refresh-Button sein.
Und aktuell ist eben ENTER keine definierte Taste für das "ins nächste Feld springen" sondern eben TAB. Auch wenn ich mir das für Apps wünschen würde um Verwirrungen und De-Intuition zu vermeiden....
-
Matthias,
als externer kann das ein Zeit- und allgemeine-zielorientiertheit-Haltung-des-Projektteams-Problem werden. Auch wenn ich für Zeit billable bin, wird letztlich danach beurteilt, wieviel Leistung ich im avisierten Zeitrahmen abliefere. Solche Haltungen wie haha-der-dumme-Kunde-will-das-also-mach-ich-den-Quatsch sind nämlich oft auch nicht so gut für den entscheidenden Gesamteindruck.
In einer besseren Welt, würde die Diskussion so ablaufen:
PM Kunde: Aber die Leute sind das so gewohnt.
Ich: In Notes gibt es null/nada/zilch eventhandler, den ich da einklinken könnte.
PM Kunde: Aber in dem Programm geht das.
Ich: Das ist C++. Da gibt es einen Eventhandler für.
PM Kunde: Geht es wirklich nicht. Es ist glaub ich für die Anwender wichtig.
Ich: Ich kann theoretisch ein Applet erzeugen, dass über LiveScript (oder eine andere Technik, weiss wo ich nachschlagen muss) mit Feldern in der Maske kommuniziert. In Java gibts TastaturListener.
PM Kunde: Das hört sich aber kompliziert an und dürfte wohl die Anwendung unnötig mit crap aufblähen.
Ich: Genau.
PM Kunde: OK. Dann geht das nicht.
In der Realität. Wenn man da nicht höllisch aufpasst, findet man sich wegen sowas dann in einem Meeting mit 8 bis 10 Leuten mit voller Bewirtung wieder. 4 kommen zu spät. Inkompetente Leute produzieren sich. Der ganze Wahnsinn eben. Das Projekt mache ich dann zwischen 18:00 - 22:00 Uhr, wenn die ganze Bande weg ist. >:( ;D
Gruß Axel
-
ENTER geht in Notes einfach nicht, da es für zu viele andere Zwecke dringend gebraucht wird (Zeilenschaltung in Textfeldern, Trennung von Mehrfachwerten). Es wäre also eher verwirrend, wenn man zum Bleistift einen Schalter hätte in den field properties: "ENTER sets focus to next field". Mal würde dann ENTER das eine, mal das andere bedeuten. Das wäre dann erst die perfekte Verwirrung ;D
Notes ist ja bei weitem auch nicht das einzige Programm, das auf ENTER so reagiert. Andererseits geht TAB (fast) überall, um den Focus auf das nächste Eingabefeld zu setzen. Sogar in Excel ;)
Bernhard
-
Andererseits geht TAB (fast) überall, um den Focus auf das nächste Eingabefeld zu setzen. Sogar in Excel ;)
Jein. In Excel springt der Cursor bei TAB zum Feld rechts daneben. Bei Enter nach unten. In Notes sind oft die Maskenfelder untereinander angeordnet. Somit für den reinen Excel-Anwender nicht 100% intuitiv.
Aber ansonsten gebe ich Dir natürlich Recht. Passt einfach heute nicht ins Notes-Konzept.
Wobei eine Laufzeit-Eingabevalidierung (also vor Exiting-Event) imho ganz praktisch wäre. Z.B. man definiert für ein Feld max. 10 mögliche Zeichen. User gibt den 11. Buchstaben ein: Fehlermeldung.
-
Hier ist vorher der Begriff "Windows-Standard" gefallen. Ich muss mir das mal besorgen. Da gibt es nämlich klare Dokumentation zu. Und nach dem Windowsstandard bewirkt <return> nämlich nicht, dass man in ein neues Feld springt. Das ist der für mich der entscheidende Punkt.
Selbst Sun propagiert inzwischen, dass sich die Entwickler darum kümmern müssen, das eine GUI-Anwendung auf allen Plattformen konform sein soll:
Zumindest hat das Hani Suleiman aus einer Sun Session so geblogt:
Yes, amazingly, you DO need to know the UI guidelines of your target platform. Yes, you DO need to test using multiple platforms. If you don't, you end up with shit like Eclipse, which, through the divine gift of obstinate fuckwittedness, behaves like a Windows application no matter what platform you run it on. If your UI is successful and usable, the best outcome is no feedback from your end users. They'll be suffused with a happyhappy feeling and won't quite know why. They'll eagerly use your application and not cringe when they're asked to do something with it.
On the downside, when you have a bad UI, very very few users will be able to pinpoint what is so bad about it. Instead, they'll hate your application and feel an incoherent rage towards anyone insisting they use it. It's not like web shit where there are a few million html monkeys and two ways of doing everything; with rich clients, there are thousands of ways of doing everything, and about 3 people who know the right way. Finding the sweet spot is a task far more daunting than farting out yet another silly web intranet app.
Conclusion? The user drives the UI and features, NOT the underlying code. It's your responsibility as a developer to ensure that the mapping between your UI and your underlying functionality works well, and to acknowledge that such a mapping is necessary. Also, always always go that extra mile to ensure that your app is well behaved on all platforms, and be prepared to spend a lot of time and effort doing that with no feedback. No feedback that is beyond smiley gleeful users who are more often than not totally unable to attribute that sensual sense of satisfaction with anything you might have done.
Fazit: Die wirklich wichtigen Sachen stehen im Bile Blog. ;D
-
In der Realität. Wenn man da nicht höllisch aufpasst, findet man sich wegen sowas dann in einem Meeting mit 8 bis 10 Leuten mit voller Bewirtung wieder. 4 kommen zu spät. Inkompetente Leute produzieren sich. Der ganze Wahnsinn eben.
Und beschlossen wird dann, dass man das ganze in den Steuerkreis zur Entscheidung kippt :P (in dem natürlich nur die Bosse sitzen die am wenigsten Plan haben). Beschlossen wird dann je nach Lust und Laune.
(habs zumindest so ähnlich schon öfter erlebt). Widerspruch dann zwecklos, wenn es mal soweit ist.
-
Zumindest hat das Hani Suleiman aus einer Sun Session so geblogt:
Und das ganze klingt sehr vernünftig (egal jetzt erstmal welche Plattform) :D
-
Jein. In Excel springt der Cursor bei TAB zum Feld rechts daneben. Bei Enter nach unten. In Notes sind oft die Maskenfelder untereinander angeordnet. Somit für den reinen Excel-Anwender nicht 100% intuitiv.
Das ist jetzt aber kein Argument, welches sticht ;D Der "reine Excel-Anwender" soll dann auch kein Notes benutzen, sonst ist er ja nicht mehr "rein" ...
Aber ansonsten gebe ich Dir natürlich Recht. Passt einfach heute nicht ins Notes-Konzept.
Wobei eine Laufzeit-Eingabevalidierung (also vor Exiting-Event) imho ganz praktisch wäre. Z.B. man definiert für ein Feld max. 10 mögliche Zeichen. User gibt den 11. Buchstaben ein: Fehlermeldung.
Das passt auch später nicht mehr ins Notes-Konzept: Notes ist keine Tabellenkalkulation, Notes ist kein RDMS usw. usf.
Aber mit einem Event "OnKeyStroke" könnten die Jungs und Mädels von Iris wirklich mal 'rausrücken. ENTER umbiegen wäre zwar Mist (Axel hat da die besten Argumente geliefert), aber zum Bleistift korrekte Eingaben von Datums- oder Zeitangaben überwachen, Passworteingaben zu registrieren, aber nicht auf dem Bildschirm darzustellen etc. - das ist wirklich ein absolut fehlendes Feature !!
Bernhard
-
Jein. In Excel springt der Cursor bei TAB zum Feld rechts daneben. Bei Enter nach unten. In Notes sind oft die Maskenfelder untereinander angeordnet. Somit für den reinen Excel-Anwender nicht 100% intuitiv.
Das ist jetzt aber kein Argument, welches sticht ;D Der "reine Excel-Anwender" soll dann auch kein Notes benutzen, sonst ist er ja nicht mehr "rein" ...
Na ja, Bernhard, Du hast ja das "Excel-Argument" gebracht ;D
Und Tab führt da eben nach Rechts und nicht nach Unten. Somit nicht 100% intuitiv.
Ansonsten wären wirklich ein paar mehr Hilfsmittel recht zur Eingabevalidierung. Würde vieles vereinfachen.....
-
Ich befürchte, wir sind in einem recht müssigen Diskurs ;D
TAB setzt Fokus auf Zelle unter der aktuellen. Okay, that's Excel. Aber was hat das mit Notes zu tun ? Wieviele Masken gibt es, die Felder nur untereinander gruppieren ? Excel-Liebhaber scheitern da dann ja sowieso.
Wenn so ein Excelzist mit der Enter-Taste und "das geht ja immer so ..:" kommt, sollte man den Schnelldenker auch gleich fragen, ob er denn auch Word benutzt ;D
Bernhard
-
Excel ist genau das richtige Beispiel: Microsoft durchbricht die eigenen Regeln/Standards (zum Bleistift die völlig eigene Art, mit dem Kopieren und Einfügen umzugeehen). Vermutlich würde Excel nicht einmal den Microsoft-Test "Runs with Windows" bestehen ... go figure ... :P
-
Gut gebrüllt, Semeaphoros !
Die Anwender sollten sich da auch mal an der eigenen Nase kratzen. Eine Argumentation "Aber in Programm XYZ geht das doch auch so ..." ist oft (aber nicht immer - da müssen wir auch immer aufpassen !) totaler Schwachsinn. Über die unterschiedliche Procedere, wie zum Bleistift bei Hersteller A im Gegensatz zu Hersteller B den Rückwärtsgang des Autos schalten lässt, moniert sich auch keine Sau - obwohl man da was tun könnte (wie bei der Blinkerschaltung oder der Scheinwerferauswahl, die ja auch de jure standardisiert ist).
Bernhard
-
Jo, genau das was ich meine, wenn immer möglich sich an das halten, was üblich ist, aber das nicht unbedingt mit dem Kopf durch die Wand durchsetzen wollen. Kompromisse muss man ja eh irgendwie schliessen. Ich versuche immer, mir selbst die Frage zu stellen, was erwartet der User an dieser Stelle oder wo könnte er die Funktionalität suchen, und da muss man schon fast mit anderen Produkten vergleichen und beobachten, wie es andere machen. Aber konsequent irgendwas durchzuziehen ist unmöglich. Wozu ein "Datei"-"Speichern" implementieren, wenn das Programm nur anhzeigt und nichts verändern .... nur weils im CUA-Standard so defniert ist ???
-
Wozu ein "Datei"-"Speichern" implementieren, wenn das Programm nur anhzeigt und nichts verändern .... nur weils im CUA-Standard so defniert ist ???
Datei/Speichern-Menüdialog können wir in Notes-Apps ja eh nicht bieten.
Meine Meinung: Bitte keine API-Konstrukte um das "Enter-> nächstes Feld" umsetzen. Sonst heißt es irgendwann noch "Hey, ich hab das in Notes schon gesehen dass das geht".
In der Input Translation die Zeilenumbrüche rauswerfen sollte reichen.
Den sog. "Windows-Standard" bricht MS leider oft genug selber. Ist also wohl nicht wirklich ein Standard.