Standardaktion für Leertaste verhindern

[peter]

Hallo Forum,

ich kämpfe hier mit der Standardaktion für die Leertaste und kriegs einfach nicht hin.

Hab in nem Frame ne Karte und möchte bei "onkeydown" ne Zusatzfunktion einblenden.

Das haut alles auch hin, nur wird beim Drücken der Leertaste die Standardaktion derselben durchgeführt.
Das heisst, daß meine Karte (is größer als der Frame) nach unten gescrollt wird.
Kann mir jemand sagen, wie ich das verhindern kann?

Viele Grüße

Peter

[Gernot Back]

Hallo peter,

Hab in nem Frame ne Karte und möchte bei "onkeydown" ne Zusatzfunktion einblenden.

Das haut alles auch hin, nur wird beim Drücken der Leertaste die Standardaktion derselben durchgeführt.

Ich würde eher mit onkeypress arbeiten und wenn der Keycode dem der Leertaste(32) entspricht, die Aktion unterbinden.

  
function welche (e) {  
  var e = e || window.event;  
  if(window.captureEvents) {  
    var taste = e.which;  
  } else {  
    var taste = e.keyCode;  
  }  
  if(taste==32)  
    alert('Ich sach nichts!');  
  else  
    alert('Bin bereit!');  
}  
  
if (window.captureEvents) {  
  window.captureEvents(Event.KEYPRESS);  
  window.onkeypress=welche;  
} else {  
  document.onkeypress=welche;  
}  

Gruß Gernot

[peter]

Hallo Gernot,

erstmal vielen Dank für deine Antwort.Konnte leider nicht früher zurückschreiben, da ich den ganzen Nachmittag bis jetzt unterwegs war.

Interressant finde ich folgendes Konstrukt:
var e = e || window.event;

Das war mir bis jetzt noch nicht bewußt, daß das auch bei Zuweisungen geht.
Dachte bis jetzt, das ODER ("||") wäre nur bei Vergleichen möglich.
Werd das mal ausprobieren , bisher hab ichs immer so gemacht:
if(!e){e=window.event;}

Ich würde eher mit onkeypress arbeiten und wenn der Keycode dem der Leertaste(32) entspricht, die Aktion unterbinden.

Jo, nehm ich keypress.

Okay, für NS 4 schreib ich nicht mehr.
Da müßte ich auf zu viele Funktionalitäten im Script verzichten.

Um eine abgespeckte Version für den 4er zum Laufen zu bringen würde ein komplett eigenes Projekt entstehen nur für den NS 4.
Der Aufwand ist leider zu groß.

Ohne NS4 würde dein Vorschlag also so aussehen:

**************************************

function welche (e)
{
var e = e || window.event;

var taste = e.keyCode;

if(taste==32)
{alert('Ich sach nichts!');}

else
{alert('Bin bereit!');}

}

document.onkeypress=welche;

**************************************

Gibt dann zwar unterschiedliche Meldungen aus, wenns die Leertaste is oder nicht.
Verhindert aber nicht die Ausführung der Standardaktion der Leertaste, sprich das Scrollen des Dokumentes im Fenster.

Ich habs schon mit einem "return false" in der Funktion versucht, das brachte aber nichts.

Oder müßte man die Funktion dann auch so zuweisen ?:

**************************************
document.onkeypress=return welche;
**************************************

Das kommt mir eher komisch vor, kann ja aber mal probieren ob sowas geht.

Dein Ansatz brachte mich allerdings noch auf die Idee, das ganze mal mit "cancelBubble" bzw. "stopPropagation" zu versuchen.

Mal schaun, was bei den ganzen Versuchen rauskommt, werds hier mal mitteilen, wenn ich Ergebnisse hab.

Viele Grüße und gute Nacht

Peter

[peter]

Hi,

bin hier beim Stöbern und Schmökern in meinen Büchern und Scripten auch noch auf das gestoßen:

************************************
if(e.preventDefault){e.preventDefault()}else{e.returnValue=false;}
************************************

Das könnts vielleicht sein, was ich such.

Jetzt ist aber endgültig Feierabend.
Kiste ausmachen, ausprobiert wirds morgen!

Gute Nacht

Peter

[Gernot Back]

Hallo peter,

