wie erkennen, wenn Browserfenster geschlossen wird?

[André Mantz]

Hallo,

ich habe eine Problemstellung die es erfordert, das ein Perl-Script erkennen soll ob der Anwender seinen Browser beendet hat.

Genauer: der Anwender ruft das Script auf. Dieses soll nun an einem bestimmten Punkt erkennen, ob der Anwender mittlerweile seinen Browser beendet oder aber eine andere Internetseite aufgerufen hat. Dabei soll ganz bewußt KEIN JavaScript (onUnload) zum Einsatz kommen.

Geht sowas überhaupt?

Ich hab das mal ganz naiv mit

print "text" || &meinesub();

probiert, in der Hoffnung das eine Sub aufgerufen wird, wenn der Print-Befehl nicht ausgeführt werden kann. So simpel geht´s aber nicht *örx*

btw. ... das Perl-Script läuft auf einem WinXP-Rechner mit MS IIS auf dem ich Admin-Rechte habe ... falls dort etwas eingestellt werden muß.

Danke für eure Hilfe.

Gruß, André

[Liza]

Hallo,

Perl läuft serverseitig. Der Browser ist beim Client :-)

Wenn man also mit dem Browser eine Seite aufruft, die am Server ein serverseitges Script startet, läuft das Script einfach mal los. Schließt der User nun seinen Browser, läuft das Script immer noch, da dieses ja nicht weiß, was beim Client passiert, es sei denn, dass dieser dem Script Bescheid gibt. Da dies automatisch geschehen müsste, kommt nur ein clientseitiges Script in Frage. Da JS ausgeschlossen sein soll, bietet sich VBS an. Das funktioniert aber nur auf'm IE und ist dort genauso abschaltbar, wie JS.

Also: ich würd tippen, es klappt nicht.

Ciao
Liza

P.S.: Ich beherrsche allerdings kein Perl, sondern nur PHP. Dort ist die prinzipielle Überlegung aber die selbe.

[André Mantz]

Hallo Liza,

Also: ich würd tippen, es klappt nicht.

Und es klappt doch ... bin gerade selbst drauf gekommen. Folgende Anweisung löst das Problem:

syswrite(STDOUT," ") || &meinesub();

Mit dem Befehl syswrite schicke ich ein Leerzeichen an den aufrufenden Browser (Standard-Ausgabe). Syswrite gibt tatsächlich einen Fehler zurück, falls der Browser die Seite nicht mehr offen hat oder selbst nicht mehr offen ist. Diesen Fehler fange ich dann ab und verzweige in meinem Script entsprechend.

P.S.: Ich beherrsche allerdings kein Perl, sondern nur PHP. Dort ist die prinzipielle Überlegung aber die selbe.

Ob das in PHP auch geht weiß ich nicht. Da aber PHP und Perl eng verwandt sind denke ich, dass es auch in Perl einen entsprechenden Befehl gibt, mit dem man systemnahe Ausgaben machen kann.

Noch was zur Lösung mit clientseitigen Scripts: egal ob mit JS, VBS oder sonstwas realisiert haben diese Lösungen immer zwei Haken:
1. der Browser muß die entspr. Scriptsprache unterstützen und diese auch aktiviert haben, sonst geht gar nix.
2. das clientseitige Script wird nicht ausgeführt, falls der Browser oder sogar der PC des Users abstürzt.

Gruß, André

[Lude]

Hi,

[...]
Und es klappt doch ... bin gerade selbst drauf gekommen. Folgende Anweisung löst das Problem:

syswrite(STDOUT," ") || &meinesub();
[...]

also, ohne genau Dich verstanden zu haben, aber ich denke Du moechtest wissen, ob der Client noch "da" ist; also mit dieser Einschraenkung ein paar Saetze.

Loesungsansatz 1) Du laesst den Client pullen ("refresh"). Geht nicht immer, aber "so what"? Scheint doch OK zu sein.
Loesungsansatz 2) Du laesst den Server pushen ("versteckter frame oder so?"). Zwar kein Kandidat fuer den Schoenheitspreis, aber "so what"? Allerdings muesstest Du dann einen permanent auf dem Server laufenden Prozess (mit entsprechender Datenhaltung) am Start haben.

