"close" als Eigenschaft?

[Claus]

Hallo,

ich habe folgenden Code geklaut, und er funktioniert auch. Die Frage ist nur: Warum?

function Closer(){
        if (window.FensterObj && FensterObj.close) FensterObj.close();
        return;
}

Die Funktion "Closer()" schließt also ein evtl. geöffnetes Fenster und sorgt dafür, dass es keine Fehlermeldung gibt, falls "FensterObj" gar nicht existiert. Dabei ergibt für mich die Abfrage
"if (FensterObj.close)" keinen Sinn. Ich kenne nur "close()" als Methode und "closed" als Eigenschaft. Was soll das also?
Bin mal gespannt...

Grüße,
Claus

[holger kuehne]

Hi claus
Nicht das ich mir ganz sicher ware ob das stimmt was ich jetzt schreibe....
Also: Meiner Meinung nach ist es so, dass mit if (FensterObj.close) abgefragt wird ob fuer das Objekt FensterObj die Methode close() existiert. Mit so einer if Abfrage kann man alle Methoden und Eigenschaften eines Objektes abfragen.Siehe auch Erlaeuterungen in
<../../tebc.htm#a6>

Tschau Holger

[Bio]

Das hat wohl ein IE Programmierer verbrochen! Das

&& FensterObj.close

ist naemlich Schwachsinn!

Wenn man sich mit alert mal window.close ausgeben laesst, kriegt man, weil das strenggenommen eine Referenz/ein Zeiger auf die Methode .close() ist, ein Stueck Code zurueck. Dieses Stueck Code ist fuer JS ein String, und damit ungleich 0, also true, und man koennte genausogut && 1 schreiben.

:-))

Bio

[Bio]

Uiuiui...

natuerlich koennte diese Methode auch gar nicht existieren... Dann waere die Referenz darauf wohl 0, und false, und das waere doch kein Schwachsinn... was natuerlich an meiner Meinung ueber IE Programmierer nichts aendert ]:-)

Trotzdem kann es meines Erachtens gar nicht sein, dass ein Fenster keine Methode close kennt... oder gibt es window.open ("...","...","uncloseable=yes") ???

Bio

[Claus]

Trotzdem kann es meines Erachtens gar nicht sein, dass ein Fenster keine Methode close kennt... oder gibt es window.open ("...","...","uncloseable=yes") ???

Bio

Jetzt wird's interessant!

Ich habe jetzt aus dem If-Statement "&& FensterObj.close" weggelassen. Alles schön und gut, aber nachdem man einmal das Fenster geöffnet und dann wieder geschlossen hat, kommt eine Fehlermeldung, wenn die Funktion "Close()" ausgeführt wird:
"FensterObj.close is not a function."
Das passiert allerdings nicht mit dem scheinbar wertlosen Statement "...&& FensterObj.close". Irgendetwas "macht" das also, fragt sich nur was!

Wer kann das jetzt erklären?

Gespannt,
Claus

[Günter Marchewka]

Hallo Claus,
hast Du mal geguckt, ob FensterObj vielleicht ein Array oder eine JSVariable ist, die im Code definiert wird und der die Eigenschaft close zugeordnet wurde?
Ich bin IE-Programmierer (oh... geoutet) und kenne keine deutschsprachigen Befehle im IE, ob es welche unter NS gibt? (lerne gerne dazu)
MfG Günter

[Claus]

Hallo Claus,
hast Du mal geguckt, ob FensterObj vielleicht ein Array oder eine JSVariable ist, die im Code definiert wird und der die Eigenschaft close zugeordnet wurde?
Ich bin IE-Programmierer (oh... geoutet) und kenne keine deutschsprachigen Befehle im IE, ob es welche unter NS gibt? (lerne gerne dazu)
MfG Günter

Hallo Günter,

"FensterObj" ist eine ganz normale Window-Instanz, also das zu einem geöffneten Fenster gehörige Objekt. Den deutschen Namen habe ich ihr verliehen.

Übrigens tritt das Problem bei Netscape auf.

Gruß,
Claus

[Claus]

function Closer(){
        if (window.FensterObj && FensterObj.close) FensterObj.close();
        return;
}

So, ich glaube, ich habe eine Erklärung:

Wurde ein Fenster geöffnet und dann wieder geschlossen, so exisitiert das zugehörige Window-Objekt (FensterObj) immernoch; die Methode "close()" kann aber nicht angewendet werden, da das Fenster ja nicht mehr existiert. Daher die zweite Bedingung. Ein Window-Objekt kann also in manchen Fällen durchaus nicht über die Methode "close()" verfügen, nämlich dann, wenn das Fenster nicht mehr exisitiert.
Oder ist das des Rätsels Lösung?

Claus

[brand]

Hi!

function Closer(){
        if (window.FensterObj && FensterObj.close) FensterObj.close();
        return;
}

