Tastendruck Code-Kollision

[Don P]

Hallo,

Ein Input-Feld soll nur numerische Eingaben erlauben. Statt den Benutzer alles eingeben zu lassen und nachher auf nicht-numerische Zeichen zu prüfen, würde ich gerne alle Tasten bereits bei der Eingabe abfangen, die nicht die Ziffern 1-9 sind oder die Navigationstasten Pfeil, PgUp, PgDn, Home, End.

Das ist mit onkepress schon machbar, aber: Die Codes für die Navigationstasten 35-40 kollidieren ja mit den ASCII-Zeichen 35-40, als da sind: #$%&'(

Diese Zeichen will ich natürlich nicht zulassen, wohl aber die Navigationstasten mit denselben Codes. Es ist auch keine Lösung, zusätzlich auf die Shift-Taste zu prüfen (die meisten dieser ASCCI Zeichen müssten ja mit Shift eingegeben werden), denn die Shift-Taste dient ja in Verbindung mit den Navigationstasten zum Markieren, was ich natürlich auch zulassen will.

Weiß jemand Rat?
Es muss doch irgendwie möglich sein, genauere Codes zu bekommen...

Gruß, Don P

[Beat]

Ein Input-Feld soll nur numerische Eingaben erlauben. Statt den Benutzer alles eingeben zu lassen und nachher auf nicht-numerische Zeichen zu prüfen, würde ich gerne alle Tasten bereits bei der Eingabe abfangen, die nicht die Ziffern 1-9 sind oder die Navigationstasten Pfeil, PgUp, PgDn, Home, End.

Ohne dass du den obligaten Hupton mitlieferst, der den User auf eine deaktivierte Taste aufmerksam macht, ist dein Vorhaben verwerflich.

Begnüge dich mit Stringprüfung onblur, denn da hat der User seine Augen oder was auch immer wieder auf das Formular gerichtet.

mfg Beat

[ChrisB]

Hi,

Ein Input-Feld soll nur numerische Eingaben erlauben. Statt den Benutzer alles eingeben zu lassen und nachher auf nicht-numerische Zeichen zu prüfen, würde ich gerne alle Tasten bereits bei der Eingabe abfangen, die nicht die Ziffern 1-9 sind oder die Navigationstasten Pfeil, PgUp, PgDn, Home, End.

Halte ich für eher unsinnig.

Das ist mit onkepress schon machbar, aber: Die Codes für die Navigationstasten 35-40 kollidieren ja mit den ASCII-Zeichen 35-40, als da sind: #$%&'(

Was kollidiert da bitte?
Um # einzugeben, muss ich (auf meinem Rechner) die 3 drücken, da ergibt Tastencode 51 (unabhängig davon, dass auch noch Shift gedrückt ist).
Für $ drücke ich 4, Code 52;
für % 5, 53;
etc.

Was kollidiert da bitte?

MfG ChrisB

[Don P]

Hallo,

Halte ich für eher unsinnig.

Ich für genial.

Was kollidiert da bitte?
Um # einzugeben, muss ich (auf meinem Rechner) die 3 drücken, da ergibt Tastencode 51 (unabhängig davon, dass auch noch Shift gedrückt ist).

Was hast du denn für eine seltsame Tastatur? Die #-Taste ist bei mir links von der rechten Enter-Taste und ohne Shift einzugeben. Das ergibt im FF mit which den Code 35, genau wie die Home-Taste, mit den anderen ist es analog.

Für $ drücke ich 4, Code 52;

Na also, das ist doch gerade die Kollision: ode 52 sowohl für die 4 als auch für $, usw.

Gruß, Don P

[ChrisB]

Hi,

Halte ich für eher unsinnig.

Ich für genial.

Um # einzugeben, muss ich (auf meinem Rechner) die 3 drücken, da ergibt Tastencode 51 (unabhängig davon, dass auch noch Shift gedrückt ist).

Was hast du denn für eine seltsame Tastatur?

Eine andere, als du offenbar.