Habe ich Dich (teilweise ;-) richtig verstanden?

Gruss,
Lude

[André Mantz]

Hallo Lude,

[...]
Und es klappt doch ... bin gerade selbst drauf gekommen. Folgende Anweisung löst das Problem:

syswrite(STDOUT," ") || &meinesub();
[...]

also, ohne genau Dich verstanden zu haben, aber ich denke Du moechtest wissen, ob der Client noch "da" ist; also mit dieser Einschraenkung ein paar Saetze.

Loesungsansatz 1) Du laesst den Client pullen ("refresh"). Geht nicht immer, aber "so what"? Scheint doch OK zu sein.
Loesungsansatz 2) Du laesst den Server pushen ("versteckter frame oder so?"). Zwar kein Kandidat fuer den Schoenheitspreis, aber "so what"? Allerdings muesstest Du dann einen permanent auf dem Server laufenden Prozess (mit entsprechender Datenhaltung) am Start haben.

Habe ich Dich (teilweise ;-) richtig verstanden?

Jetzt verstehe ich dich nicht ganz. Ich verwende für die Lösung weder einen refresh vom Client aus noch irgendwelche versteckten Frames.
Ich lasse das Script einfach mittels syswrite ein Leerzeichen an STDOUT ausgeben und fange ab, ob da ein Fehler zurückkommt.

Gruß, André

[Struppi]

syswrite(STDOUT," ") || &meinesub();

Ach, das '&' Zeichen ist Perl4 syntax und sollte nur verwendet werden wenn du weißt warum, weil es eine Spezielle Bedeutung hat (du gibst soweit ich weiß  damit automatisch @_ an die Sub weiter) .

Ich lasse das Script einfach mittels syswrite ein Leerzeichen an STDOUT ausgeben und fange ab, ob da ein Fehler zurückkommt.

wenn dem so wäre lasse dir auch mal die Fehlermeldung ausgeben:

syswrite(STDOUT, " ") || die "Der Fehler ist: $!";

Struppi.

[André Mantz]

Hallo Struppi

[...]
wenn dem so wäre lasse dir auch mal die Fehlermeldung ausgeben:

syswrite(STDOUT, " ") || die "Der Fehler ist: $!";
[...]

öhm ... da kommt doch tatsächlich als Fehler "invalid argument". Komisch ist es in sofern, als es für meinen Zweck funktioniert ... sehr seltsam. Liegt vielleicht daran, dass das Script auf WinXP mit IIS läuft ;-)

Gruß, André

[Christian Kruse]

Hallo Struppi,

syswrite(STDOUT," ") || &meinesub();

Ach, das '&' Zeichen ist Perl4 syntax und sollte nur verwendet
werden wenn du weißt warum, weil es eine Spezielle Bedeutung hat
(du gibst soweit ich weiß  damit automatisch @_ an die Sub weiter) .

Das hängt vom Kontext ab.

blahr;       # @_ in sub ist leer
&blahr;      # @_ in sub ist @_ im Kontext
blahr();     # @_ ist leer
&blahr();    # @_ ist leer

Grüße,
 CK

[Struppi]

Also: ich würd tippen, es klappt nicht.

Und es klappt doch ... bin gerade selbst drauf gekommen. Folgende Anweisung löst das Problem:

syswrite(STDOUT," ") || &meinesub();

Mit dem Befehl syswrite schicke ich ein Leerzeichen an den aufrufenden Browser (Standard-Ausgabe). Syswrite gibt tatsächlich einen Fehler zurück, falls der Browser die Seite nicht mehr offen hat oder selbst nicht mehr offen ist. Diesen Fehler fange ich dann ab und verzweige in meinem Script entsprechend.

Das ist völliger Quatsch.
Perl schreibt ein Leerzeichen an STDOUT, das kann die Konsole sein (DOS Box unter Windows) oder bei einer CGI Anwendung ist es der Server der das Leerzeichen entgegen nimmt und dan den Empfänger weiterleitet. Wenn der Empfänger nicht mehr existiert (der Empfänger ist aber nicht der Browser, sondern die IP Nummer, die die Anfrage ausgelöst hat) bekommst du nie eine Rückmeldung und Perl schon gar nicht, da das Programm i.d.R. schon lange beendet ist.

