Alertfenster
Gerie
- javascript
Hallo !
Ich möchte das sich das Alertfenster nur 1 mal bei
onmouseover öffnet.
Meiner Meinung nach müssete es mit einer Variablen funktionieren, aber wie ?
Vielleicht kann mir jemand dabei helfen ?
Vielen dank im Voraus
Gerie
<html>
<head>
<SCRIPT language="JavaScript">
<!--
function ask()
{
alert ("Bericht wirklich abschicken ?";
}
//-->
</SCRIPT>
</head>
<body>
<FORM method=Post" action="mailto:" emailadresse">
<p><input type="submit" value="senden" onmouseover="ask()" name="senden"></p>
</form>
</body>
</html>
Moin Moin !
Hallo !
Ich möchte das sich das Alertfenster nur 1 mal bei
onmouseover öffnet.
var sawalert=false;
function meepmeep()
{
if (!sawalert) {
alert('meepmeep');
sawalert=true;
}
}
<a onmouseover="meepmeep()" ...>
Alexander
Hi Gerie,
Meiner Meinung nach müssete es mit einer Variablen funktionieren, aber wie ?
Z.B. so:
<SCRIPT language="JavaScript">
<!--
var fAlreadyAsked = false;
function ask()
{
if ( !fAlreadyAsked )
{
alert( "Bericht wirklich abschicken ?" );
fAlreadyAsked = trueM
}
}
//-->
</SCRIPT>
Durch die Deklaration ausserhalb einer Funktion ist fAlreadyAsked eine globale Variable, die mit false initialisiert wird.
Aber mal ne Frage, wie willst du die Frage auswerten? alert hat nur einen OK-Button. Beim IE gibt's ja noch confirm, aber das solltest du nur benutzen bei Intranet-Sachen, wenn du dem Benutzer den Browser vorschreiben kannst.
Gruß,
Martin
Hallo Martin,
Aber mal ne Frage, wie willst du die Frage auswerten? alert hat nur einen OK-Button.
Soweit ok.
Beim IE gibt's ja noch confirm, aber das solltest du nur benutzen bei Intranet-Sachen, wenn du dem Benutzer den Browser vorschreiben kannst.
Mit Verlaub, das ist Unsinn. confirm ist seit Javascript 1.0 ganz normaler Bestandteil der Sprache und hat mit IE erst mal gar nix zu tun.
Grüße
Andreas
Hi Andreas,
Mit Verlaub, das ist Unsinn. confirm ist seit Javascript 1.0 ganz normaler Bestandteil der Sprache und hat mit IE erst mal gar nix zu tun.
oops. Echt? Ich hab da auf die MSDN vertraut, die am Schluß der Referenz immer schreibt, in welchem Standard es drin ist. Dort steht: "There is no public standard that applies to this method." Hab mich halt darauf verlassen, wenn MS schon sagt, dass sie am Standard vorbei arbeiten. Ich kontrollier meist nur, wenn da nix steht, oder es dem Standard entsprechen soll.
Gruß,
Martin
Hallo Martin,
oops. Echt? Ich hab da auf die MSDN vertraut, die am Schluß der Referenz immer schreibt, in welchem Standard es drin ist. Dort steht: "There is no public standard that applies to this method." Hab mich halt darauf verlassen, wenn MS schon sagt, dass sie am Standard vorbei arbeiten. Ich kontrollier meist nur, wenn da nix steht, oder es dem Standard entsprechen soll.
Ehrlich gesagt schau ich da nie rein. Ich vertraue voll und ganz auf selfhtml :-)
Außerdem hat bei confirm bei mir noch kein Browser Probleme gemacht.
Grüße
Andreas
Hi Andreas,
Ehrlich gesagt schau ich da nie rein. Ich vertraue voll und ganz auf selfhtml :-)
Ich bin halt mehr die MSDN als Referenz gewohnt. Da steht alles tabellarisch da, vor allem die Properties und Methoden, die es so gibt :-)
Außerdem hat bei confirm bei mir noch kein Browser Probleme gemacht.
Bei mir auch nicht. Wir entwickeln hier nämlich was für's Intranet, und können unseren Kunden die Browser vorschreiben *g* Ich weiß zwar nicht, wieso wir extra ne Webapplikation schreiben, wenn der Client nachher doch nur unter IE/Windows läuft, aber was soll's. Mein Teamleiter konnte ne entsprechende Frage auch nicht beantworten, er wirkte da etwas verblüfft ;-)
Gruß,
Martin
Moin Moin !
Bei mir auch nicht. Wir entwickeln hier nämlich was für's Intranet, und können unseren Kunden die Browser vorschreiben *g* Ich weiß zwar nicht, wieso wir extra ne Webapplikation schreiben, wenn der Client nachher doch nur unter IE/Windows läuft, aber was soll's. Mein Teamleiter konnte ne entsprechende Frage auch nicht beantworten, er wirkte da etwas verblüfft ;-)
Tja, kommt mir irgendwie bekannt vor. ;-)
Das schöne an so einer "Microsoft-Web"-Applikation ist eben, das man sich das installieren einer Client-Software sparen kann. Wenn kein anderer Browser mit dem HTML-Murks aus der "Microsoft-Web"-Applikation klar kommt, ist das eben Pech. Für's Intranet, wo man den Usern Betriebssystem und Browser vorschreiben kann, ist die Lösung ausreichend (im Sinne einer Schulnote 4).
Man könnte natürlich auch gleich eine "richtige" Web-Applikation bauen, die mit allen gängigen Browsern incl. IE funktioniert, das erspart einem das Theater, wenn man (endlich) merkt, daß der IE oder Windows eben nicht allen Anforderungen genügt.
Gut, das bei mir andere für die "Microsoft-Web"-Applikationen verantwortlich sind. Meine Applikation ist eine "richtige" Web-Applikation.
Alexander
Hi Alexander,
Man könnte natürlich auch gleich eine "richtige" Web-Applikation bauen, die mit allen gängigen Browsern incl. IE funktioniert, das erspart einem das Theater, wenn man (endlich) merkt, daß der IE oder Windows eben nicht allen Anforderungen genügt.
dazu muss man sagen, dass es auch in der Entwicklung mehr kostet, was sich dann aufs Produkt auswirkt. Ausserdem geht Manches nicht mehr. Ich hab z.B. letzte Woche eine MessageBox gebraucht, um eine Ja/Nein/Abbrechen-Abfrage zu machen. Da bot sich showModalDialog einfach an.
Aber generell dachte ich, dass sich ein "normaler" Client, sprich ein eigenständiges Programm, noch mehr gelohnt hätten. Da würde vieles einfacher gehen, z.B. das Mitschleppen von Session-Variablen von Seite zu Seite würde einfach entfallen.
Gruß,
Martin
Hallo, Martin und Alexander,
Man könnte natürlich auch gleich eine "richtige" Web-Applikation bauen, die mit allen gängigen Browsern incl. IE funktioniert, das erspart einem das Theater, wenn man (endlich) merkt, daß der IE oder Windows eben nicht allen Anforderungen genügt.
ACK.
dazu muss man sagen, dass es auch in der Entwicklung mehr kostet, was sich dann aufs Produkt auswirkt. Ausserdem geht Manches nicht mehr. Ich hab z.B. letzte Woche eine MessageBox gebraucht, um eine Ja/Nein/Abbrechen-Abfrage zu machen. Da bot sich showModalDialog einfach an.
Genau das denke ich auch, auch deinen Schluss daraus:
Aber generell dachte ich, dass sich ein "normaler" Client, sprich ein eigenständiges Programm, noch mehr gelohnt hätten. Da würde vieles einfacher gehen, z.B. das Mitschleppen von Session-Variablen von Seite zu Seite würde einfach entfallen.
Ähm, ich habe ja keine Ahnung, aber wieso verwendet man dann HTTP-Anwendungen, wenn man doch einen um ein vielfaches effizienter bedienbareren Client entwickeln könnte, welcher nahtlos an die Serveranwendung angepasst ist? Je spezieller die Aufgaben sein sollen, desto naheliegender wäre ein eigenständiges Clientprogramm, ob das HTTP weiterhin als Protokoll verwendet wird, muss nicht ausgeschlossen werden, schließlich bietet sich es zur Übermittlung von Daten in XML-Sprachen an. Hypertext ist nunmal per se nicht das richtige Medium und ein Browser nicht das perfekte Benutzerinterface für eine Anwendung, ich kann vollkommen verstehen, wieso der Browser durch die Scripterweiterung des MSIEs gefügig gemacht werden muss, schließlich werden diese Anforderungen an einen Hypertextagent normalerweise nicht gestellt und der Browser wird zweckentfremdet. Interaktion mit dem Benutzer durch von dir genannte Standarddialoge ist in der Regel einem auf dem Clientrechner ausführbaren speziellen Programm vorbehalten, ein Browser eignet sich für solche Aufgaben eher wenig.
Andersherum würde ich für den Fall, dass auf den Browser als Clientprogramm nicht verzichtet werden soll, dafür plädieren, dass eine Intranet-HTTP/HTML-Anwendung soviel wie möglich serverseitig überprüfen sollte, einerseits weil der Browser durch Fehlbedienung beziehungsweise einer Bedienung, welche dem gewöhnlichen Hypertextnavigieren eigen ist, unzuverlässig ist, es sei denn, man staucht den Browser so zusammen, dass er nur das Klicken auf Links sowie das Ausfüllen von Formularen erlaubt, das dann natürlich durch die clientseitigen Möglichkeiten überprüft werden könnten etc.
Generell ist es kein Anzeichen von hoher »Systemstrukturqualität«, die Flexibilität einer HTTP-Anwendung dadurch zu begrenzen, sie auf ein spezielles Clientprogramm zu münzen, wenn es unnötig ist und ebenso die Ünterstützung verschiedener Clientplatformen und generell Interfaces möglich wäre. Wenn das Intranet beispielsweise aus Rechnern verschiedener Betriebssysteme besteht, ist eine auf MSIE geprägte Anwenderoberfläche (hier zeigt sich erneut die Paradoxie) unzuverlässig, genauso müsste die Serveranwendung komplett umgeschrieben werden, wenn sich das Unternehmen entscheidet, einen anderen Browser als MSIE einzusetzen, weil die Supportverträge auslaufen oder man sich entscheidet, einen auf Gecko basierenden Client zu entwickeln (was IMHO die perfekte Lösung ist, da man nicht auf Hypertext verzichten muss, den Client aber optimal einschränken und erweitern kann, ohne einen komplett eigenen Client zu schreiben).
Grüße,
Mathias
Hi,
Meiner Meinung nach müssete es mit einer Variablen funktionieren, aber wie ?
indem Du sie global setzt, in der Funktion prüfst und ggf. veränderst.
<SCRIPT language="JavaScript">
ERROR: Required attribute "type" missing.
alert ("Bericht wirklich abschicken ?";
Von der fehlenden Klammer mal abgesehen: Die öffnende Klammer bei Funktionen sollte man direkt an den Funktionsnamen anschließen, und in der deutschen Sprache ist vor einem Satzendezeichen ebenfalls kein Leerzeichen.
<FORM method=Post" action="mailto:" emailadresse">
http://www.praast.de/ffq/mailto.htm
Wenn Du diesen Code mit Copy&Paste hier ins Forum gebracht hast - und alles andere ist sinnarm - solltest Du _dringend_ an Deinem Stil arbeiten und/oder Dich mit dem einen oder anderen Checker beschäftigen; beispielsweise mit http://validator.w3.org/. Natürlich kann sich immer mal ein Fipptehler einschleichen, aber Dein Code strotzt davon.
Cheatah
Halihallo Gerie
Ich möchte das sich das Alertfenster nur 1 mal bei
onmouseover öffnet.
Meiner Meinung nach müssete es mit einer Variablen funktionieren, aber wie ?
<body>
<FORM method=Post" action="mailto:" emailadresse">
<p><input type="submit" value="senden" onmouseover="ask()" name="senden"></p>
</form>
btw. was soll das ganze überhaupt mal werden? - Ich klicke nirgens drauf und schon kommt so'n blöder Dialog, der mich nervt und mich fragt, ob ich wirklich absenden will. Natürlich will ich absenden, wenn ich auf "senden" klicke!
Verfolge lieber den Vorschlag von Martin. Also: Dein Client _klickt_ (nicht fährt-über) auf "senden" und dann wird eben nochmals gefragt, ob er dies wirklich tun will. Aber ohne dass der Client irgendetwas macht (ausser eben seine Maus zu bewegen, was du ihm hoffentlich nicht vermiesen willst), soll auch nix geschehen. Diese Dialogbox ist höchstenfalls verwirrend, der Client fragt sich, was er getan hat... "huch, jetzt bin ich über 'senden' gefahren und schon sendet er das Formular, und ich kann nichtmal auf abbrechen klicken"...
Viele Grüsse
Philipp
hi
Ich möchte das sich das Alertfenster nur 1 mal bei
onmouseover öffnet.
Meiner Meinung nach müssete es mit einer Variablen funktionieren, aber wie ?
Vielleicht kann mir jemand dabei helfen ?
schon, aber ich würde nicht fragen, wenn man ausversehen mit der Maus dem Button zu Nahe kommt, sondern allerhöchstens wenn wirklich geklickt wurde! Beachte, dass es viele DAUs gibt, die sobald irgendwas unerwartetes auf dem Bildschrim erscheint, das nach Fehler aussieht panisch die Kiste ausmachen...!
Grüße aus Bleckede
Kai