Die #-Taste ist bei mir links von der rechten Enter-Taste und ohne Shift einzugeben. Das ergibt im FF mit which den Code 35, genau wie die Home-Taste, mit den anderen ist es analog.

Reicht dir das als argumentativer Beleg dafür, dass du den Sinngehalt deines Vorhabens noch mal überdenken solltest, und mit der Einschätzung der Genialität daneben liegst?

Für $ drücke ich 4, Code 52;
Na also, das ist doch gerade die Kollision: ode 52 sowohl für die 4 als auch für $, usw.

Da kolldiert nichts.
Ich drücke die Taste 4, der Tastencode ist 52.
Ich drücke noch mal die Taste 4, der Tastencode ist immer noch 52.
Keinerlei Kollision erkennbar.

Dass ich beim zweiten Mal auch noch die Shift-Taste gedrückt habe, hat weder Bedeutung noch Einfluss - wieso sollte es auch? Es ist eine andere Taste.

Was hier vielleicht kollidiert, ist dein Verständnis von Tastendrücken, die du abfragst, einerseits, und den Zeichen, die sich daraus letztendlich ergeben, andererseits.

MfG ChrisB

[Don P]

Hallo,

Reicht dir das als argumentativer Beleg dafür, dass du den Sinngehalt deines Vorhabens noch mal überdenken solltest, und mit der Einschätzung der Genialität daneben liegst?

Keineswegs. Es reicht allenfalls als Beweis, dass die Tastaturcodes in JS unbrauchbar sind.

Da kolldiert nichts.
Ich drücke die Taste 4, der Tastencode ist 52.
Ich drücke noch mal die Taste 4, der Tastencode ist immer noch 52.
Keinerlei Kollision erkennbar.

Es geht doch nicht um die Ziffern, die sind schon ok. Ich schrub doch, dass es um die Navigationstasten geht mit den Codes 35-40.
Es geht z.B. um das Dollarzeichen $ und die Home-Taste (bzw. Pos1 oder wie die auch immer beschriftet sein mag):

Ich gebe $ ein, der Tastencode ist 36.
Ich drücke die Taste Home, der Tastencode ist ebenfalls 36!

Die Home-Taste will ich erlauben, das Dollarteichen aber nicht.
Wenn *das keine Kollision ist, dann weiß ich auch nicht...

Gruß, Don P

[ChrisB]

Hi,

Reicht dir das als argumentativer Beleg dafür, dass du den Sinngehalt deines Vorhabens noch mal überdenken solltest, und mit der Einschätzung der Genialität daneben liegst?

Keineswegs. Es reicht allenfalls als Beweis, dass die Tastaturcodes in JS unbrauchbar sind.

Wenn du dir noch ein bisschen mehr Mühe gibst, dann reicht es vielleicht auch dafür, dass für dein Vorhaben die Abfrage von Tastendrücken unbrauchbar ist.

Es geht doch nicht um die Ziffern, die sind schon ok.

Du selber schriebst vom $-Zeichen.
Die Taste, die ich für dieses und die 4 drücke, sind bei meiner Tastatur identisch.

Also ist dein Vorgehen auch diesbezüglich *nicht* "ok", wenn du mich zwar die Ziffer 4 eingeben lassen willst, das Zeichen $ aber nicht.
Ich drücke für beides die selbe Taste - du willst mich aber nur eins von beidem eingeben lassen; und Prüfung der Shift-Taste - die hierbei den Unterschied macht, welches Zeichen dabei letztendlich herauskommt - hast du schon als unpraktikabel ausgeschlossen.

Ich gebe $ ein, der Tastencode ist 36.
Ich drücke die Taste Home, der Tastencode ist ebenfalls 36!

Bei meiner Tastatur/meinem System aber nicht.

Die Home-Taste will ich erlauben, das Dollarteichen aber nicht.
Wenn *das keine Kollision ist, dann weiß ich auch nicht...

Das ist vielleicht auf deinem System eine.

Auf Grund dieser Unterschiede finde ich wie gesagt dein Vorhaben nicht genial, sondern unsinnig.

Genial wäre, wenn du jetzt langsam mal erkennen würdest, dass du an *Zeichen* interessiert bist, und nicht daran, welche Tasten gedrückt wurden, um sie zu erzeugen.

MfG ChrisB

[Don P]

Hallo,

Du selber schriebst vom $-Zeichen.
Die Taste, die ich für dieses und die 4 drücke, sind bei meiner Tastatur identisch.

Das stimmt allerdings.

Also ist dein Vorgehen auch diesbezüglich *nicht* "ok", wenn du mich zwar die Ziffer 4 eingeben lassen willst, das Zeichen $ aber nicht.
Ich drücke für beides die selbe Taste - du willst mich aber nur eins von beidem eingeben lassen; und Prüfung der Shift-Taste - die hierbei den Unterschied macht, welches Zeichen dabei letztendlich herauskommt - hast du schon als unpraktikabel ausgeschlossen.

Ist sie vielleicht doch praktikabel? Anscheinend stehe ich gerade auf dem Schlauch... aber klar: Die Shift-Taste muss eben doch abgefragt werden *kopfpatsch*

Auf Grund dieser Unterschiede finde ich wie gesagt dein Vorhaben nicht genial, sondern unsinnig.

Naja, die Idee finde ich nach wie vor genial. Wenn man nicht will, dass unsinniges Zeug eingegeben wird, warum dann nicht einfach dafür sorgen, dass das gar nicht möglich ist, anstatt später den Mist jeweils aufzuräumen?

Der Benutzer wird deutlich darauf hingewiesen, dass nur Ziffern erlaubt sind, und wenn er etwas anderes eingibt, ist das ganz sicher ein Versehen (oder ein Betrugsversuch), für dessen Verhinderung im Vorfeld er mir dankbar sein sollte. Das erspart ihm nämlich eine lästige Meldung wie "Falsche Eingabe, Sie Dösbaddel!"

Genial wäre, wenn du jetzt langsam mal erkennen würdest, dass du an *Zeichen* interessiert bist, und nicht daran, welche Tasten gedrückt wurden, um sie zu erzeugen.

Hmmm, ja doch...

Gruß, Don P

[ChrisB]

Hi,

Naja, die Idee finde ich nach wie vor genial.

Ich die gewählte *Umsetzung* nach wie vor und immer noch nicht.

Der Benutzer wird deutlich darauf hingewiesen, dass nur Ziffern erlaubt sind, und wenn er etwas anderes eingibt, ist das ganz sicher ein Versehen (oder ein Betrugsversuch), für dessen Verhinderung im Vorfeld er mir dankbar sein sollte. Das erspart ihm nämlich eine lästige Meldung wie "Falsche Eingabe, Sie Dösbaddel!"

Meine Dankbarkeit hält sich in Grenzen, wenn ich "123abc" aus meiner Zwischenablage einfach in das Feld einfüge (und das möglicherweise, ohne auch nur eine einzige Taste auf meiner Tastatur zu drücken), und von dir dann anschliessend, vermutlich(?) bei der serverseitigen Validierung, mit "Falsche Eingabe, Sie Dösbaddel!" angeschnauzt werde.

MfG ChrisB

[Don P]

Hallo,

Meine Dankbarkeit hält sich in Grenzen, wenn ich "123abc" aus meiner Zwischenablage einfach in das Feld einfüge

Auch das wird verhindert bzw. onchange nochmal geprüft

und von dir dann anschliessend, vermutlich(?) bei der serverseitigen Validierung, mit "Falsche Eingabe, Sie Dösbaddel!" angeschnauzt werde.

Natürlich würde ich mich höflicher ausdrücken (war hier nur zur Verdeulichung so krass formuliert), und eine serverseitige Validierung gibt's in dem Fall nicht. Der Client hat alle nötigen Informationen, um das selbständig zu erledigen.

Gewisse Leute hier im Forum sollten sich besser abgewöhnen, immer stille Annahmen über das Einsatzgebiet und das Umfeld von Programmen zu machen, von denen sie nicht die geringsten Informationen haben. Es gibt noch mehr da draußen als nur www und Suchmaschinen und blinde Benutzer, denen man unbedingt alles vorlesen können muss...

Gruß, Don P

[ChrisB]

Hi,

Natürlich würde ich mich höflicher ausdrücken (war hier nur zur Verdeulichung so krass formuliert), und eine serverseitige Validierung gibt's in dem Fall nicht. Der Client hat alle nötigen Informationen, um das selbständig zu erledigen.

Und der Server (oder wer sonst die Daten weiter verarbeitet) verlässt sich darauf, dass er es auch *tut*?

Gewisse Leute hier im Forum sollten sich besser abgewöhnen, immer stille Annahmen über das Einsatzgebiet und das Umfeld von Programmen zu machen, von denen sie nicht die geringsten Informationen haben.

Dass das weniger wahrscheinlich passiert, wenn du spezielle Umgebungbedingungen gleich nennst, steht in den Tipps für Fragende übrigens auch drin.

MfG ChrisB

[Don P]

Hallo,

Der Client hat alle nötigen Informationen, um das selbständig zu erledigen.

Und der Server (oder wer sonst die Daten weiter verarbeitet) verlässt sich darauf, dass er es auch *tut*?

Die Daten werden nicht weiterverarbeitet. Sie sind sehr kurzlebig. Wenn der Benutzer mit dem Programm fertig ist, sind sie weg, es sei denn er möchte das *Endrgebnis* irgendwie speichern, dann kann er es rauskopieren oder so. Auch alle seine Eingaben kann er bei Bedarf rauskopieren und abspeichern, seine Sache. Kein Server interessiert sich jemals dafür.

Gewisse Leute hier im Forum sollten sich besser abgewöhnen, immer stille Annahmen über das Einsatzgebiet und das Umfeld von Programmen zu machen, von denen sie nicht die geringsten Informationen haben.

Ich schreibe ja so schon halbe Romane. Man muss doch nicht unbedingt für jedes Detailproblem(chen) die ganze dahinter stehende Anwendung und Philosophie zum Besten geben.

Nochmal zum eigentlichen Problem, damit du auch was davon hast: Auf der genannten Seite machen sie es mit String.fromCharCode(keyCode). Ich wollte halt einfach in einem Array mit erlaubten keyCodes nachschauen. So einfach ist es anscheinend doch nicht. Aber das hast du wahrscheinlich gewusst, und wolltest es mir nur nicht sagen, gelle?

Werde schon selber dahinter kommen, wie das für meine Zwecke am besten geht. Ist ja alles SELF hier.

Gruß, Don P

[Don P]

Hallo,

Werde schon selber dahinter kommen, wie das für meine Zwecke am besten geht. Ist ja alles SELF hier.

Wenn man nicht alles selber macht...

Die Lösung ist onkeydown, nicht onkeypress, was ich zuerst versuchte.
onkeydown reagiert nämlich auf jede Taste einzeln, d.h. Tastenkombinationen wie Shift-4 kann es da gar nicht geben, weil die 4 dann wieder einen neuen onkeypress-Event auslöst. Bei onkeydown ist das anscheinend nicht der Fall. Da liefert Shift-4 unsinnigerweise denselben Code wie die Home-Taste :(

Gruß, Don P

[Struppi]

Da liefert Shift-4 unsinnigerweise denselben Code wie die Home-Taste :(

Zeig doch mal, wie du das ermittelst. Bei mir ist dies nicht so.

Struppi.

[Don P]

Hallo Struppi,

Da liefert Shift-4 unsinnigerweise denselben Code wie die Home-Taste :(

Zeig doch mal, wie du das ermittelst. Bei mir ist dies nicht so.

In FF 3.5.3 z.B. so:

document.getElementByID("numInput").onkeypress = function(e) {  
  
    e = e||event;  
    var key = e.which||e.keyCode;  
  
    alert([key, String.fromCharCode(key)]);  
};  

Für # ergibt das: 35,#.
Für End ergibt das: 35,#.

Bei Shift-4 (=$) ergibt das: 36,$.
Bei Home (Pos1) ergibt das: 36,$.

usw.;
Code 37 = % und Code 37 = Pfeiltaste links
Code 38 = & und Code 38 = Pfeiltaste hoch
Code 39 = ' und Code 39 = Pfeiltaste rechts
Code 40 = ) und Code 40 = Pfeiltaste runter

Mit onkeypress kann man die also nicht unterscheiden.
Aber es klappt mit onkeydown!

Gruß, Don P

[MudGuard]

Hi,

var key = e.which||e.keyCode;
    alert([key, String.fromCharCode(key)]);

Überleg doch mal, warum die von Dir benutzte Methode fromCharCode und nicht fromKeyCode heißt.

Eine übliche Tastatur hat zwischen 100 und 200 Tasten, es gibt wesentlich mehr Zeichen.

Du schmeißt key codes und character codes in einen Topf, und wunderst Dich dann über das Ergebnis ...

cu,
Andreas

[Don P]

Hallo,

Überleg doch mal, warum die von Dir benutzte Methode fromCharCode und nicht fromKeyCode heißt.

Du schmeißt key codes und character codes in einen Topf, und wunderst Dich dann über das Ergebnis ...

Nicht wirklich, die Alert-Ausgabe fromCharCode hätte ich ja auch weglassen können.
Trotzdem bleibt der Code, den mir e.which liefert, bei verschidenen Eingaben gleich, und ich meine, dass z.B. Shift-4 vom Code her nichts der Home-Taste zu tun haben sollte.

Kannst du mir erklären, was der Sinn dahinter sein könnte?
Mir erschließt sich der ganz und gar nicht.

Gruß, Don P

[Struppi]

Trotzdem bleibt der Code, den mir e.which liefert, bei verschidenen Eingaben gleich, und ich meine, dass z.B. Shift-4 vom Code her nichts der Home-Taste zu tun haben sollte.

Nein, wich ist unterschiedlich. Guck dir das mal an:

<form action="" name="form1">  
<p><textarea rows=40 name="area"></textarea>  
<input type="text" name="text" value="" onkeypress="key(event)" onkeydown="key(event)">  
<script type="text/javascript">  
function key(e) {  
	document.form1.area.value +=  
	e.type +':' + e.which + '/' + e.keyCode + '\n'  
}  
</script>  
</p>  
</form>

Struppi.

[Don P]

Hallo,

Trotzdem bleibt der Code, den mir e.which liefert, bei verschidenen Eingaben gleich, und ich meine, dass z.B. Shift-4 vom Code her nichts der Home-Taste zu tun haben sollte.

Nein, which ist unterschiedlich. Guck dir das mal an: [...]

Oha, das ist ja ganz neu. Und plötzlich ist es mir klar.
Die Unterscheidung key=e.which||e.keyCode habe ich immer nur als Browserweiche verstanden. Wusste nicht, dass FF beides kennt. Tatsächlich ergibt which manchmal 0, und dann greift keyCode, was die vermeintliche Kollision verursacht.

Gute Idde von dir, mal nach dem konkreten Code zu fragen.
Vielen Dank! Man lernt ja nie aus.

Gruß, Don P

[MudGuard]

Hi,

Gute Idde von dir, mal nach dem konkreten Code zu fragen.

Eine noch bessere wäre es gewesen, wenn Du diesen bereits im ersten Posting dieses Threads geliefert hättest.

cu,
Andreas

[Don P]

Hallo,

Gute Idde von dir, mal nach dem konkreten Code zu fragen.

Eine noch bessere wäre es gewesen, wenn Du diesen bereits im ersten Posting dieses Threads geliefert hättest.

Das ist mir inzwischen auch klar. War aber anfangs unnötig, da ich mir ja sooo sicher war, dass es nicht an dem bisschen Code liegen kann ;-)

Gruß, Don P

[Gunnar Bittersmann]

@@Don P:

nuqneH

Gute Idde von dir, mal nach dem konkreten Code zu fragen.

Ja, wirklich sehr originell. ;-)

Weniger gut ist die Idee, Tastencodes abzufragen, wenn man Zeichen meint. Bist du sicher, dass auf allen Systemem (PC vs. Mac) die Zuordnung Tasten–Zeichen dieselbe ist?

Schon auf einem System versagt dein Ansatz durch unterschiedliche Tastaurbelegungen.

Schon gestern hatte Beat dich darauf hingewiesen, dass dein Ansatz untauglich ist. Warum hast du noch einen Tag damit verschwendet, ihn weiter zu verfolgen?

Qapla'

[Don P]

Hallo,

Ja, wirklich sehr originell. ;-)

Eben ;-)

Weniger gut ist die Idee, Tastencodes abzufragen, wenn man Zeichen meint. Bist du sicher, dass auf allen Systemem (PC vs. Mac) die Zuordnung Tasten–Zeichen dieselbe ist?

Eher nicht. Inzwischen bin ich auch vom keyCode abgekommen und beim charCode angelangt.

Schon auf einem System versagt dein Ansatz durch unterschiedliche Tastaurbelegungen.

Schon gestern hatte Beat dich darauf hingewiesen, dass dein Ansatz untauglich ist.

Untauglich ist ein hartes Wort. Schau dir z.B. mal den ColorPicker an. Dort gibt es ein Input-Feld mit einer sehr begrenzenten Auswahl zulässiger Eingaben. Das halte ich aber nicht für untauglich, sondern für durchaus angebracht. Wer da z.B. ein Euro-Zeichen eingeben will, der hat sie doch nicht alle, bzw. hat sich höchstwahrscheinlich vertan.

Für einen ganz ähnlichen Fall – wo einfach nur bestimmte Eingaben überhaupt Sinn machen, was der Benutzer natürlich weiß – wollte ich die Funktion haben, und jetzt tut sie auch wie gewünscht. Verstehe gar nicht, warum man mich dafür steinigen will.

Auf den Piepston bei deaktivierten Tasten kann man dabei getrost verzichten. Vielleicht baue ich ich sogar noch ein, aber nicht ohne die Möglichkeit für den User ihn zu deaktivieren, aus Rücksicht auf sein Nervenkostüm.

Warum hast du noch einen Tag damit verschwendet, ihn weiter zu verfolgen?

Das war sicher keine Verschwendung, sondern eine sehr lehrreiche Angelegenheit, wenn auch etwas mühsam.

Gruß, Don P

[Don P]

Hallo,

Verstehe gar nicht, warum man mich dafür steinigen will.

Habe noch ein bisschen darüber meditiert. Vielleicht habt ihr ja Bedenken, dass das Schule macht und jeder Möchtergern-Web-Programmierer Herrscher über die Tastaturen der Benutzer werden will, z.B. böswillig dokumentweit die Tasten abschaltet oder gar umprogrammiert, mit eiem fiesen ROT13 oder so... Das wäre natürlich weniger wünschenswert. Werde das Ding mal nicht weiter an die große Glocke hängen. Aber man kann auch nicht unbedingt pauschal eine Technik für ihren möglichen Missbrauch verantwortlich machen, oder?

Gruß, Don P

[Beat]

Vielleicht habt ihr ja Bedenken, dass das Schule macht und jeder Möchtergern-Web-Programmierer Herrscher über die Tastaturen der Benutzer werden will, z.B. böswillig dokumentweit die Tasten abschaltet oder gar umprogrammiert, mit eiem fiesen ROT13 oder so... Das wäre natürlich weniger wünschenswert. Werde das Ding mal nicht weiter an die große Glocke hängen. Aber man kann auch nicht unbedingt pauschal eine Technik für ihren möglichen Missbrauch verantwortlich machen, oder?

Beim Entwurf einer GUI kommen viele Überraschungen zum Zuge. Programmierst du für dich, dann ist es OK. Sobald du aber für unbekannte Benutzerschaft schreibst, hast du mit allem zu rechnen.
Das sind die bedenken. Wir werfen Sie dir an den Kopf, einfach, damit sie geäussert sind.

Interessant ist auch, was AListApart zum Thema QA sagt.
Keine Firma, niemand als einzelner, ist in der Lage, Probleme zu erfassen.
Man muss sie durch möglichst viele gewonnen Quellen sammeln, so wie sie kommen.
http://www.alistapart.com/articles/the-myth-of-usability-testing/

Nachdem ich diesen Artikel gelesen habe, wurde mir auch klar, dass es keine Rolle spielt, ob meine Bedenken oder Reflexe zu irgend etwas einseitig sind oder nicht. Sie gehören einfach zum Input.

mfg Beat

[Don P]

Hallo,

Bei onkeydown ist das anscheinend nicht der Fall. Da liefert Shift-4 unsinnigerweise denselben Code wie die Home-Taste :(

Hatte mich da anscheinend verschrieben. Richtig muss es heißen:

Bei *onkeypress* ist das anscheinend nicht der Fall.Da liefert Shift-4 unsinnigerweise denselben Code wie die Home-Taste :(

Gruß, Don P

[Beat]

Naja, die Idee finde ich nach wie vor genial. Wenn man nicht will, dass unsinniges Zeug eingegeben wird, warum dann nicht einfach dafür sorgen, dass das gar nicht möglich ist, anstatt später den Mist jeweils aufzuräumen?

Also auch copy/paste unterdrücken?

Ich liebe Leute die vergessen, dass ihr Code zu Gast auf auf einem PC ist.
Deine Homepage beginnt auf deinem Server.

mfg Beat

[Don P]

Hallo,

Also auch copy/paste unterdrücken?

Äh ja, genau. Es ist eine Zahl einzugeben, mehr als 4 Ziffern dürften es selten sein. Jede andere Eingabe ist völlig sinnlos und muss ohnehin korrigiert werden.

Ich liebe Leute die vergessen, dass ihr Code zu Gast auf auf einem PC ist.

Die Gastgeber erwarten ein funktionierendes Programm und keines, dass ihnen Fehlermeldungen um die Ohren haut. Das Programm muss so gut designed sein, dass möglichst keine Fehler entstehen, auch nicht durch Versehen der Benutzer. Das bin ich ihnen schuldig und das erwarten sie auch zu Recht.

Ich sage ja nicht, dass diese Praxis mit dem Eingabefeld immer und überall angewendet werden soll, aber in meinem speziellen Fall macht das sehr viel Sinn. Was würdest du  sagen, wenn z.B. ein Bildschirm-Taschenrechner alle Eingaben zulässt und onblur dann meldet "Was soll das sein? Bitte nochmal eingeben, aber diesmal richtig!"

Deine Homepage beginnt auf deinem Server.

Wie ist das jetzt zu verstehen?

Gruß, Don P

[Don P]

Hallo,

Habe jetzt diese Seite gefunden. Dort ist das Zeichen $ gar nicht aufgeführt, und wenn ich dort Shift-4 für das Dollarzeichen eingebe, meldet das Programm tatsächlich Code 52. Damit könnte ich leben, aber nicht mit Code 36, der für die Home-Taste reserviert sein sollte.

Werde also bei denen mal nachschauen, wie sie das gelöst haben...

Gruß, Don P

[ChrisB]

Hi,

Habe jetzt diese Seite gefunden. Dort ist das Zeichen $ gar nicht aufgeführt, und wenn ich dort Shift-4 für das Dollarzeichen eingebe, meldet das Programm tatsächlich Code 52. Damit könnte ich leben, aber nicht mit Code 36, der für die Home-Taste reserviert sein sollte.

Werde also bei denen mal nachschauen, wie sie das gelöst haben...

Was haben die "gelöst"?

Ich habe neben den Cursortasten noch zwei zusätzlichen Tasten auf meiner Tastatur, über die ich $ und € eingeben kann, ohne bei irgendeiner anderen Taste noch Shift oder sonstwas zusätzlich drücken zu müssen.
Für beiden gibt mir das Script auf der dortigen Seite an, dass ich die [alt]-Taste mit dem Code 18 gedrückt hätte.

MfG ChrisB

[Don P]

Hallo,

Was haben die "gelöst"?

Sie geben nicht den Code 36 für $ aus. Mein e.which in FF aber schon :(

Ich habe neben den Cursortasten noch zwei zusätzlichen Tasten auf meiner Tastatur, über die ich $ und € eingeben kann

Banker oder was ? ;)
Und wenn du draufdrückst, flattern die Scheine aus dem DVD-Laufwerk? Sowas will ich auch...

Für beiden gibt mir das Script auf der dortigen Seite an, dass ich die [alt]-Taste mit dem Code 18 gedrückt hätte.

Waaas? Die Lügen ja wie gedrückt...

Gruß, Don P

[Der Martin]

Hallo,

Ein Input-Feld soll nur numerische Eingaben erlauben. Statt den Benutzer alles eingeben zu lassen und nachher auf nicht-numerische Zeichen zu prüfen, würde ich gerne alle Tasten bereits bei der Eingabe abfangen, die nicht die Ziffern 1-9 sind oder die Navigationstasten Pfeil, PgUp, PgDn, Home, End.

deinem eigentlichen Phänomen bist du ja nun ein entscheidendes Stück näher auf die Schliche gekommen. Mich beschäftigt beim aufmerksamen Lesen aber noch eine Frage:

Was zum Geier soll ich in einem (einzeiligen) Eingabefeld für 4 Ziffern mit den Tasten PgUp und PgDn anstellen? Okay, anscheinend werden sie synonym zu Home und End interpretiert. Aber von der Grundidee her stehen sie für eine vertikale Navigation, was sich ja auch in den Bezeichnungen "Up" und "Down" oder in den Pfeilen auf den Tasten widerspiegelt. Ich käme also nicht auf die Idee, diese Tasten in einem einzeiligen EIngabefeld benutzen zu wollen.

So long,
 Martin

[Don P]

Hallo,

Mich beschäftigt beim aufmerksamen Lesen aber noch eine Frage:
Was zum Geier soll ich in einem (einzeiligen) Eingabefeld für 4 Ziffern mit den Tasten PgUp und PgDn anstellen?

Da hast du natürlich recht, sehr aufmerksam :)
Im Extremfall können es sogar 6 oder 7 Ziffern werden, macht trotzdem keinen Unterschied.

Okay, anscheinend werden sie synonym zu Home und End interpretiert.

Ja, und möglicherweise gibt es Leute, die sie auch bei einzeilgen Feldern so benutzen, man weiß ja nie...
Aber der eigentliche Grund war ursprünglich, dass sie von den (falschen) Codes her gerade gut dazupassten. Schaden kann es ja nicht, wenn die funktionstüchtig bleiben, da sie kein störendes Zeichen im Feld hinterlassen.

Aber von der Grundidee her stehen sie für eine vertikale Navigation, was sich ja auch in den Bezeichnungen "Up" und "Down" oder in den Pfeilen auf den Tasten widerspiegelt. Ich käme also nicht auf die Idee, diese Tasten in einem einzeiligen EIngabefeld benutzen zu wollen.

Die Up/Dn-Cursortasten würde ich auch nie benutzen in einem einzeiligen Feld, zumal sie da gar keine Wirkung zeigen. Sie passten halt von den (falschen) Codes her auch gerade gut dazu und fallen nicht ins Gewicht.

Es gibt natürlich noch ein paar mehr, die aktiv bleiben sollten:
Backspace, Delete, Esc, Enter, Ctrl und Shift

Gruß, Don P

[Der Martin]

Hi,

Was zum Geier soll ich in einem (einzeiligen) Eingabefeld für 4 Ziffern mit den Tasten PgUp und PgDn anstellen?
Okay, anscheinend werden sie synonym zu Home und End interpretiert.
Die Up/Dn-Cursortasten würde ich auch nie benutzen in einem einzeiligen Feld, zumal sie da gar keine Wirkung zeigen.

die "blättern" doch AFAIR in der Eingabehistorie vor und zurück, wenn man dieses Feature nutzt. Insofern (für den, der's nutzt) nicht ganz sinnlos.

Es gibt natürlich noch ein paar mehr, die aktiv bleiben sollten:
Backspace, Delete, Esc, Enter, Ctrl und Shift

Unbedingt, ja!

Ciao,
 Martin