Falls in dem obigen Falle wirklich ein Fehler auftritt, dann ist irgendwas anderes bei dir kaputt.

Struppi.

[Christian Kruse]

Hallo André,

bei dem hahnebüchenden Unsinn, der hier verbrochen wurde, muss ich
doch mal antworten.

ich habe eine Problemstellung die es erfordert, das ein Perl-Script
erkennen soll ob der Anwender seinen Browser beendet hat.

Das ist nicht möglich. Du kannst höchstens erkennen, dass der
Webserver eines der beiden Dinge versucht: entweder, ein Filehandle
zu schließen oder, alternativ, ein Signal schickt, wobei Ersteres
meist mit Zweiterem einher geht. Die Gründe hierfür können absolut
unterschiedlich sein: Browserfenster geschlossen, Laden abgebrochen
(in dem Fall das gleiche), Verbindungs-Timeout, CGI-Timeout, etc, pp.

Genauer: der Anwender ruft das Script auf. Dieses soll nun an einem
bestimmten Punkt erkennen, ob der Anwender mittlerweile seinen
Browser beendet oder aber eine andere Internetseite aufgerufen hat.
Dabei soll ganz bewußt KEIN JavaScript (onUnload) zum Einsatz
kommen.

Das ist nicht möglich.

Geht sowas überhaupt?

Nein.
Was du tun kannst, ist folgendes: setze einen Signal-Handler für
SIGTERM, in dem du deine Aufräumaktionen machst. Weiterhin prüfe, ob
du etwas ausgeben kannst. Die Methode allerdings, die du machen
willst, ist nur dann sinnvoll, wenn du befürchtest, mitten in der
Ausgabe abgebrochen zu werden. Die von Struppi angepriesene Methode
ist *absoluter* Humbug, bitte setze sie nicht ein. Sie verschwendet
Systemresourcen (CPU-Auslastung in so einer print while 1;-Schleife
ist 100%) und verschwendet Bandbreite (das ist so ähnlich wie ein
ping -f, man schickt damit so viele Daten wie eben möglich an den
Client. Man nagelt ihn absolut zu damit). Als Provider würde ich dir
kündigen. Stattdessen mach das so:

my $do_run = 1;
while($do_run) {
  my $ebits;
  vec($ebits,fileno(STDOUT),1);

my ($nfound,$timeleft) = select(undef,undef,$ebits,.75);
  if($nfound == 1) {
    $do_run = 0;
  }
}

aufraeumen();

Ich hab das mal ganz naiv mit

print "text" || &meinesub();

probiert,

Wenn schon, dann bitte

print "text" or &meinesub();

Der Unterschied zwischen || und or ist die Präferenz.

print "text" || &meinesub();

ist das gleiche wie

print("text" || &meinesub());

während

print "text" or &meinesub();

das gleiche wie

print("text") or &meinesub();

ist.

in der Hoffnung das eine Sub aufgerufen wird, wenn der Print-Befehl
nicht ausgeführt werden kann.

Völlig korrekt, wenn du annimmst, dass du Probleme kriegen könntest,
wenn STDOUT während des Schreibens geschlossen wird. Wann das
passiert, habe ich ja oben beschrieben.

Vergiss aber in keinem Fall, den SIGTERM-Handler zu setzen! Sonst
wird das Script in einem solchen Fall stupide beendet.

btw. ... das Perl-Script läuft auf einem WinXP-Rechner mit MS IIS
auf dem ich Admin-Rechte habe ... falls dort etwas eingestellt
werden muß.

Inwiefern das unter Windows anders ist, kann ich dir nicht sagen. Ich
vermute aber, es wird dort ähnlich sein.

Grüße,
 CK

[Christian Kruse]

Hallo nochmal,

[...] Die von Struppi angepriesene Methode ist *absoluter* Humbug,

Oh, Verzeihung. Die Methode kam von dir selbst, nicht von Struppi.

Grüße,
 CK

[Struppi]

[...] Die von Struppi angepriesene Methode ist *absoluter* Humbug,

Oh, Verzeihung. Die Methode kam von dir selbst, nicht von Struppi.

