nicht angemeldet
Breite von TD in Javascript: Warum mal definiert, mal 0?
StruppiHallo!
Seht euch mal das Beispiel unten an. Dort wird über iFrames das gleiche Dokument 25 mal angezeigt. In so einem Dokument ist eine Tabellenzelle, deren Breite ermittelt wird. Das Problem: Die Breite der Zellen wird in den letzten iFrames nicht mehr ermittelt, die Funktion wird aber schon noch aufgerufen. Mir ist aufgefallen, dass die Anzahl der Frames, deren Zellenbreite noch ermittelt wird, abhängig von der Höhe der Frames ist. Deshalb habe ich den auskommentierten focus-Befehl eingefügt, ich finde es aber nicht so schön, jedes Mal das ganze Document durchscrollen zu sehen, und würde lieber den eigentlichen Fehler finden.
Das braucht nur im InternetExplorer funktionieren und muss auf Frames und Tabellen basieren.
Hier der Inhalt von index.htm:
<html>
<body>
<iframe src="frame.htm" width="100%" height="100px"></iframe>
<iframe src="frame.htm" width="100%" height="100px"></iframe>
<iframe src="frame.htm" width="100%" height="100px"></iframe>
<iframe src="frame.htm" width="100%" height="100px"></iframe>
<iframe src="frame.htm" width="100%" height="100px"></iframe>
<iframe src="frame.htm" width="100%" height="100px"></iframe>
<iframe src="frame.htm" width="100%" height="100px"></iframe>
<iframe src="frame.htm" width="100%" height="100px"></iframe>
<iframe src="frame.htm" width="100%" height="100px"></iframe>
<iframe src="frame.htm" width="100%" height="100px"></iframe>
<iframe src="frame.htm" width="100%" height="100px"></iframe>
<iframe src="frame.htm" width="100%" height="100px"></iframe>
<iframe src="frame.htm" width="100%" height="100px"></iframe>
<iframe src="frame.htm" width="100%" height="100px"></iframe>
<iframe src="frame.htm" width="100%" height="100px"></iframe>
<iframe src="frame.htm" width="100%" height="100px"></iframe>
<iframe src="frame.htm" width="100%" height="100px"></iframe>
<iframe src="frame.htm" width="100%" height="100px"></iframe>
<iframe src="frame.htm" width="100%" height="100px"></iframe>
<iframe src="frame.htm" width="100%" height="100px"></iframe>
<iframe src="frame.htm" width="100%" height="100px"></iframe>
<iframe src="frame.htm" width="100%" height="100px"></iframe>
<iframe src="frame.htm" width="100%" height="100px"></iframe>
<iframe src="frame.htm" width="100%" height="100px"></iframe>
<iframe src="frame.htm" width="100%" height="100px"></iframe>
</body>
</html>
und frame.htm:
<html>
<head>
<script type="text/javascript">
function test()
{
//document.getElementById("Zelle").focus();
document.getElementById("Zelle").innerText = "Breite: " + document.getElementById("Zelle").offsetWidth;
}
</script>
</head>
<body onload="test()">
<table style="width: 640px; border: 1px black solid">
<tr>
<td id="Zelle"></td>
</tr>
</table>
</body>
</html>
danke,
dartrax
-
hallo,
Seht euch mal das Beispiel unten an. Dort wird über iFrames das gleiche Dokument 25 mal angezeigt.
Das kann doch nicht ganz dein Ernst sein - abgesehen davon, daß es nicht "das gleiche" Dokument ist, sondern tatsächlich "dasselbe". Zu welchem Zweck unternimmst du diese Übung?
Das Problem: Die Breite der Zellen wird in den letzten iFrames nicht mehr ermittelt, die Funktion wird aber schon noch aufgerufen.
Ich weiß nicht, was du hier unter "letzte iFrames" verstehst. Im Internet Explorer ist es mal der 20., mal der 11., mal der 17. iframe, der eine Anzeige "0" bringt, obwohl da "634" stehen sollte. Das ändert sich bei jedem Aufruf, wenn man zwischendurch den Cache leert. Opera hat dieses Problem nicht, und Firefox kann "innerText" nicht.
Mir ist aufgefallen, dass die Anzahl der Frames, deren Zellenbreite noch ermittelt wird, abhängig von der Höhe der Frames ist. Deshalb habe ich den auskommentierten focus-Befehl eingefügt
Den Focus dort festlegen zu wollen, wo du es jetzt stehen hast, ist eh widersinnig, weil er sich dann auf sämtlichen 25 geladenen Dokumenten wiederholen müßte. Wie und wodurch du diese Abhängigkeit bemerkt hast, ist für mich nicht nachvollziehbar.
ich [...] würde lieber den eigentlichen Fehler finden.
Gib deinen iFrames wenigstens Namen oder IDs oder vervielfältige die Seite "frame.htm" so, daß du eben 25 Seiten "frameX.htm" hast - das X steht für eine fortlaufende Zahl - die du dann in den jeweiligen Rahmen laden kannst.
Das braucht nur im InternetExplorer funktionieren und muss auf Frames und Tabellen basieren.
Eine Begründung dafür, daß es Frames und Tabellen sein müssen, wäre nett. "Nur im Internet Explorer funktionieren" mag gelten, wenn du das in einem Intranet einsetzen willst. Dann mußt du dich auch nicht auf die üblichen Hinweise, daß Frames eh doof sind, einlassen.
Grüße aus Berlin
Christoph S.
-
Das kann doch nicht ganz dein Ernst sein - abgesehen davon, daß es nicht "das gleiche" Dokument ist, sondern tatsächlich "dasselbe". Zu welchem Zweck unternimmst du diese Übung?
Es ist für ein Programm, an dem ich gerade arbeite. Die Dokumente enthalten natürlich einiges mehr, aber das würde alles unnötig verkomplizieren. Ich habe das "unsinnige" Beispiel gebaut, um mein Problem zu verdeutlichen.
Ich weiß nicht, was du hier unter "letzte iFrames" verstehst. Im Internet Explorer ist es mal der 20., mal der 11., mal der 17.
Bei mir ist es immer gleich, habe aber auch den Cache noch nicht gelehrt. Ist ja auch egal, soll bei allen funktionieren.
Den Focus dort festlegen zu wollen, wo du es jetzt stehen hast, ist eh widersinnig, weil er sich dann auf sämtlichen 25 geladenen Dokumenten wiederholen müßte. Wie und wodurch du diese Abhängigkeit bemerkt hast, ist für mich nicht nachvollziehbar.
Ich hatte vorher Frames mit einer Höhe von 100 px verwendet, dadurch waren weniger Frames beim Laden im Fenster sichtbar und weniger Zellbreiten wurden korrekt erkannt. Daher kam ich auf die Idee, mit focus() jedes Frame ins Fenster zu scrollen, und siehe da, es ging.
Gib deinen iFrames wenigstens Namen oder IDs oder vervielfältige die Seite "frame.htm" so, daß du eben 25 Seiten "frameX.htm" hast - das X steht für eine fortlaufende Zahl - die du dann in den jeweiligen Rahmen laden kannst.
Im Programm ist das genau so, wie du es vorschlägst. Der Fehler tritt trotzdem auf.
Eine Begründung dafür, daß es Frames und Tabellen sein müssen, wäre nett. "Nur im Internet Explorer funktionieren" mag gelten, wenn du das in einem Intranet einsetzen willst. Dann mußt du dich auch nicht auf die üblichen Hinweise, daß Frames eh doof sind, einlassen.
Ich werde es auch nicht im Intranet einsetzen, sondern wie bereits beschrieben in einem Programm. Dieses ruft die Seiten in einem internen Steuerelement auf, das auf dem Internet Explorer beruht. Kein anderer Browser wird die Dokumente jemals zu Gesicht bekommen, das verspreche ich dir. Frames müssen sein, damit alle Dokumente unabhängig voneinander ihre Javascriptfunktionen ausführen können, und trotzdem in einem Dokument angezeigt werden. Tabellen haben einen anderen Grund, dazu müsste ich ein umfangreicheres Beispiel posten, das tue ich erst, wenn weder ihr noch ich weiter weiß.
So, bitte keine weiteren Diskussionen um Sinn und Zweck, ich verstehe, dass das unter dem Aspekt Webdesign betrachtet sehr unsinnig ist.
dartrax
-
hallo,
Es ist für ein Programm, an dem ich gerade arbeite. Die Dokumente enthalten natürlich einiges mehr, aber das würde alles unnötig verkomplizieren. Ich habe das "unsinnige" Beispiel gebaut, um mein Problem zu verdeutlichen.
Eventuell geht dieses "unsinnige" Beispiel auch am Sinn deines Programms vorbei. Die Vermutung, daß du nur einen "dummy" beschreibst, der allenfalls als Strukturbeispiel für dein eigentliches Problem herhalten muß, lag ja sehr nahe. Und das ist generell nicht unbedingt ein "Fehler" - manchmal ist es allerdings sinnvoller, gleich bekanntzugeben, daß du ein "Programm" entwickelst, das eben unter anderem auch HTML ausgeben können soll.
Da muß man dann nämlich, wenn man dir antworten und einen Hinweis versuchen möchte, doch ein bißchen mehr tun als bloß einen Verweis aufs Forums-Archiv anzubringen oder dir entgegenzurülpsen, daß Frames doof sind. Nur hast du so eine Angabe im Originalposting versäumt.
"Programmausgaben" dürfen sehr vieles, was wir hier im Forum sonst sofort mit aller Gewalt mit einem absoluten "äks" belegen würden - da darf auch mal invalider Code drin sein. Hauptsache ist letzten Endes, daß dein "Programm" am Ende versteht, was es damit anfangen können soll. An dieser Stelle wird dann auch eine Forumsdiskussion unter Umständen sogar sehr interessant, weil "wir" dann gezwungen sind, alle "Standard-Antworten" auf den Müll zu werfen und nachzuschauen, was du denn eigentlich tun willst. Es gibt sicher ein paar Leute hier, die sich auf so eine "out-of-door"-Aufgabe mit großem Vergnügen und auch mit viel Ernsthaftigkeit stürzen würden. Nur solltest du das gleich von Anfang an zu erkennen geben. Der Grund, weshalb dir nahezu einen Tag lang keiner geantwortet hat (was für das Forum auch am Wochenende ein ungewöhnlich langer Zeitraum ist), lag wahrscheinlich auch darin, daß deine Fragestellung zunächst mal wie die eines absoluten newbies gelesen wurde - man macht halt sowas einfach nicht, 25 Frames mit der jeweils identischen URL zu befüllen, so doof kann ja eigentlich niemand sein.
Ich hatte vorher Frames mit einer Höhe von 100 px verwendet, dadurch waren weniger Frames beim Laden im Fenster sichtbar
Warum um alles in der Welt müssen Framesgrößenangaben nur immer in "px" stehen? Ist es nicht _wesentlich_ sinnvoller, eine Maßeinheit zu wählen, die skalieren kann - also zum Beispiel em oder %?
Gib deinen iFrames wenigstens Namen oder IDs oder vervielfältige die Seite "frame.htm" so, daß du eben 25 Seiten "frameX.htm" hast
Im Programm ist das genau so, wie du es vorschlägst.Das kan ich ja nicht wissen ;-)
Der Fehler tritt trotzdem auf.
Ich bestreite nicht, daß das ein "Fehler" ist. Er ist ja reproduzierbar (wenn auch ausschließlich im IE), wenn auch nicht mit immer gleichem Ergebnis. Daraus läßt sich eher schließen, daß der IE irgendwelche Probleme mit deiner bisherigen Konstruktion hat, die sich vermutlich mit einer Korrektur des HTML-Codes allein nicht lösen lassen werden.
"Nur im Internet Explorer funktionieren" mag gelten, wenn du das in einem Intranet einsetzen willst.
Ich werde es auch nicht im Intranet einsetzen, sondern wie bereits beschrieben in einem ProgrammDas entspricht aber ungefähr den Bedingungen eines "Intranet" - das heißt, es mögen da Dinge erlaubt sein (oder erlaubt scheinen), gegen die "wir" im Internet nahezu geschlossen zu Felde ziehen würden.
So, bitte keine weiteren Diskussionen um Sinn und Zweck, ich verstehe, dass das unter dem Aspekt Webdesign betrachtet sehr unsinnig ist.
Ok, einverstanden - jedenfalls soweit es um "Webdesign" geht. Aber sobald es um "Programmiertechnik" geht, muß man über Sinn und Zewck sowie über die Frage, ob denn die richtigen Strukturierungsmodelle für eine Browserdarstellung gewählt wurden, sehr wohl noch ein bißchen debattieren.
Ich wäre ja ganz glücklich, wenn ich dir jetzt zwei oder drei Zeilen Code vor die Nase schmeißen könnte und dein Problem damit gelöst wäre. So gehts aber leider nicht. Du hast möglicherweise dein Problem selbst noch nicht verstanden, und ich (und vermutlich etliche Leser deiner Anfrage auch) habe noch nicht ganz verstanden, worin dein Problem eigentlich begründet ist. Die "Energie des Verstehens" ist also vorläufig noch auf der Strecke geblieben ...
Grüße aus Berlin
Christoph S.
-
Da muß man dann nämlich, wenn man dir antworten und einen Hinweis versuchen möchte, doch ein bißchen mehr tun als bloß einen Verweis aufs Forums-Archiv anzubringen oder dir entgegenzurülpsen, daß Frames doof sind. Nur hast du so eine Angabe im Originalposting versäumt.
Ok, überzeugt. Mein Fehler.
Warum um alles in der Welt müssen Framesgrößenangaben nur immer in "px" stehen? Ist es nicht _wesentlich_ sinnvoller, eine Maßeinheit zu wählen, die skalieren kann - also zum Beispiel em oder %?
Es war doch nur zum ausproobiieerreeennn! Na gut, ich gestehe, das Programm benutzt auch Pixel, und zwar genau passend für eine DIN A4-Seite. Bis her hat das wunderbar geklappt.
Ich bestreite nicht, daß das ein "Fehler" ist. Er ist ja reproduzierbar (wenn auch ausschließlich im IE), wenn auch nicht mit immer gleichem Ergebnis. Daraus läßt sich eher schließen, daß der IE irgendwelche Probleme mit deiner bisherigen Konstruktion hat, die sich vermutlich mit einer Korrektur des HTML-Codes allein nicht lösen lassen werden.
Muss sich ja nicht lösen lassen, hauptsache, die Breite wird richtig gemessen. Es gibt so viele Möglichkeiten für alles im MS-DOM (Breite: offsetWidth, pixelWidth, innerWidth, outerWidth, clientWidth, style.width, ...), das ich denke, über irgend einen Weg müsste es doch funktionieren. Das Problem ist, das bei vielen die Breite gar nicht in der Eigenschaft eingetragen ist, vielleicht gibt es irgend eine Funktion, welche die Breite auch benötigt und die man aufrufen kann, woraufhin die Breite errechnet wird? Oder irgend eine Methode? Das es nach focus() geht, legt doch die Vermutung nahe, dass es noch mehr Möglichkeiten gibt.
Ok, einverstanden - jedenfalls soweit es um "Webdesign" geht. Aber sobald es um "Programmiertechnik" geht, muß man über Sinn und Zewck sowie über die Frage, ob denn die richtigen Strukturierungsmodelle für eine Browserdarstellung gewählt wurden, sehr wohl noch ein bißchen debattieren.
Dies ist bereits die zweite Version, die mit solchen Frames arbeitet. Das Konzept wird deswegen nun nicht mehr geändert. Man könnte aber eine Alternative zu Tabellenzellen suchen.
Ich wäre ja ganz glücklich, wenn ich dir jetzt zwei oder drei Zeilen Code vor die Nase schmeißen könnte und dein Problem damit gelöst wäre. So gehts aber leider nicht. Du hast möglicherweise dein Problem selbst noch nicht verstanden, und ich (und vermutlich etliche Leser deiner Anfrage auch) habe noch nicht ganz verstanden, worin dein Problem eigentlich begründet ist. Die "Energie des Verstehens" ist also vorläufig noch auf der Strecke geblieben ...
Und was soll ich jetzt tun? Ich geh' erst mal schlafen und warte bis (über)morgen auf weitere Antworten. Dann hab' ich Zeit, mehr Code zu posten.
dartrax
-
morgens,
Und was soll ich jetzt tun?
Naja ... wir zwei haben bisher ganz nett geplaudert, aber mit mehr als großer Wahrscheinlichkeit haben auch allerhand andere Leute mitgelesen und bloß nicht genügend Mut oder Zeit gehabt, sich einzumischen.
Was _du_ nun machen könntest, wäre: erkläre das Konzept deines "Programms" genauer und gib an, wann, wo, wie und warum das Ding unbedingt so eine HTML-Frames-Seite ausgeben muß. Schließlich hast du bereis eine Riesenmenge an Gedankenarbeit geleistet, und "wir" hier kriegen bisher dein Problem nur in einer "light"-Version zu sehen, ohne bisher genau einschätzen zu können, warum du das unbedingt haben mußt.
Was _die anderen_ machen könnten, wäre: <murmelmurmelmurmel>ich sags ja</murmelmurmelmurmel> - oder etwas Vernünftigeres.Ich geh' erst mal schlafen und warte bis (über)morgen auf weitere Antworten.
Dann schlaf mal gut. Es bleibt zu hoffen, daß sich noch jemand anderes mit etwas Sachverstand zu Wort meldet, dazu sind wir schließlich ein Forum.
Dann hab' ich Zeit, mehr Code zu posten.
Hehe, es geht vermutlich gar nicht um "mehr Code", sondern eher um "mehr Konzeption" ...
Ähhhhh ... wenns geht, poste den Code, den du für relevant hältst, nicht unmittelbar hier im Forum, sondern lade eine Beispielseite irgendwo auf eine temporäre Adresse hoch und gib dann den Link an, so daß man sich das bei Bedarf anschauen kann. Das hat einen einfachen Grund: wie du richtig bemerkt hast, würdest du heftig beschimpft werden, wenn du gar keinen Code posten würdest - aber wenn du nun wieder "zu viel" Code postest, ist es auch doof, dann kriegst du auch wieder von irgendjemand nur einen vor den Latz geknallt.
Grüße aus Berlin
Christoph S.
-
-
-
-
-
Seht euch mal das Beispiel unten an. Dort wird über iFrames das gleiche Dokument 25 mal angezeigt. In so einem Dokument ist eine Tabellenzelle, deren Breite ermittelt wird. Das Problem: Die Breite der Zellen wird in den letzten iFrames nicht mehr ermittelt, die Funktion wird aber schon noch aufgerufen. Mir ist aufgefallen, dass die Anzahl der Frames, deren Zellenbreite noch ermittelt wird, abhängig von der Höhe der Frames ist. Deshalb habe ich den auskommentierten focus-Befehl eingefügt, ich finde es aber nicht so schön, jedes Mal das ganze Document durchscrollen zu sehen, und würde lieber den eigentlichen Fehler finden.
Wenn das iFrame Dokument strict ist (du hattest keinen DOCTYPE angegeben) wird überall der Wert angezeigt.
Wenn du unbedingt im Quirksmode dein Dokument ausliefern willst, muss es am onload liegen, wenn du nochmal eine kurze Verzögerung einbaust funktioniert es. (bei mir reichen 200ms)Struppi.
-
Hallo Struppi!
Wenn das iFrame Dokument strict ist (du hattest keinen DOCTYPE angegeben) wird überall der Wert angezeigt.
Aha. Wollte ich gerade ausprobieren, da merke ich: Hier funktioniert es bei allen Frames! Liegt vielleicht daran, das hier IE 5.0 installiert ist. Werde es zu Hause aber nochmal mit strict versuchen.
Wenn du unbedingt im Quirksmode dein Dokument ausliefern willst, muss es am onload liegen, wenn du nochmal eine kurze Verzögerung einbaust funktioniert es. (bei mir reichen 200ms)
Wie baust du die Verzögerung ein? Ich hätte an sowas wie Application.DoEvents() gedacht, was es in JavaScript leider nicht gibt...
dartrax
-
Wenn du unbedingt im Quirksmode dein Dokument ausliefern willst, muss es am onload liegen, wenn du nochmal eine kurze Verzögerung einbaust funktioniert es. (bei mir reichen 200ms)
Wie baust du die Verzögerung ein? Ich hätte an sowas wie Application.DoEvents() gedacht, was es in JavaScript leider nicht gibt...
Nö, aber window.setTimeout()
<body onload="window.setTimeout('test()', 200);">
Struppi.
-
Wenn du unbedingt im Quirksmode dein Dokument ausliefern willst, muss es am onload liegen, wenn du nochmal eine kurze Verzögerung einbaust funktioniert es. (bei mir reichen 200ms)
Ich habe dies direkt in der Anwendung ausprobiert, ich muss mindestens 1500ms angeben, damit alle Zellen erkannt werden. Je nach Geschwindigkeit des Computers und Komplexität des Dokumentes, nehme ich an, ist das also keine zuverlässige, sondern eine Notlösung (wie wir sie bisher auch hatten).
Außerdem habe ich es mit einer Dokumentenangabe für Strict versucht, das hat keinen Unterschied gebracht, weder im Beispiel noch in der Anwendung. Ich bin mir nicht sicher, ob ich das richtig gemacht habe, ich habe diese Zeilen oben eingefügt:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">War das nicht so, dass der IE automatisch in den Quirks-Mode kommt, wenn etwas nicht in den "Strict-Mode" passt? In der Anwendung passt garantiert vieles nicht...
Schließlich habe ich meine focus()-Methode ausprobiert. Dabei werden in regelmäßigen Abständen die Zellbreite _nicht_ erkannt, dazwischen schon. Deshalb habe ich noch ein Mix aus focus()- und SetTimeOut-Methode versucht. Ich habe beobachtet, dass bei zu kleinen Intervallen für TimeOut etwa 5 Dokumente geladen werden, dann wird für diese von unten nach oben die Javascript-Funktion angewandt (man sieht das dann daran, dass durch focus() immer dorthin gescrollt wird, wo die Funktion aktiv ist), dann werden die nächsten 5 geladen und wieder abgearbeitet. Erst wenn man so viel Zeit lässt, dass alle Dokumente vollständig geladen werden können und danach die Funktion ausgeführt wird, funktioniert sie fehlerfrei. Dazu würden dann bereits 300ms reichen.
Ich fürchte, alles endet mit diesem Zeitproblem: Angenommen, man lässt 5 Sekunden Zeit, dann ist das für User mit schnellen Prozessoren nervig und User, die viele Prozesse im Hintergrund laufen haben oder einen langsameren Computer haben bekommen völlig deformatierte Anzeigen. Vielleicht muss das ganze so gebaut werden, dass die Breite der Tabellenzelle unwichtig ist. Morgen poste ich mehr "Hintergrund".
bis dann,
dartrax
-
-
-
-
So, auch wenn dann alles etwas komplizierter ist, erweitere ich das Beispiel jetzt mal. Und bevor ich groß erkläre, erstmal der Code. Am besten herunterladen und im Internet Explorer (!) öffnen, damit hinterher die Verzögerung durch die Datenübertragung ausgeschlossen ist.
dartrax.da.funpic.de/selfhtml
Und jetzt die Erklärung:
Es geht um vier Tabellenzellen, die wie Zeilen untereinander angeordnet sind. In die erste wird in einen <pre>-Tag ein kurzer Text geschrieben. Beim Laden des Dokumentes soll der Text nun automatisch umgebrochen werden, das heißt auf die vier Zellen-Zeilen verteilt werden.
Besonderheiten: Zeilenumbrüche werden berücksichtigt (d. h. nächste Zelle) und freier Platz in der Zelle wird durchgestrichen (d. h. mit einem horizontalen Strich auf halber Höhe versehen).Gelöst wird das über eine JavaScript-Funktion, die bei onLoad aufgerufen wird. Das funktioniert schon alles, NUR: wenn viele dieser Dokumente per iFrame-Konstruktion in einem Dokument aufgerufen werden, wird die Breite der Zellen innerhalb der letzten Javascriptfunktionen nicht mehr erkannt - obwohl alles das gleiche Dokument ist!
-
hallo,
bevor ich groß erkläre, erstmal der Code.
Sehr gut, das ist ja auch das, was ich meinte: auf eine (temporäre) Adresse hochladen und den link angeben. Eine extra ZIP wäre nicht unbedingt nötig, hat aber auch nix geschadet und ist eine nette Zugabe.
Am besten herunterladen und im Internet Explorer (!) öffnen
Opera macht es genauso wie der IE, aber das nur nebenbei. "Herunterladen" ist eigentlich nicht nötig, man hat den Code ja im Cache, wenn man deinem Link folgt. Ich sehe keinen Unterschied zwischen dem, was in der ZIP steckt und dem, was ich mir als Seiten- bzw. Frames-Quelltext anschauen kann.
Gelöst wird das über eine JavaScript-Funktion, die bei onLoad aufgerufen wird. Das funktioniert schon alles, NUR: wenn viele dieser Dokumente per iFrame-Konstruktion in einem Dokument aufgerufen werden, wird die Breite der Zellen innerhalb der letzten Javascriptfunktionen nicht mehr erkannt - obwohl alles das gleiche Dokument ist!
Nunja, damit wären wir wieder beim Anfang. Ich sehe nicht, daß du den durchaus klugen Hinweis von Struppi, der dir ein Timeout ewmpfahl, umgesetzt hättest, und ich sehe auch nicht, daß deine iFrames unterschiedliche Namen bzw IDs tragen würden, wie ich empfohlen hatte. Machst du das noch und probierst es einfach aus?
Bei Struppi liest du in der Signatur "Javascript ist toll" - und ich kann dir versichern, der Mann weiß, warum er das sagt. Bei dir sieht der Javascript-Code auch erstmal höchst beeindruckend aus, allerdings bin ich der Überzeugung, daß du ihn noch erheblich eindampfen und verkleinern könntest. Zum Beispiel ist bisher nicht einzusehen, weshalb du sowohl "innerHTML" wie auch "innerText" brauchst.
Und eine kleine Spitze mußt du mir so ganz nebenbei noch erlauben:
<!--:::[...]::: -->
<!--:::[ J A V A ]::: -->
<!--:::[...]::: -->
Nichts gegen solche Kommentarblöcke, das ist gegebenenfalls Geschmackssache, aber prinzipiell erlaubt. Daß aber zwischen JAVA und Javascript doch ein erheblicher Unterschied besteht, ist dir schon klar?Ich verstehe auch nicht ganz, warum du
<body style="overflow: hidden" ... >
brauchst. Du hast ja bereits einen CSS-Bereich im Header, also solltest du solche Festlegungen alle an einem Ort versammeln. Und auch
<td id="Caption" style="WIDTH: 0%; PADDING-TOP: 7px">
ist ziemlich sehr erklärungsbedürftig. Es gibt nichts in deinem Code, was die Vergabe eine ID "Caption" verlangen würde, und die CSS-Formatierung gehört in den Header - wobei dringend geklärt werden müßte, warum das 0% sein sollen, wenn dann doch noch was in der <td> drinsteht.Letzten Endes muß aber wohl dein "Programm" das umsetzen und den HTML-Code erzeugen. Was das nun für ein Programm ist, und ob das Problem nicht vielleicht von ihm erzeugt wird, wissen wir noch nicht. Ich konnte bei einem erneuten Test deines (mit der ZIP heruntergeladenen) Codes das von dir beschriebene Problem nicht mehr reproduzieren - keine Sorge, einen IE 6.0 hab ich auch.
Setze mal die Anregungen, die du bereits bekommen hast, um - insbesondere die Sache mit dem Timeout. Wenn das auch nicht zum Erfolg führt, meldest du dich wieder. Wir kriegen das schon hin, auch wenns ein bissel dauern kann. Und wenn du zwischendurch angeniest werden solltest oder von "nicht hilfreichen" Antworten genervt wirst - tja, da mußt du durch. Die "letzte Instanz" ist, was Javascript angeht, im Moment tatsächlich Struppi, die sonstigen Javascript-Gurus des Forums sind im Moment mehr damit beschäftigt, an der geplanten Neuauflage von SELFHTML herumzustricken und kommen nicht mehr so oft dazu, hier im Forum alles mitzulesen.
Und zuguterletzt: ich verstehe immer noch nicht, warum du ein und dieselbe Seite 25mal in 25 iFrames laden willst. Wenn das irtendeinen Sinn machen soll, dann doch nur, weil der Aufruf auch 25 verschiedene Darstellungsweisen bzw. auf der Seite enthaltene Daten bringen soll.
Grüße aus Berlin
Christoph S.
-
Hallo!
Opera macht es genauso wie der IE, aber das nur nebenbei. "Herunterladen" ist eigentlich nicht nötig, man hat den Code ja im Cache, wenn man deinem Link folgt. Ich sehe keinen Unterschied zwischen dem, was in der ZIP steckt und dem, was ich mir als Seiten- bzw. Frames-Quelltext anschauen kann.
Es gibt keinen Unterschied, ich dachte nur, es ist bequemer, als im Cache rumzukramen.
Nunja, damit wären wir wieder beim Anfang. Ich sehe nicht, daß du den durchaus klugen Hinweis von Struppi, der dir ein Timeout ewmpfahl, umgesetzt hättest, und ich sehe auch nicht, daß deine iFrames unterschiedliche Namen bzw IDs tragen würden, wie ich empfohlen hatte. Machst du das noch und probierst es einfach aus?
Wie bereits geschrieben, ich habe den TimeOut-Tipp ausprobiert, muss aber 1500ms eingeben und fürchte so, dass es CPU-abhängig ist. Soll heißen: Es gibt immer ein langsameres System wo es nicht geht. Unterschiedliche Namen verwende ich von Anfang an, dabei (nicht dadurch) ist das Problem ja entstanden. Ich habe sie der Einfachheit halber im Beispiel weggelassen. Du kannst dir ja auch die frames.htm 20 mal kopieren, alle verschieden benennen und die Namen in die index.htm eintragen. Wenn du was ausprobieren willst, musst du halt nur alle 20 frames.htm durchgehen zum Code-ändern...
Es geht auch mit unterschiedlichen Namen nicht, wirklich!Bei Struppi liest du in der Signatur "Javascript ist toll" - und ich kann dir versichern, der Mann weiß, warum er das sagt. Bei dir sieht der Javascript-Code auch erstmal höchst beeindruckend aus, allerdings bin ich der Überzeugung, daß du ihn noch erheblich eindampfen und verkleinern könntest. Zum Beispiel ist bisher nicht einzusehen, weshalb du sowohl "innerHTML" wie auch "innerText" brauchst.
Weil es einen großen Unterschied zwischen innerText und innerHTML gibt!
Daß aber zwischen JAVA und Javascript doch ein erheblicher Unterschied besteht, ist dir schon klar?
Ja, das ist schon eineinhalb Jahre her, dass diese Zeilen entstanden, da habe ich angefangen, mir Javascript selbst beizubringen und da war mir das tatsächlich noch nicht klar.
Ich verstehe auch nicht ganz, warum du
<body style="overflow: hidden" ... >
brauchst. Du hast ja bereits einen CSS-Bereich im Header, also solltest du solche Festlegungen alle an einem Ort versammeln.Brauchen tue ich es, damit der Ausdruck wirklich zentriert ist und nicht die Breiten imaginärer Scrollleisten den Ausdruck verrücken. Hat mich einen ganzen Tag gekostet, um das herauszufinden. Du hast aber recht, strukturiert ist etwas anderes.
Und auch
<td id="Caption" style="WIDTH: 0%; PADDING-TOP: 7px">
ist ziemlich sehr erklärungsbedürftig. Es gibt nichts in deinem Code, was die Vergabe eine ID "Caption" verlangen würde, und die CSS-Formatierung gehört in den Header - wobei dringend geklärt werden müßte, warum das 0% sein sollen, wenn dann doch noch was in der <td> drinsteht.Das td soll so schmal wie möglich sein. Die ID wird wo anders gebraucht, ist nicht Bestandteil des Beispieles.
Letzten Endes muß aber wohl dein "Programm" das umsetzen und den HTML-Code erzeugen.
Warum setzt du Programm in Anführungszeichen? Was für eine Ablehnung hegst du gegen das Wort?
Was das nun für ein Programm ist, und ob das Problem nicht vielleicht von ihm erzeugt wird, wissen wir noch nicht. Ich konnte bei einem erneuten Test deines (mit der ZIP heruntergeladenen) Codes das von dir beschriebene Problem nicht mehr reproduzieren - keine Sorge, einen IE 6.0 hab ich auch.
Aber du konntest ihn doch vorher reproduzieren, oder? Verdoppele die Anzahl der iFrames, dann wird es schon noch klappen...
Setze mal die Anregungen, die du bereits bekommen hast, um - insbesondere die Sache mit dem Timeout. Wenn das auch nicht zum Erfolg führt, meldest du dich wieder. Wir kriegen das schon hin, auch wenns ein bissel dauern kann. Und wenn du zwischendurch angeniest werden solltest oder von "nicht hilfreichen" Antworten genervt wirst - tja, da mußt du durch.
Habe ich bereits - soll ich die auch hochladen? Ich glaube, wenn ich die Anregungen hier nicht ausprobierte, bräuchte ich gar nicht erst hier posten.
Die "letzte Instanz" ist, was Javascript angeht, im Moment tatsächlich Struppi, die sonstigen Javascript-Gurus des Forums sind im Moment mehr damit beschäftigt, an der geplanten Neuauflage von SELFHTML herumzustricken und kommen nicht mehr so oft dazu, hier im Forum alles mitzulesen.
Dann hat Struppi angesichts meines Codenirwanas vielleicht eine Idee, wie man sonst die Länge eines Textes in Pixeln errechnet oder das Problem mit den unerkannten Tabellenzellenweiten löst? Ich müsste sonst den Timeout-Focus-Mix anwenden, und das schmeckt eher nach Notlösung.
Und zuguterletzt: ich verstehe immer noch nicht, warum du ein und dieselbe Seite 25mal in 25 iFrames laden willst. Wenn das irtendeinen Sinn machen soll, dann doch nur, weil der Aufruf auch 25 verschiedene Darstellungsweisen bzw. auf der Seite enthaltene Daten bringen soll.
Pass auf, damit die Neugier versiegt: Man nimmt ein Formular (aus einer Auswahl von vielen unterschiedlichen), in das man Daten einträgt. Weil man ganze Datensätze hat, nimmt man 20 von diesen Formularen. Die will man vielleicht ausdrucken. Dafür werden diese 20 Formulare in eines zusammengefasst. Es ist die selbe HTML-Datei, es stehen aber unterschiedliche Daten drin. Mir Hilfe des zu einem zusammengesetzten 20er-Formulares kann man in einem Rutsch alle drucken.
So, bitte keine weiteren Zweifel an dem Programm, das wird nicht mehr geändert.dartrax
-
Weil es einen großen Unterschied zwischen innerText und innerHTML gibt!
Der würde mich interessieren.
Egal - ich hab mir das auch runtergeladen und bei mir scheint es zu laufen wie es soll. Auch wenn ich die iFrames verdoppele. Trotz des immer Quirksmode in allen Dokumenten.
Struppi.
-
Hallo Struppi.
Weil es einen großen Unterschied zwischen innerText und innerHTML gibt!
Der würde mich interessieren.
Mit innerText kann kein interpretierbares HTML ausgegeben werden, sondern nur Zeichenketten.
Einen schönen Mittwoch noch.
Gruß, Ashura
-
Weil es einen großen Unterschied zwischen innerText und innerHTML gibt!
Der würde mich interessieren.
Mit innerText kann kein interpretierbares HTML ausgegeben werden, sondern nur Zeichenketten.
Das geht mit fistChild.data auch, aber für den Zweck ist es belanglos, weil er so oder so nur eine Zeichenkette ausgibt soweit ich das sehe und da dürfte es keine Rolle spielen. Daher meine Frage
Struppi.
-
Das geht mit firstChild.data auch, aber für den Zweck ist es belanglos, weil er so oder so nur eine Zeichenkette ausgibt soweit ich das sehe und da dürfte es keine Rolle spielen. Daher meine Frage
Beide geben zwar Zeichenketten aus, der Inhalt ist aber unterschiedlich. Deshalb hat es seine Berechtigung, ich bin aber zu Faul genauer danach zu suchen, weil ich glaube, dass das nicht für das Problem verantwortlich ist.
Egal - ich hab mir das auch runtergeladen und bei mir scheint es zu laufen wie es soll. Auch wenn ich die iFrames verdoppele. Trotz des immer Quirksmode in allen Dokumenten.
Auf meinen beiden Rechnern (XP; IE 6.0.28... SP1) tritt der Fehler permanent auf. Index.htm muss allerdings ein mal neu geladen werden, wenn der IE erst durch Doppelklick auf index.htm geöffnet wird, ist der Fehler noch nicht da. Soll ich euch einen Screenshot schicken?
Da das Beispiel meines ersten Postings bei euch dennoch den Fehler produzierte, dürfte euch das nicht-auftreten nicht am Testen anderer Lösungsmöglichkeiten stören ;-)Opera macht es genauso wie der IE, aber das nur nebenbei.
Nein, denn (jedenfalls in der Version 8.5) fehlen die Striche an den Zeilenenden, außerdem werden alle Zellenbreiten hier korrekt erkannt.
dartrax
-
Auf meinen beiden Rechnern (XP; IE 6.0.28... SP1) tritt der Fehler permanent auf. Index.htm muss allerdings ein mal neu geladen werden, wenn der IE erst durch Doppelklick auf index.htm geöffnet wird, ist der Fehler noch nicht da. Soll ich euch einen Screenshot schicken?
OK, ich hab's nochmal getestet und plötzlich waren wirklich wieder zwei drei Frames auf null. Aber, wenn du die Dokumente gültig machst und in den Standardmode versetzt funktioniert alles tadellos ohne workaround.
(Ich hab auch dein innerTEXT in innerHTML geändert es ist kein Unterschied festzustellen)
Struppi.
-
OK, ich hab's nochmal getestet und plötzlich waren wirklich wieder zwei drei Frames auf null. Aber, wenn du die Dokumente gültig machst und in den Standardmode versetzt funktioniert alles tadellos ohne workaround.
Ich habe es nochmal mit der Strict-Anweisung ausprobiert und meinen Fehler entdeckt, weswegen ich bisher keinen Erfolg mit dieser Anweisung hatte: Ich hatte nicht index.htm, sondern nur frame.htm in den Strict-Mode gesetzt! Ist auch index.htm im Strictmode, funktioniert es zwar mit den Beispielen, im Programm haut's trotzdem noch bei zwei Dokumenten rein. (Aber es sind immerhin weniger geworden...)
(Ich hab auch dein innerTEXT in innerHTML geändert es ist kein Unterschied festzustellen)
Ich habe beides ausprobiert, also sowohl alle innerText mit innerHTML ersetzen zu lassen als auch umgekehrt. In beiden Fällen ist der Text danach verschoben, unvollständig, falsch formatiert oder mit nicht interpretierten HTML-Tags gespickt. Ich habe dazu das zweite Beispiel verwendet. Außerdem glaube ich, dass durch den Einsatz von innerText verhindert werden sollte, dass das gesamte Dokument durch HTML-Tags innerhalb des Textes zerschossen wird.
dartrax
-
-
-
-
-
-
-
-
-
Hallo dartrax,
In so einem Dokument ist eine Tabellenzelle, deren Breite ermittelt wird. Das Problem: Die Breite der Zellen wird in den letzten iFrames nicht mehr ermittelt, die Funktion wird aber schon noch aufgerufen.
Woran das jetzt liegt, weiß ich auch nicht; es scheint ein Bug zu sein. Als Workaround würde ich eine Funktion zwischenschalten, die so lange Ehrenrunden dreht, bis der Wert da ist:
function checkOffsetW()
{
if(document.getElementById("Zelle").offsetWidth > 0)
test();
else
setTimeout("checkOffsetW()", 200);
}<body onload="checkOffsetW()">
Es muss aber garantiert sein, dass die Zelle immer eine Breite > 0 hat. Sonst müßte noch eine Abbruchbedingung hinein, um zu verhindern, dass die Funktion sich endlos selbst aufrufen kann.
Grüße,
Stefan-
Hallo Stefan!
Klasse Idee, so sollte es klappen, wenn's denn auf den TimeOut hinausläuft, und im Moment sehe ich keine Alternative dazu.
Bin gerade dabei das umzusetzen, habe allerdings ein Problem, was aber nicht so schwierig sein dürfte: Ich möchte der Funktion Test() einen Parameter übergeben, und zwar ein String-Array. Ich bin soweit, dass er mir [Object] zurückgibt anstatt des Arrays (oder ist dies das Array?)
function checkOffsetW(ArrString)
{
if(document.getElementById("Zelle").offsetWidth > 0)
// Öffnet MsgBox mit Str1,Str2,Str3,Str4
test(ArrString);
else
// Öffnet MsgBox mit [Object]
setTimeout("checkOffsetW(" + ArrString + ")", 200);
}function test(ArrString)
{
alert(ArrString);
// ...
}<body onload="checkOffsetW(new Array('Str1', 'Str2', 'Str3', 'Str4'))">
dartrax
-
Hallo dartrax,
Bin gerade dabei das umzusetzen, habe allerdings ein Problem, was aber nicht so schwierig sein dürfte: Ich möchte der Funktion Test() einen Parameter übergeben, und zwar ein String-Array. Ich bin soweit, dass er mir [Object] zurückgibt anstatt des Arrays (oder ist dies das Array?)
function checkOffsetW(ArrString)
{
if(document.getElementById("Zelle").offsetWidth > 0)
// Öffnet MsgBox mit Str1,Str2,Str3,Str4
test(ArrString);
else
// Öffnet MsgBox mit [Object]
setTimeout("checkOffsetW(" + ArrString + ")", 200);Hier würde ArrString durch Str1,Str2,Str3,Str4 ersetzt, was dann kein Array mehr wäre, sondern vier wahrscheinlich nicht definierte Variablen. Ist es denn nötig, das Array schon im onload-Handler zu definieren? Könnte es nicht genausogut erst in test() definiert werden? Oder du packst es in eine globale Variable, sodass es nicht übergeben werden muss.
Wenn das nicht geht, musst du setTimeout() einen String übergeben, der genauso aussieht wie im onload-Handler:
<body onload="checkOffsetW(new Array('Str1', 'Str2', 'Str3', 'Str4'))">
etwa so: setTimeout("checkOffsetW(new Array('" + ArrString[0] + "','" + ArrString[1] + ... usw.
Eventuell geht auch: setTimeout(document.body.onload, 200);
Grüße,
Stefan-
Hier würde ArrString durch Str1,Str2,Str3,Str4 ersetzt, was dann kein Array mehr wäre, sondern vier wahrscheinlich nicht definierte Variablen. Ist es denn nötig, das Array schon im onload-Handler zu definieren? Könnte es nicht genausogut erst in test() definiert werden? Oder du packst es in eine globale Variable, sodass es nicht übergeben werden muss.
Das geht leider nicht, denn die Funktion wird im onload-Handler zwei mal mit verschiedenen Parametern aufgerufen. Deshalb müssen die Parameter bereits im Handler festgelegt werden, denn danach benutzen beide Funktionsdurchläufe den selben Code und sind deshalb nicht mehr ohne Parameter unterscheidbar.
Wenn das nicht geht, musst du setTimeout() einen String übergeben, der genauso aussieht wie im onload-Handler:
<body onload="checkOffsetW(new Array('Str1', 'Str2', 'Str3', 'Str4'))">
etwa so: setTimeout("checkOffsetW(new Array('" + ArrString[0] + "','" + ArrString[1] + ... usw.
Sehr kompliziert, wenn es kein statisches Array ist und der String deshalb mit einer Schleife gebildet werden muss.
Eventuell geht auch: setTimeout(document.body.onload, 200);
Wie oben beschrieben hat der onLoad-Handler mehrere Funktionsaufrufe, die sollen dann nicht auch alle mehrfach ausgeführt werden. Das wäre aber wohl der Fall, wenn man den im onLoad-Handler gespeicherten Wert aufruft.
Weil setTimeout nicht für Arrays ausgelegt zu sein scheint und auch meine Versuche, innerhalb von checkOffsetW die Verzögerung über eine while-Schleife, in der mit setTimeout eine dummy-Funktion aufgerufen wird, zu realisieren, eher in Endlosschleifen denn zum Erfolg geführt haben, verzichte ich auf das Array und packe die Zellennamen durch Komma getrennt in einen einfachen String. Der wird dann erst in der eigentlichen (hier test() genannten) Funktion mit .split() in ein Array umgewandelt. setTimeout braucht sich dann nur noch um den einen String kümmern.
Mit deinem timeOut-Tipp in einer rekursiven Funktion funktioniert es jetzt also, und zwar ohne überflüssige Zeit verstreichen zu lassen oder das Risiko einzugehen, dass auf langsamen Systemen doch noch die eine oder andere Fehlformatierung auftritt.
Wenn noch ein Problem mit dieser Lösung auftritt (oder noch die ein oder andere Antwort fällig ist), melde ich mich wieder, bis dahin: Tausend Dank, Stefan W!
dartrax
-
-
-