meines Erachtens ist eines der beiden Statements umsonst.
(Ursprünglich dachte ich, daß, egal welches man wegläßt, das Ergebnis das gleiche sein müßte, da ja window.FensterObj abfragt, ob das Fenster existiert, und FensterObj.close, ob es die Methode close des FensterObj gibt - die kanns doch nicht geben, wenn das Fenster nicht mehr existiert - denkste)

Tatsächlich ist's beim IE (4.0) egal welche der beiden Abfragen man wegläßt.
Beim NS allerdings nicht, da FensterObj immer noch existiert, wenn es einmal geöffnet und wieder geschlossen wurde. Die Methode FensterObj.close gibts bei geschlossenen Fenstern (die als Objekt noch irgendwo in den Unsichtbaren Regionen des Netscape herumschwirren) aber nicht mehr.

Also kann man die Abfrage window.FensterObj weglassen (nicht aber die FensterObj.close)

brand

[Bio]

Grotesk...
Sachen gibt's.
Fragt sich, welcher Browser diesmal 'falscher' liegt, vom Standpunkt des objektorientierten Programmierers aus gesehen...
Und wieder was gelernt.

Bio

[Claus]

Moooment mal!!

Also kann man die Abfrage window.FensterObj weglassen (nicht aber die FensterObj.close)

brand

Hallo Brand,

wenn man die Abfrage "window.FensterObj" weglässt, mecker Netscape:
"FensterObj is not defined". Mann braucht also tatsächlich beide Abfragen. Warum? Watt weiss ich...

Vielen Dank an alle Helfer!
Claus

[brand]

Hi!

wenn man die Abfrage "window.FensterObj" weglässt, mecker Netscape:
"FensterObj is not defined".

Aha! Aber nur, wenn das Fenster noch nie geöffnet (und wieder geschlossen wurde). - das hatte ich vorhin noch nicht probiert!

BRAND

[Calocybe]

Hi Leuts!

(Ursprünglich dachte ich, daß, egal welches man wegläßt, das Ergebnis das gleiche sein müßte, da ja window.FensterObj abfragt, ob das Fenster existiert, und FensterObj.close, ob es die Methode close des FensterObj gibt - die kanns doch nicht geben, wenn das Fenster nicht mehr existiert - denkste)

FensterObj ist lediglich eine Referenz auf ein Speicherobjekt, ueber welches man auf das echte Fenster zugreifen und dieses manipulieren kann. Das (Speicher-)Objekt und das echte Fenster sind also zwei verschiedene Dinge. Schliest nun der Anwender das Fenster, so existiert das Objekt aber weiterhin. Und das ist auch gut so, denn es kann nicht angehen, dass von *irgendjemandem* ohne des JS-Programmierers Zutun einfach Variablen auf null oder undefined gesetzt werden. (Das naechste Mal aendert sich vielleicht auch noch der Wert einer Variablen einfach mal so von 3 auf 10, oder was?) Das Objekt, das das Fenster repraesentiert, kann aber sehr wohl den Inhalt einer seiner Membervariablen aendern, denn dazu ist es ja da - so ist die Klasse "window" eben definiert. Und so reagiert das Objekt (welches durch FensterObj referenziert wird) eben auf die Schliessung des Fensters mit dem Setzen seines closed-Flags.

Das Objekt existiert aber weiterhin, und man kann nach dem Schliessen z.B. vom Hauptfenster aus noch Variablen abfragen, die das Popup in seiner window-Variablen gespeichert hatte (zwecks Datenaustausch). Denn die window-Variable in dem Popup und die FensterObj-Variable im Hauptfenster sind beides nur Refernzen auf *ein und dasselbe* Speicherobjekt. (Siehe auch <../../sfarchiv/2000_1/t10312.htm#a51977>.)

Beim NS allerdings nicht, da FensterObj immer noch existiert, wenn es einmal geöffnet und wieder geschlossen wurde. Die Methode FensterObj.close gibts bei geschlossenen Fenstern (die als Objekt noch irgendwo in den Unsichtbaren Regionen des Netscape herumschwirren) aber nicht mehr.
Also kann man die Abfrage window.FensterObj weglassen (nicht aber die FensterObj.close)

Nun ja, je nach Programmierung sollte man auch FensterObj pruefen, denn wenn Closer() schon aufgerufen wird, wenn noch gar kein Fenster geoeffnet wurde, ist FensterObj unter Umstaenden noch undefined. Und auf close pruefen halte ich fuer, na sagen mir mal seltsam, denn eigentlich sollte es die Methode weiterhin geben, auch wenn das Fenster schon geschlossen ist. Ich bevorzuge jedenfalls die Abfrage auf closed:

if (window.FensterObj && !window.FensterObj.closed) FensterObj.close();

Calocybe

[brand]

Hi!

so klingt's irgendwie logisch.

mfg
BRAND