ich wolte mich grad beschweren.

und das '&' vor den Funktionsaufruf sollte trotzdem weg.

Struppi.

[Christian Kruse]

Hallo Struppi,

und das '&' vor den Funktionsaufruf sollte trotzdem weg.

Kannst du mir einen sachlichen Grund dafür nennen?

Grüße,
 CK

[Struppi]

Hallo Christian

und das '&' vor den Funktionsaufruf sollte trotzdem weg.

Kannst du mir einen sachlichen Grund dafür nennen?

Weil's in diesem Falle überflüssig ist (mit KLammern) und im anderen eine Bedeutung hat die oft nicht gewünscht wird.

Struppi.

[Christian Kruse]

Hallo Struppi,

und das '&' vor den Funktionsaufruf sollte trotzdem weg.

Kannst du mir einen sachlichen Grund dafür nennen?

Weil's in diesem Falle überflüssig ist (mit KLammern) und im anderen
eine Bedeutung hat die oft nicht gewünscht wird.

Mit anderen Worten: du kannst mir keinen nennen. Ob etwas gewünscht
oder unerwünscht ist, entscheide ich als Autor des Codes. Genauso wie
ich entscheide, ob ein Zeichen überflüssig ist oder nicht.

Du kannst ja überlegen, ob du deine Behauptung abschwächen willst
in 'Das &-Zeichen ist uU gefährlich für Anfänger'. In dem Fall würde
ich dir zustimmen.

Grüße,
 CK

[Struppi]

Weil's in diesem Falle überflüssig ist (mit KLammern) und im anderen
eine Bedeutung hat die oft nicht gewünscht wird.

Mit anderen Worten: du kannst mir keinen nennen. Ob etwas gewünscht
oder unerwünscht ist, entscheide ich als Autor des Codes. Genauso wie
ich entscheide, ob ein Zeichen überflüssig ist oder nicht.

Naja, ein überflüssiges Zeichen, das unter Umständen eine andere Bedeutung hat als gewünscht nicht zu halte ich für einen Grund.

Und da ich keine Probleme habe auch zuzugeben wenn ich nicht alles weiss, habe ich mal ein wenig recherchiert, da ich zugegebenweise, diese Aussage nur übernommen hatte aber nciht mehr den wirklichen grund wußte.

Also der Funktionsaufruf &function(param1, param2); umgeht außerdem deine Prototypen, was mit Sicherheit nicht gewünscht ist. Sofern man Prototypen verwendet.

Es gibt also keinen Grund Perl 4 Syntax zu verwenden, auch wenn sie in 99,9% der Fällen das gleiche macht wie die neue Schreibweise.

Perlsub sagt dazu:
Not only does the & form make the argument list optional, it also disables any prototype checking on arguments you do provide. This is partly for historical reasons, and partly for having a convenient way to cheat if you know what you're doing. See Prototypes below.

also, '&' nur benutzen wenn man weiss was man tut.

und wieso werd ich dass Gefühl nicht los, dass dir irgendwas an meinen Aussagen nicht paßt?
erst versuchst du mich hier anzukacken und jetzt eine Grundsatzdiskusyion loszutreten, die dem Frager nicht hilft. Während mein Tipp durchaus seine Berechtigung hatte.

Struppi.

[Christian Kruse]

Hallo Struppi,

Weil's in diesem Falle überflüssig ist (mit KLammern) und im
anderen eine Bedeutung hat die oft nicht gewünscht wird.

Mit anderen Worten: du kannst mir keinen nennen. Ob etwas
gewünscht oder unerwünscht ist, entscheide ich als Autor des
Codes. Genauso wie ich entscheide, ob ein Zeichen überflüssig ist
oder nicht.

Naja, ein überflüssiges Zeichen, das unter Umständen eine andere
Bedeutung hat als gewünscht nicht zu halte ich für einen Grund.

Hae? Der Satz kein Deutsch. Meintest du vielleicht 'Naja, ein
überflüssiges Zeichen, das unter Umständen eine andere Bedeutung hat
als gewünscht halte ich für einen Grund'? Nun, in dem Fall kann ich
mich nur wiederholen. Das ist kein Grund. Ich kann durchaus
einschätzen, wann das & welche Funktion hat.

Also der Funktionsaufruf &function(param1, param2); umgeht außerdem
deine Prototypen,

Richtig, das hatte ich vergessen. Übrigens wird von Prototypen
abgeraten, da sie buggy sind:

http://www.perl.com/pub/a/language/misc/fmproto.html

Es gibt also keinen Grund Perl 4 Syntax zu verwenden, auch wenn sie
in 99,9% der Fällen das gleiche macht wie die neue Schreibweise.

Es gibt genau so wenig einen triftigen Grund dagegen.

und wieso werd ich dass Gefühl nicht los, dass dir irgendwas an
meinen Aussagen nicht paßt?

Das Gefühl stimmt. Ich hasse es, wenn mir einer vorzuschreiben
versucht, wie ich meinen Code zu schreiben habe und mir dafür
nichtmal Gründe liefern kann. Nimm das Absolutistische aus deinen
Aussagen und begründe sie, und ich kann damit leben. Statt 'Das &
muss trotzdem weg!' (sinngemäß) lieber ein 'Das & sollte man
weglassen, weil ...'.

erst versuchst du mich hier anzukacken

Ehm? Hab ich was verpasst?

und jetzt eine Grundsatzdiskusyion loszutreten, die dem Frager
nicht hilft.

Meine Intention ist es nicht immer, dem OP zu helfen. Wem sonst,
kannst du ja mal drüber nachdenken. Wenn du mal Vorträge oder Artikel
verfassen solltest, wirst du Aussagen nicht Argumentlos stehen lassen
können. Gewöhne dir doch einfach an, sauber zu recherchieren, warum
etwas boehze[tm] ist und formuliere vorsichtiger. Ich ballere ja auch
nicht rum 'nein, das ist Kacke, mach das so!', sondern ich begründe
meine Kritik an Lösungswegen oder stilistischen Mängeln. Sollte ich
das btw. doch mal tun, weise mich bitte genau so darauf hin, wie ich
es bei dir getan habe.

Übrigens verwende auch ich keine & vor den Subs. Nur um dir
klarzumachen, dass es hier nicht um deine Person geht.

Grüße,
 CK

[Struppi]

Weil's in diesem Falle überflüssig ist (mit KLammern) und im
anderen eine Bedeutung hat die oft nicht gewünscht wird.

Mit anderen Worten: du kannst mir keinen nennen. Ob etwas
gewünscht oder unerwünscht ist, entscheide ich als Autor des
Codes. Genauso wie ich entscheide, ob ein Zeichen überflüssig ist
oder nicht.

Naja, ein überflüssiges Zeichen, das unter Umständen eine andere
Bedeutung hat als gewünscht nicht zu halte ich für einen Grund.

Hae? Der Satz kein Deutsch. Meintest du vielleicht 'Naja, ein

Das stimmt manchmal vertippe ich mich. Und manchmal lese ich auch nicht gründlich drüber.

Das sollte heißen:
Naja, ein überflüssiges Zeichen, das unter Umständen eine andere Bedeutung hat als gewünscht nicht zu verwenden, halte ich für einen Grund [von dessen Verwendung abzuraten].

mich nur wiederholen. Das ist kein Grund. Ich kann durchaus
einschätzen, wann das & welche Funktion hat.

du hast jemanden geantwortet der es mit Sicherheit nicht weiss.

Es gibt also keinen Grund Perl 4 Syntax zu verwenden, auch wenn sie
in 99,9% der Fällen das gleiche macht wie die neue Schreibweise.

Es gibt genau so wenig einen triftigen Grund dagegen.

Dann sage mir einen warum es jemand der keine Ahnung hat verwendet soll?
Es gibt lediglich einen, in deinen Augen belanglosen, Grund es nicht zu tun. Aber nicht einen einzigen es zu verwenden, ausser das es mehr Arbeit ist, was in meinen Augen ein Grund ist es nicht zu verwenden.

und wieso werd ich dass Gefühl nicht los, dass dir irgendwas an
meinen Aussagen nicht paßt?

Das Gefühl stimmt. Ich hasse es, wenn mir einer vorzuschreiben
versucht, wie ich meinen Code zu schreiben habe und mir dafür
nichtmal Gründe liefern kann. Nimm das Absolutistische aus deinen
Aussagen und begründe sie, und ich kann damit leben. Statt 'Das &
muss trotzdem weg!' (sinngemäß) lieber ein 'Das & sollte man
weglassen, weil ...'.

ich schrieb 'sollte' und das nachdem du schriebst:"...Die von Struppi angepriesene Methode
ist *absoluter* Humbug, "

war das ein kleine nicht mal bösartige Revanche die so wie ich sie formuliert habe nicht mal gegen dich gerichtet war, sondern lediglich als nochmaligen Hinweis an den OP gerichtet sein sollte.

erst versuchst du mich hier anzukacken

Ehm? Hab ich was verpasst?

Naja, ohne genau gelesen zu haben wer was schrieb, setzt du dich hin und behauptest ich würde Humbug erzählen.

und jetzt eine Grundsatzdiskusyion loszutreten, die dem Frager
nicht hilft.

Meine Intention ist es nicht immer, dem OP zu helfen. Wem sonst,
kannst du ja mal drüber nachdenken. Wenn du mal Vorträge oder Artikel
verfassen solltest, wirst du Aussagen nicht Argumentlos stehen lassen
können. Gewöhne dir doch einfach an, sauber zu recherchieren, warum

Das ist aber genau was du tust. Während du steif und fest behauptest es ist egal (was es wahrscheinlich in den meisten Fällen ist), habe ich recherchiert und dir gezeigt wann es nicht egal ist, daneben ist  auch überflüssig, selbst das halte ich für einen trifftigen Grund.

etwas boehze[tm] ist und formuliere vorsichtiger. Ich ballere ja auch
nicht rum 'nein, das ist Kacke, mach das so!', sondern ich begründe

Ich habe nie geschrieben das etwas böse ist, sondern, das man es nicht verwenden sollte, wen man nicht weiß warum.
Auch habe ich nicht Ansatzweise geschrieben irgendwas ist Kacke, im gegensatz zu dir, sondern - ich wiederhole mich - ich habe geschrieben 'man sollte nicht'

meine Kritik an Lösungswegen oder stilistischen Mängeln. Sollte ich
das btw. doch mal tun, weise mich bitte genau so darauf hin, wie ich
es bei dir getan habe.

Ich wollte dich lediglich darauf Hinweisen, dass es sicher keine kluge Sache ist jemand der nicht weiss was das '&' vor Funktionsaufurfen tut, deren Verwendung zu empfehlen, in dem du, als vermeintlich Wissender, dieses in einem Lösungsvorschlag verwendest.

Und diesen Hinweis hatte ich in einem völlig normalen Satz in keinsterweise scharf, angreifend oder sonst einer Art und Weise gegen dich persönlich gerichtet verwendet.

Insofern verstehe ich nicht warum du dich hier so aufregst als ob ich dich beleidigen wollte.

Übrigens verwende auch ich keine & vor den Subs. Nur um dir
klarzumachen, dass es hier nicht um deine Person geht.

Was hat das eine mit dem anderen zu tun, wegen mir kannst du soviele überflüssige '&' verwenden wie du willst. Aber es macht aus den von mir genannten Gründen weder Sinn, aber da du ja auch keine Prototypen verwendest (ich auch nicht), sollte es auch nicht Schaden. Es wäre deine Mehrarbeit.

Struppi.

[Christian Kruse]

Hallo Struppi,

mich nur wiederholen. Das ist kein Grund. Ich kann durchaus
einschätzen, wann das & welche Funktion hat.

du hast jemanden geantwortet der es mit Sicherheit nicht weiss.

Aha! Und da haben wir den Salat. Wie gesagt, wenn du schreibst 'Das &
ist für Anfänger gefährlich, weil ...' ist die Aussage absolut
einsehbar und korrekt.

Es gibt also keinen Grund Perl 4 Syntax zu verwenden, auch wenn
sie in 99,9% der Fällen das gleiche macht wie die neue
Schreibweise.

Es gibt genau so wenig einen triftigen Grund dagegen.

Dann sage mir einen warum es jemand der keine Ahnung hat verwendet
soll?

Habe ich nicht gesagt. Aber so, wie du es formuliert hast, möchtest
du *allen*, auch denen, die es besser wissen, davon abraten, es zu
verwenden.

und wieso werd ich dass Gefühl nicht los, dass dir irgendwas an
meinen Aussagen nicht paßt?

Das Gefühl stimmt. Ich hasse es, wenn mir einer vorzuschreiben
versucht, wie ich meinen Code zu schreiben habe und mir dafür
nichtmal Gründe liefern kann. Nimm das Absolutistische aus deinen
Aussagen und begründe sie, und ich kann damit leben. Statt 'Das &
muss trotzdem weg!' (sinngemäß) lieber ein 'Das & sollte man
weglassen, weil ...'.

ich schrieb 'sollte' und das nachdem du schriebst:"...Die von
Struppi angepriesene Methode ist *absoluter* Humbug, "

Ja.

war das ein kleine nicht mal bösartige Revanche die so wie ich sie
formuliert habe nicht mal gegen dich gerichtet war, sondern
lediglich als nochmaligen Hinweis an den OP gerichtet sein sollte.

Dann formuliere das auch so! ;) Ich hoffe, du verstehst jetzt, worauf
ich hinaus will.

erst versuchst du mich hier anzukacken

Ehm? Hab ich was verpasst?

Naja, ohne genau gelesen zu haben wer was schrieb, setzt du dich
hin und behauptest ich würde Humbug erzählen.

Nein. Ich habe lediglich die Namen verwechselt. Deshalb habe ich ja
auch direkt darauf mich verbessert.

und jetzt eine Grundsatzdiskusyion loszutreten, die dem Frager
nicht hilft.

Meine Intention ist es nicht immer, dem OP zu helfen. Wem sonst,
kannst du ja mal drüber nachdenken. Wenn du mal Vorträge oder
Artikel verfassen solltest, wirst du Aussagen nicht Argumentlos
stehen lassen können. Gewöhne dir doch einfach an, sauber zu
recherchieren, warum

Das ist aber genau was du tust.

Nein. Ich versuche eine saubere Formulierung aus dir herauszukitzeln.

Während du steif und fest behauptest es ist egal (was es
wahrscheinlich in den meisten Fällen ist),

Ich sage, es ist zu absolut formuliert.

habe ich recherchiert und dir gezeigt wann es nicht egal ist,
daneben ist  auch überflüssig, selbst das halte ich für einen
trifftigen Grund.

Ja, aber das hast du erst geliefert als ich nachgehakt habe ;) Und
darum ging es mir ja.

etwas boehze[tm] ist und formuliere vorsichtiger. Ich ballere ja
auch nicht rum 'nein, das ist Kacke, mach das so!', sondern ich
begründe

Ich habe nie geschrieben das etwas böse ist,

Nicht wörtlich, nein.

sondern, das man es nicht verwenden sollte, wen man nicht weiß
warum.

Das hast du eben nicht. Deine Aussage war viel absoluter.

meine Kritik an Lösungswegen oder stilistischen Mängeln. Sollte
ich das btw. doch mal tun, weise mich bitte genau so darauf hin,
wie ich es bei dir getan habe.

Ich wollte dich lediglich darauf Hinweisen, dass es sicher keine
kluge Sache ist jemand der nicht weiss was das '&' vor
Funktionsaufurfen tut, deren Verwendung zu empfehlen, in dem du,
als vermeintlich Wissender, dieses in einem Lösungsvorschlag
verwendest.

Eine völlig korrekte Intention. Nur die Ausführung hat halt noch ein
wenig gehapert.

Und diesen Hinweis hatte ich in einem völlig normalen Satz in
keinsterweise scharf, angreifend oder sonst einer Art und Weise
gegen dich persönlich gerichtet verwendet.

Nein. Nur war es kein Hinweis.

Insofern verstehe ich nicht warum du dich hier so aufregst als ob
ich dich beleidigen wollte.

*g* keine Angst, ich rege mich nicht auf und ich fühle mich nicht
beleidigt. Ich möchte nur, dass du siehst, dass ungenaue und absolute
Aussagen nicht das Gelbe vom Ei sind.

Grüße,
 CK