ja, das scheint tatsächlich die Lösung zu sein:

  
function welche (e) {  
  var e = e || window.event;  
  if(window.captureEvents) {  
    var taste = e.which;  
  } else {  
    var taste = e.keyCode;  
  }  
  if(taste==32) {  
    if(e.preventDefault)  
      e.preventDefault();  
    else  
      e.returnValue=false;  
  }  
}  
  
if (window.captureEvents) {  
  window.captureEvents(Event.KEYPRESS);  
  // auf die eine Zeile vorher (für Netscape 4.X) kommt's nicht an  
  window.onkeypress=welche;  
} else {  
  document.onkeypress=welche;  
}  

Gruß Gernot

[Struppi]

function welche (e) {
  var e = e || window.event;
  if(window.captureEvents) {
    var taste = e.which;
  } else {
    var taste = e.keyCode;
  }

Nach der elegenaten Lösung der ersten Zeile, ist der zweite Vergleich nicht besonders sinnvoll, was hat captureEvents mit which oder keyCode zu tun? Nichts. Außerdem sollte eigentlich var eine Variabel in einem Block lokal definieren, d.h. ausserhalb von {} sollte taste nicht mehr zu Verfügung stehen (tut es aber, in meinen augen eine Fehler, aber da Wissen andere mehr drüber).

Also einfach wie das erste:

var taste = e.which || e.keyCode;

Was events und ihre Behnadlung angeht ist diese Seite http://www.quirksmode.org/js/introevents.html sehr gut.

Ich vermute mal, dass der Peter nach Event bubbling sucht http://www.quirksmode.org/js/events_order.html

Struppi.

[Gernot Back]

Hallo Struppi,

Nach der elegenaten Lösung der ersten Zeile, ist der zweite Vergleich nicht besonders sinnvoll, was hat captureEvents mit which oder keyCode zu tun? Nichts. Außerdem sollte eigentlich var eine Variabel in einem Block lokal definieren, d.h. ausserhalb von {} sollte taste nicht mehr zu Verfügung stehen (tut es aber, in meinen augen eine Fehler, aber da Wissen andere mehr drüber).

Also einfach wie das erste:

var taste = e.which || e.keyCode;

Ja, das ist der Nachteil, wenn man nach der "Trial&Error"-Methode vorgeht.

vgl.: https://forum.selfhtml.org/?t=108434&m=675494

Ich will versuchen, deine Ratschläge zu beherzigen und in Zukunft ein bisschen mehr Hirn einzuschalten. Das habe ich vor kurzem schon Cybaer versprochen, und jetzt dieser Rückfall! Ich ärgere mich über mich selbst!

Gruß Gernot

[peter]

Hi Struppi,

Ich vermute mal, dass der Peter nach Event bubbling sucht http://www.quirksmode.org/js/events_order.html

Ja, das dachte ich auch.
Ist aber nicht so.

Mit cancelBubble und stopPropagation wird nur das Weiterreichen des Events "auf der Seite" verhindert aber nicht, daß "der Browser selbst" das ausführt, was er immmer macht, wenn die Leertaste gedrückt wird.

Is wohl so ne ähnliche Geschichte wie mit der rechten Maustaste.

Auch preventDefault und returnValue=false brachte nicht den gewünschten Erfolg.

Denkbar wäre für mich noch, einem anderen ("Blind-")Frame den Focus zu geben und das ganze in diesem Frame auszuführen.
Da wird dann nichts angezeigt sondern nur das Script aufgerufen, da darf er meinetwegen soviel rumscrollen wie er will.

Vielleicht hab ich auch mit obengenannten Funktionen was falschgemacht, rumprobieren werd ich damit auf jeden Fall nochmal.

Oder es liegt daran, daß ich das auf window- bzw. document- Ebene notiert hab.
Wenn ichs mal ne Ebene höher notiere...???

Oder es liegt allgemein an der Konstellation, die ich habe...???

Werd bei nächster Gelegenheit mal ne ganz einfache Seite basteln, wo ich das alles mal austesten kann.

Gruß

peter

[Gernot Back]

Hallo peter,

Mit cancelBubble und stopPropagation wird nur das Weiterreichen des Events "auf der Seite" verhindert aber nicht, daß "der Browser selbst" das ausführt, was er immmer macht, wenn die Leertaste gedrückt wird.

Oder es liegt daran, daß ich das auf window- bzw. document- Ebene notiert hab.
Wenn ichs mal ne Ebene höher notiere...???

eher eine Ebene tiefer, du sprachst von Karten, ich vermute DIV-Elemente in einem Spiel.

Binde das Event mal an dieses Element!

Gruß Gernot

[molily]

Hallo,

Oder es liegt daran, daß ich das auf window- bzw. document- Ebene notiert hab.
Wenn ichs mal ne Ebene höher notiere...???

eher eine Ebene tiefer, du sprachst von Karten, ich vermute DIV-Elemente in einem Spiel.

Hm. Wie kann ein div-Element Ziel eines Keypress-Events sein? Es kann schlecht den Fokus haben, daher sollte in einem solchen Fall document das Ziel (target) der Keypress-Events sein.
Es könnten höchstens andere Elemente, z.B. Eingabefelder, im div enthalten, sodass das Ereignis »aufsteigt« und auch beim div vorbeikommt.

Mathias

[peter]

HI

Oder es liegt daran, daß ich das auf window- bzw. document- Ebene notiert hab.
Wenn ichs mal ne Ebene höher notiere...???

eher eine Ebene tiefer, du sprachst von Karten, ich vermute DIV-Elemente in einem Spiel.

Jo, hatte ich auch sorum gemeint, war falsch ausgedrückt von mir.

Hm. Wie kann ein div-Element Ziel eines Keypress-Events sein? Es kann schlecht den Fokus haben, daher sollte in einem solchen Fall document das Ziel (target) der Keypress-Events sein.
Es könnten höchstens andere Elemente, z.B. Eingabefelder, im div enthalten, sodass das Ereignis »aufsteigt« und auch beim div vorbeikommt.

Oder ich mach ein blindes Eingabefeld und setz es direkt da drauf.
?????

Allerdings alles auch etwas merkwürdige Konstrukte mit denen ich nicht so richtig glücklich werden kann.

Gruß

peter

[molily]

Hallo,

Is wohl so ne ähnliche Geschichte wie mit der rechten Maustaste.

Vielleicht, man kennt die Sicherungsmechanismen der Browser nicht genau.

Auch preventDefault und returnValue=false brachte nicht den gewünschten Erfolg.

return false; wäre noch eine Möglichkeit, also if (taste==32) { /* preventDefault/returnValue */ return false; }.
Wenn das auch nicht das Gewünschte bringt, dann lässt sich der Browser in diesem Punkt nicht mit JavaScript beschneiden.

Oder es liegt daran, daß ich das auf window- bzw. document- Ebene notiert hab.

Daran sollte es nicht liegen. Der Handler wird auf jeden Fall vor der Standardaktion ausgeführt, auf oberster Ebene sollte auch das Abbrechen des Events möglich sein.

Mathias

[molily]

Hallo,

if (window.captureEvents) {
  window.captureEvents(Event.KEYPRESS);
  // auf die eine Zeile vorher (für Netscape 4.X) kommt's nicht an
  window.onkeypress=welche;
} else {
  document.onkeypress=welche;
}

  
Nur eine formale Anmerkung:  
Wie du schon sagst, die Browserabfrage ist ziemlich spekulativ. window.captureEvents kennen wie gesagt auch Opera, KHTML und Gecko, das heißt, die Methode existiert, ohne eine Wirkung oder Notwendigkeit zu haben.  
\*Falls\* window.onkeypress nun in einem dieser Browser \*nicht\* funktionieren würde, und der Handler für document vergeben werden müsste, würde man in der Patsche sitzen. Dass die Koppelung captureEvents + window.onkeypress klappt, ist also eher ein glücklicher Zufall. Eine bessere Abfrage wüsste ich aber auch nicht. ;) Man könnte höchstens untersuchen, ob eine Fallunterscheidung überhaupt nötig ist oder ob eine doppelte Zuweisung nicht für alle Browser reicht. Dann wird der Handler im KHTML und Gecko zwar zweimal aufgerufen (Opera hingegen erkennt den doppelten Handler und feuert nur den von document), aber das sollte nicht weiter stören. (Bzw. dagegen würde notfalls e.cancelBubble = true; if (e.stopPropagation) e.stopPropagation(); helfen.)  
  
