Hello, Guest the thread was viewed2k times and contains 40 replies

last post from goloMAK at the

Verständnisfrage bei GET/INPUT Abfrage.

  • Ich finde, man sollte das durch eine Subroutine in Assembler lösen, das ist eh schneller (anfach!) :saint:.

  • INPUT sollte man nie nicht verwenden.


    Und mit GETX$/VAL combo statt GETX erspart man sich auch den Fall des Syntax Errors

    Dem pflichte ich voll uns ganz bei (also so ungefähr, wenn man "nie nicht" verstärkend und nicht doppeltverneinend auffasst ;) ).
    INPUT ist wegen Verlust der Kontrolle über die Cursorposition und das Bildschirmlayout ziemlich unpraktisch - einige würden sicherlich unbrauchbar sagen. Selbst wenn man eine Variable vom Typ String einliest, so hat man noch mit etwaigen Kommas zu kämpfen (?EXTRA IGNORED Meldung) oder Hochkommas die eine Quotierung vornehmen ...

  • Wir sollten jetzt so ziemlich alle Varianten eines durchnumerierten Menüs durch haben. :whistling:


    Hier zur Abwechslung ein Auswahlmenü, in dem einfach mal keine Fehleingaben möglich sind. Es gibt meines Erachtens nämlich kaum eine nervigere Rückmeldung als etwas in der Art von "Nur die Tasten 1 bis 6 drücken!" ...

    In Zeile 21 ist ein Leerzeichen zwischen den Anführungszeichen.


    Mit ON M GOTO/GOSUB ... kann man dann den gewünschten Programmteil ausführen.

  • 11 PRINT"{HOME,DOWN,RIGHT}"MID$("{RVS ON}MENUEPUNKT 1",2+(M=1))

    Interessante Variante. Das gefällt mir.

  • Hier zur Abwechslung ein Auswahlmenü, in dem einfach mal keine Fehleingaben möglich sind. Es gibt meines Erachtens nämlich kaum eine nervigere Rückmeldung als etwas in der Art von "Nur die Tasten 1 bis 6 drücken!" ...

    Gefällt mir gut. Ich möchte die Idee nicht wirklich schmälern, aber ich bin letztlich bei meinen Projekten davon abgekommen, die Menüführung ausschließlich cursorbasiert zu machen. Wenn das das einzige Menü in einem Programm ist, dann ist es ja gut. Wenn man mehrere Ebenen hat, dann kann es nach einer Zeit ein bisserl lästig bzw. mühseelig werden. Das merkt man umso schneller, wenn man Tests macht, beispielsweise immer in gewisse Menüpunkte einer 2. Ebene möchte und sich dann durch die Menüpunkten "durchbewegen" muss. Da sind Schortcut-Tasten (für die versierte Bedienung eines Programms) schon ein Segen. Üblicherweise ohne nervigen Hinweis (vielleicht sogar noch mit einer Back-off-Time, wo gar nichts geht), was denn nun wirklich zu drücken ist. Einfach unzulässige Eingabe ignorieren (und gleich einen kleinen Hinweis auf die erwarteten Eingaben machen, wie es hier im Beispiel ja auch der Fall ist). ;)

  • Hier zur Abwechslung ein Auswahlmenü, in dem einfach mal keine Fehleingaben möglich sind. Es gibt meines Erachtens nämlich kaum eine nervigere Rückmeldung als etwas in der Art von "Nur die Tasten 1 bis 6 drücken!" ...

    Gefällt mir gut. Ich möchte die Idee nicht wirklich schmälern, aber ich bin letztlich bei meinen Projekten davon abgekommen, die Menüführung ausschließlich cursorbasiert zu machen. Wenn das das einzige Menü in einem Programm ist, dann ist es ja gut. Wenn man mehrere Ebenen hat, dann kann es nach einer Zeit ein bisserl lästig bzw. mühseelig werden.

    Die "hohe Kunst" bei mehrfach geschachtelten Menüs ist die Möglichkeit, mehrere Ebenen gleichzeitig anzugeben. Also ich will auf der ersten Ebene die Nr. 4, auf der zweiten Ebenen die Nr. 1 und auf der 3. Ebene die Nr. 2. Dann gebe ich auf der ersten Ebene "413" an und bin direkt an der richtigen Stelle. Mit einer "0" kommt man wieder ist Hauptmenü. "0413" funktioniert dann immer, egal auf welcher Ebene man gerade ist. Geübte Benutzer sind so dankbar für solche Vereinfachungen.


    Auf dem 64er habe ich sowas noch nicht realisiert, aber unter DOS.

  • Fehleingaben sollte in meinem Vorschlag auch unmöglich sein. Bei Wert VAL(X$)<1 oder >6 wird schlicht kein Sprung ausgelöst.

    Nichts für ungut, aber das grundsätzliche Problem war bereits mit Beitrag #2 gelöst. Das ein Programm damit zurechtkommen muß, wenn ein Scherzkeks trotz offenkundiger Angaben auf dem Bildschirm was anderes als die Tasten 1 bis 6 drückt, sollte klar sein. Wie der Fall dann gehandhabt wird, ist Geschmackssache.


    Das ändert aber auch nichts daran, das so ein Auswahlmenü über verschiedene Tasten einigermaßen altbacken ist und mit wenig mehr Aufwand das Menü so gestaltet werden kann, wie ich im Beitrag #27 geschrieben habe. Da braucht nichts durchnumeriert werden, anstelle der generischen Bezeichnungen können die Menüpunkte so drinstehen, wie sie heißen sollen. Was anderes als die genannten Menüpunkte kann der User nicht auswählen. Natürlich kann der User andere Tasten als f1, f7 oder Leertaste drücken und natürlich kommt das Menü in Beitrag #27 damit zurecht.


    Wenn schnell zwischen Betriebsarten umgeschaltet werden soll, macht eine direkte Eingabe per Tastaturbefehl durchaus Sinn (auch JeeK), aber dann gehört die Liste der Befehle in eine Hilfsseite. Steht die gesamte Befehlsliste ständig auf dem Bildschirm, dann nimmt sie permanent Platz weg, den man besser für was anderes gebrauchen kann. Es reicht völlig aus, irgendwo im Eck ein "? für Hilfe" anzuzeigen, das hab' ich z.B. in MINIPAINT für den VC-20 auch so gemacht:



    Die Statusanzeige rechts unten enthält den Hinweis auf die Hilfeseiten und sonst die Cursor-Koordinaten, die Palette (im Hires-Modus sind nur die Farben 1 und 2 verfügbar, im Multicolour-Modus kommen noch 3 und 4 dazu), den Hinweis, daß man mit Ctrl + Nummerntaste die Farben wechseln kann und auch den Hinweis, daß man mit H und M den Hires- bzw. Multicolour-Modus auswählt. "?" zeigt die Hilfeseiten:



    Die von mir anderweitig vorgeschlagene Menütechnik habe ich z.B. in einer Spielesammlung im Einsatz. Hier wird der Menüpunkt nicht invertiert, sondern andersfarbig dargestellt:



    Da steht jetzt zwar nicht die Bedienung bei, aber Cursor Up/Down gehen, f1/f7 für hoch/runter auch und sowohl Return als auch die Leertaste machen die Auswahl.

  • Nichts für ungut, aber das grundsätzliche Problem war bereits mit Beitrag #2 gelöst.

    Das war hier noch nie ein Grund, deswegen nicht trotzdem noch 40 Seiten weiterzudiskutieren. :D

    Eben. Der Thread hat sich längst von der ursprünglichen Frage emanzipiert. :D


    Und wir sind erst bei Seite 2. Da geht noch was.

  • Mag sein, dass die eigentliche Frage das TS in #2 beantwortet wurde.

    Ändert aber nichts daran, dass der vom TS gepostete Code redundant ist und Optimierungsbedarf hatte.


    Überlesen hatte ich allerdings, dass Egon Olsen bis auf das überflüssige

    Code
    1. 230 GET A$:IF A$="" THEN 230

    eigentlich schon den gleichen Vorschlag hatte.


    Mike: Einerseits offtopic anmahnen und dann vom Titel "GET/INPUT" bzw. von der Aufgabe "Per Tastendruck [1]-[6] Sprungziele ansteuern" hinführen zu einer per F-Tasten oder Joystick gesteuerten Menuführung (bebildert)... nix für ungut, aber das unterschreitet ein bisschen meinen Datentransfer

  • Mike: Einerseits offtopic anmahnen [...]

    Du hast die Diskussion hier nicht sorgfältig genug gelesen. Nachdem bereits in Beitrag #2 die Ausgangsfrage prinzipiell geklärt war, ergingen sich die Diskussionsteilnehmer zunächst mal in eine Sammlung von möglichen Lösungen und mein erster Beitrag war auch nicht ganz ernst gemeint (richtig erkannt von #11 und #21). Wenn das jemand nicht erkennt und mich anpflaumt, ist die Meta-Diskussion nicht weit.

    [...] und dann vom Titel "GET/INPUT" bzw. von der Aufgabe "Per Tastendruck [1]-[6] Sprungziele ansteuern" hinführen zu einer per F-Tasten oder Joystick gesteuerten Menuführung (bebildert) [...]

    Aus meiner Sicht ist das eine völlig legitime Diskussionsdrift, im Hinblick darauf, daß das Originalthema beantwortet ist und für den Themenstarter auch eine Weiterentwicklung des Menüs herauskommt.

    [...] ... nix für ungut, aber das unterschreitet ein bisschen meinen Datentransfer[.]

    Den Spruch lasse ich mit Absicht mal unkommentiert.

  • Sich in einem Thread, der offensichtlich vom TE bereits verlassen wurde und nur noch zur Expertendiskussion missbraucht wird gegenseitig Offtopic vorzuwerfen ist albern. Ich würde sagen, Feuer frei für weitere Alternativen und Verbesserungsvorschläge, tut ja keinem weh :bia.

  • Sich in einem Thread, der offensichtlich vom TE bereits verlassen wurde und nur noch zur Expertendiskussion missbraucht wird gegenseitig Offtopic vorzuwerfen ist albern. Ich würde sagen, Feuer frei für weitere Alternativen und Verbesserungsvorschläge, tut ja keinem weh :bia.

    Ich hab den Thread nicht verlassen, bin aber weiterhin für Vorschläge offen, was ich beim nächsten Mal beachten kann/sollte. Außerdem ist es doch sehr amüsant, wie das immer so blüht bei Verständnisfragen :D :popcorn: