Hallo Gast,

Um einen Fehler zu finden, ist es extrem hilfreich, wirklich alle Informationen zu haben und insbesondere nicht vorausgewählte Informationen oder eigene Beobachtungen von einem Anfänger zu bekommen. ("Anfänger" ist nicht abwertend gemeint.)
Deine Fehlerbeschreibung war von Anfang an sehr diffus und es hat sehr lange gedauert, bis man überhaupt mal auch nur ein bisschen HTML-Quelltext von Dir erhalten hat. Ich habe mir die Mühe gemacht, den Thread durchzulesen und kann auch nicht nachvollziehen, was nun genau Dein Problem ist. Vielleicht auch, weil eine der von Dir verlinkten Seiten überhaupt nicht mehr erreichbar ist.
Vielleicht hätte Struppi pädagogisch geschickter kommunizieren und besser damit umgehen zu können, dass seine Herangehensweise an das Problem (erstmal alle Information haben zu wollen, statt sich mit dem spekulieren über Browserverhalten abzugeben), Dir nicht nachvollziehbar ist. Aber verlangen kann man das kaum. Er hat sich ohnehin schon viel Mühe gegeben, bei der Informationslage im Ausgangsposting hätte ich selbst kaum geantwortet und es hat ja auch kaum jemand getan.

Du hast sicher recht damit, dass ein Fehler im HTML-Code liegen muss, wenn er auch bei einer normalen HTML-Datei auftritt. Struppi konnten das Problem mit diesem (fehlerhaften) Quelltext anscheinend nicht nachvollziehen, konnte also nichts weiter machen, als weitere Information zu fordern.

Grüße

Daniel

Hehe,

Struppi ist mein Freund. Falls Du mit ihm ein Problem hast, schick ihm eMail.

Viele Grüße,
Hotte

TOFU: Klar. Da kannst Du dir den Scheiß nochmal angucken, den Du geschrieben hast :)

Hallo,
Betonung liegt auf "einige", i.a. finde ich das Forum sehr gut.
Aber wenn man (wie Struppi) immer wieder vom Fragenden klare Fehler-Beschreibungen und klare Antworten auf die Fragen fordert, so sollte dies auch umgekehrt gelten.

Um nur ein Beispiel zu nennen:

In dem Thread ab hier müsste dem letzten klar sein, dass der Fehler beim Aufruf der von mir ins Internet gestellten HTML-Datei nicht an Perl liegt. Trotzdem beharrt Struppi immer wieder darauf!

Meinen letzten Beitrag scheint er ja nun begriffen zu haben, denn darauf hüllte er sich in Schweigen.
Ich warte allerdings auch nicht mehr auf eine Lösung, mit dem sporadischen Fehler kann ich leben.

Meinen letzten Beitrag scheint er ja nun begriffen zu haben, denn darauf hüllte er sich in Schweigen.
Ich warte allerdings auch nicht mehr auf eine Lösung, mit dem sporadischen Fehler kann ich leben.

Wow.
Ich wollte zuerst, ohne den betreffenden Thread gelesen zu haben, andeuten, dass man als Fragesteller kooperieren sollte anstatt auf stur zu schalten, denn man will ja schliesslich was.

Dann wurde mir das aber zu bloed, sowas kann man nur ignorieren, hab ich mir gedacht.
Und jetzt sehe ich da EINUNDZWANZIG Antworten, daher die Frage:
Was bringt es sich, auf sowas (nicht die gebetene Information liefern und dann auch noch frech werden) zu antworten?

g johannes

Ich mische mich zur späten stunde ein.

Ich lese diese Feststelung in deinem ursprünglichen Thread:
https://forum.selfhtml.org/?t=180705&m=1194287
Der eindeutig besagt: HTML vollständig vorhanden, jedoch bringt MSIE einen Renderfehler.

Im weiteren Thread wird auch diese Schlüsselerfahrung nicht weiter eingegangen.

So. Wir sind alles Menschen und suchen den verlorenen Schlüssel unter der Laterne. Renderfehler im MSIE gehören aber zum Reich der Finsternis. Dass Probleme um Browserkompatibilitäten nicht gerade zu den Lieblingsthemen hier gehören, ist eine Tatsache. Sie erfordern zuviel praktischen Nachvollzug.

Nun kann der Renderfehler zwar verursacht sein, was am Schluss irgendwie fehlt (fehlende </body></html> ). Es kann aber auch ein Problem mit dem Reload von CSS sein, etc...

In die Problemanalyse kamen dann folgende widrige Umstände:
Das fragliche Dokument enthielt provate Daten.
Es gab also keinen Testcase. Das ist also recht viel Aufmunterung, unter einer anderen Laterne zu suchen.

Struppi fragt also nach der Errorlog.
Hier sagst du:
https://forum.selfhtml.org/?t=180705&m=1195223
Die Errorlog steht dir nicht zur Verfügung.

An dieser Stelle hätte jetzt der Fachmann eingreifen müssen, um erst mal diesen Mangel zu beheben.

Perlfehler können IMMER in eine lokale Datei umgeleitet werden, die dem Script-Autoren erreichbar ist.
Hier ist der Code:

  
#!C:/Programme/Perl/bin/perl.exe -w  
#  
use strict;  
  
BEGIN {  
 use CGI::Carp qw(carpout);  
 open(LOG, ">>error.txt")  or  die "Unable to append to error.txt: $!\n";  
 carpout(*LOG);  
}  

Und hier beginnt nun mein Senf.
Gibt es Probleme, sollte man sich zuerst mit Analyse-Tools eindecken. Ohne diese sucht man ewig im Dunkeln.

Habe ich an diesem Punkt etwas falsch verstanden, dann habe ich wohl die Mitteilungen im ursprünglichen Thread falsch aufgefasst. Das ist möglich. Aber man tut, was man kann.

Struppi hat nun verpasst, dich auf dies aufmerksam zu machen. Aber das hätte dich wohl mehr genervt, als alles andere.

Wen dem nun so ist, dann sage ich:
Happy Debugging.

mfg Beat

Moin,

Aber wenn man (wie XYZ) immer wieder vom Fragenden klare Fehler-Beschreibungen und klare Antworten auf die Fragen fordert, so sollte dies auch umgekehrt gelten.

XYZ redet _mit_ dem Fragenden, das "Gast" redest _über_ ihn. Angesichts dieses gewaltigen kommunikativen Niveauunterschieds erübrigt sich für mich die Frage, ob das, was das "Gast" sagt, in der Sache zutreffen könnte. Schlechte Kommunikationsfähigkeiten, mangelnde Empathie und steinzeitpädagogisches Gehabe (also Dinge, die ich an dem einen oder anderen Stammposter hier bekritteln könnte / kritisiert habe) sind mir immer noch lieber als korinthenkackende Heckenschützen ohne Arsch in der Hose.

Grüße

Swen