Mathias

[peter]

Hi Mathias

Man könnte höchstens untersuchen, ob eine Fallunterscheidung überhaupt nötig ist oder ob eine doppelte Zuweisung nicht für alle Browser reicht. Dann wird der Handler im KHTML und Gecko zwar zweimal aufgerufen (Opera hingegen erkennt den doppelten Handler und feuert nur den von document), aber das sollte nicht weiter stören. (Bzw. dagegen würde notfalls e.cancelBubble = true; if (e.stopPropagation) e.stopPropagation(); helfen.)

Halte deinen Vorschlag auch für die eleganteste Lösung.
Ich versuche bei mir auch immer, eine solche Abfrage nicht an irgendwelche anderen Eigenarten der Browser zu koppeln, sondern direkt an das um was es auch geht.

Mit dem doppelten Abfeuern ist meiner Meinung nach aber höchste Vorsicht geboten !
Da gerät schnell mal was durcheinander.

Ich wills zum Beispiel als Umschalter zwischen 2 Bedienungsmodi verwenden.
In der Funktion wird dann abgefragt, in welchem Modus man sich gerade befindet und dann entsprechend in den anderen umgeschaltet.

Beim doppelten Abfeuern würde dann einmal umgeschaltet und auch gleich wieder zurück. Da tut sich dann also gar nichts.

Script sollte dann also so aussehen ? :

*****************************************

function FUNKTION(e)
{

if(!e){e=window.event;}

if(e.stopPropagation)
{e.stopPropagation();}
else
{e.cancelBubble=true;}

//...weiterer Code....

}

window.document.onkeypress=FUNKTION;

window.onkeypress=FUNKTION;

*****************************************

Bitte mich zu korrigieren, falls ich hier Blödsinn verzapfe.

Gruß

Peter

[Gernot Back]

Hallo peter,

Interressant finde ich folgendes Konstrukt:
var e = e || window.event;
Dachte bis jetzt, das ODER ("||") wäre nur bei Vergleichen möglich.
Werd das mal ausprobieren , bisher hab ichs immer so gemacht:
if(!e){e=window.event;}

Das habe ich mir im JS-Workshop von Mintert/Kühnel abgeschaut, ist nicht meine Erfindung. Man schaut sich im Laufe der Zeit so einiges an Skripten an, benutzt sie als Steinbruch und baut sich seine eigenen Kathedralen damit zusammen.

Jo, nehm ich keypress.
Okay, für NS 4 schreib ich nicht mehr.
Da müßte ich auf zu viele Funktionalitäten im Script verzichten.

Soweit es "mein" Skript betrifft, funktioniert es auch in Netscape4.

Um eine abgespeckte Version für den 4er zum Laufen zu bringen würde ein komplett eigenes Projekt entstehen nur für den NS 4.
Der Aufwand ist leider zu groß.

Ohne NS4 würde dein Vorschlag also so aussehen:

  

> function welche (e)  
> {  
> var e = e || window.event;  
>   
> var taste = e.keyCode;  
  

> if(taste==32)  
> {alert('Ich sach nichts!');}  
  

> else  
> {alert('Bin bereit!');}  
  

> }  
  

> document.onkeypress=welche;  

Davon würde ich abraten, denn window.captureEvents kennen auch Mozilla und Opera und die brauchen, wenn ich mich an meine damaligen Experimente richtig erinnere window.onkeypress=welche;

Nur der IE benötigt die Extrawurst mit document.onkeypress=welche;;

Verhindert aber nicht die Ausführung der Standardaktion der Leertaste, sprich das Scrollen des Dokumentes im Fenster.
Ich habs schon mit einem "return false" in der Funktion versucht, das brachte aber nichts.
Oder müßte man die Funktion dann auch so zuweisen ?:
document.onkeypress=return welche;
die Idee, das ganze mal mit "cancelBubble" bzw. "stopPropagation" zu versuchen.

Ich würde da auch wie wild erst mal ins blaue hinein experimentieren; alles gute Ideen, soweit ich das mit meinen oft unzureichenden Kenntnissen beurteilen kann. Ich habe mir bisher das meiste beim Programmieren durch "Trial and Error" erschlossen.

Mal schaun, was bei den ganzen Versuchen rauskommt, werds hier mal mitteilen, wenn ich Ergebnisse hab.

Das ist löblich, dann brauchen wir anderen das nächste Mal auch weniger "Trial and Error".

;-)

Gruß Gernot