onFocus feuert nicht auf Scrollbalken

[Gernot Back]

Hallo Forumsgemeinde,

ich bastele mittlerweile an der x-ten Variante einer dynamischen Frameset-Tabelle. Dabei ist Scrollen eigentlich nur im Hauptframe unten rechts vorgesehen. Klickt man jedoch in einen anderen Frame, so soll es möglich sein, auch hier mittels Mausrad, Cursortasten oder Markieren-mit-der-Maus koordiniert mit dem Hauptframe zu scrollen. Das habe ich ja auch schon hinbekommen.

http://www.sprachlernspiele.de/anzeige2/tabelle.html

Das Problem ist jetzt nur: Wenn ich anschließend versuche, wieder mit den Scrollbalken zu scrollen, weigert sich der Frame unten rechts, je nachdem, wo der Focus zuletzt war (oder besser gesagt: immer noch ist) und je nachdem, in welche Richtung ich zu scrollen versuche.

Ich steuere das Ganze über die globale Variable aktFrame. Diese sollte bei Klick in den Hauptframe unten rechts dessen Namen "untRe" enthalten (gesetzt durch onFocus-Events, die ich für unterschiedliche Browsertypen sowohl in den einzelnen Frames im Frameset als auch im Body des darin geladenen Dokuments definiere). Wie mir aber eine Alert-Meldung

javascript:alert(aktFrame)

über die Adresszeile im Anschluss an Scrollversuche über Leisten bestätigt, wird der Focus dabei offensichtlich nicht neu gesetzt.

Hat jemand eine Idee, wie ich das Problem beheben kann?

Gruß Gernot

[Bert Randolf]

Hallo,

ja benutz keine Frames, sind die wirklich so nötig?
du kannst doch eine grosse tabelle entwerfen, die ganz normal scrollbar ist.

Bert

[Gernot Back]

Hallo Bert,

du bist herzlich eingeladen, etwas ohne Frames zu entwickeln, bei dem die Tabellenüberschriften oben und links auch jeweils nur in einer Richtung mitscrollen und in der anderen stehen bleiben, sodass man sie nicht aus dem Blickfeld verliert.

Die sportliche herausforderung geht übrigens an alle hier im Forum, die glauben, man könne Frames immer und grundsätzlich vermeiden. Steigt mal von eurem CSS-Olymp herunter und strengt euch mal an!

Möge die bessere Technik gewinnen!

Mit olympischen Grüßen

Gernot

[Cybaer]

Hi,

du bist herzlich eingeladen, etwas ohne Frames zu entwickeln, bei dem die Tabellenüberschriften oben und links auch jeweils nur in einer Richtung mitscrollen und in der anderen stehen bleiben, sodass man sie nicht aus dem Blickfeld verliert.

Vermutlich hat Mr. "I hate! people who don't think" nur vor dem Posten nicht nachgedacht! ;->

Gruß, Cybaer

[Bert Randolf]

Hi :)

Vermutlich hat Mr. "I hate! people who don't think" nur vor dem Posten nicht nachgedacht! ;->

stimmt, und son bisschen rumgefrikkel mit divs hats auch nicht gebracht :(

geb mich geschlagen.

Bert

[Gernot Back]

Hallo Bert,

wer wird denn gleich so schnell aufgeben? Ich arbeite hier an diesem Projekt (mit Unterstützung aus dem Forum) auch schon mehrere Wochen! Ich bin mir übrigens ziemlich sicher, dass man das auch mit Div-Elementen machen kann. Ich denke nur, dass das deutlich mehr Aufwand wird.

Übrigens, wenn du Javascript deaktivierst, wird bei meinem Frameansatz trotzdem die Tabelle geladen. Nur bei aktiviertem Javascript wird auf das Frameset weitergeleitet, in das dieselbe Tabelle dann ausschnittweise gleich vierfach geladen wird.

Bei einem framefreien Ansatz müsstest du da zwei komplett unterschiedliche Versionen der Tabelle bereitstellen.

Gruß Gernot

[Cybaer]

Hi,

Ich bin mir übrigens ziemlich sicher, dass man das auch mit Div-Elementen machen kann.

Selbstredend.

Ich denke nur, dass das deutlich mehr Aufwand wird.

Es wäre auf jeden Fall "unruhiger", da die Seitenelemente halt laufend neu positioniert werden müßten.

Bei einem framefreien Ansatz müsstest du da zwei komplett unterschiedliche Versionen der Tabelle bereitstellen.

Warum? Wir haben doch DHTML! Prinzipiell würde ich die Legende on-the-fly aus der Tabelle entfernen und passend neu positionieren.

Aber die Frame-Variante gefällt mir hier deutlich besser (weil's eben nicht ruckelt und weil es kompatibler ist: Manche Browser ignorieren nicht nur die "normalen" Stilangaben, sondern lassen selbst CSS-Positionierungen nicht mehr zu, wenn man CSS "ausschaltet").

Gruß, Cybaer

[Gernot Back]

Hallo Cybear,

Ich bin mir übrigens ziemlich sicher, dass man das auch mit Div-Elementen machen kann.

Selbstredend.

Es wäre auf jeden Fall "unruhiger", da die Seitenelemente halt laufend neu positioniert werden müßten.

Bei einem framefreien Ansatz müsstest du da zwei komplett unterschiedliche Versionen der Tabelle bereitstellen.

Warum? Wir haben doch DHTML! Prinzipiell würde ich die Legende on-the-fly aus der Tabelle entfernen und passend neu positionieren.

Na also, was hindert die Frames-Verächter jetzt noch? Ich würde das ja gerne mal sehen, ob deine Vermutung mit dem Ruckeln wirklich stimmt!

Da du ja sowieso in meiner Mannschaft bist, erwarte ich von dir keine solche framefreie Lösung, aber vielleicht hast du ja eine Lösung für  mein Focus-Problem?

Ich überlege mir auch, ob wir den Wettbewerb zwischen den Techniken nicht mal in einem eigenen Thread ausschreiben sollten, unter dem Titel hier findet es ja keiner. Vielleicht können wir dann diese müßigen Frames-Debatten hier im Forum ein für allemal beenden. Du leidest darunter du doch offensichtlich genauso wie ich!

Was hältst du davon?

Gruß Gernot

[Raik]

Hallo, Gernot!

das css-"position fixed"-experiment von fabrice pascal würde dir nicht helfen? da ruckelt auch nichts.

freundl. Grüsse aus Berlin, Raik

[Utz]

Hallo Raik,

das css-"position fixed"-experiment von fabrice pascal würde dir nicht helfen? da ruckelt auch nichts.

So wie ich Gernot verstanden habe würd ihm das nichts bringen - er will ja, dass es in eine Richtung beweglich ist und in die andere nicht, das Teil von Fabrice Pascal macht's komplett unbeweglich (BTW: Ich würde mich hierin äußerst gerne täuschen, ich fänd's nämlich für einen praktischen Einsatz deutlich schöner, wenn es nur in einer Scrollrichtung fixiert wäre - also her mit der Lösung, falls sie einer hat! *g*)

Grüße,

Utz

[Raik]

Hallo, Utz!

So wie ich Gernot verstanden habe würd ihm das nichts bringen - er will ja, dass es in eine Richtung beweglich ist und in die andere nicht,

dann die frage dazu: welcher frame soll denn nun eigentlich in welche richtung scrollbar sein und in welche nicht?
und welche scrollbewegungen sollen sich in welcher richtung auf den hauptframe auswirken?

freundl. Grüsse aus Berlin, Raik

[Gernot Back]

Hallo Raik,

dann die frage dazu: welcher frame soll denn nun eigentlich in welche richtung scrollbar sein und in welche nicht?
und welche scrollbewegungen sollen sich in welcher richtung auf den hauptframe auswirken?

Der obere Überschriftenframe soll nur horizontal, der linke Überschriftenframe nur vertikal, der Hauptframe unten rechts in beide Richtungen und der Legendenbezeichnungsframe oben links gar nicht scrollbar sein.

Das ist ja auch alles schon geregelt, abgesehen nur von dem Bug, dass wenn man zwischenzeitlich den Focus in einen anderen Frame setzt und nachher wieder im Hauptframe unten rechts über Scrollbalken scrollt, der Focus nicht neu gesetzt wird.

http://www.sprachlernspiele.de/anzeige2/tabelle.html

Gruß Gernot

[Raik]

Hallo, Gernot!

Das ist ja auch alles schon geregelt, abgesehen nur von dem Bug, dass wenn man zwischenzeitlich den Focus in einen anderen Frame setzt und nachher wieder im Hauptframe unten rechts über Scrollbalken scrollt, der Focus nicht neu gesetzt wird.
http://www.sprachlernspiele.de/anzeige2/tabelle.html

um auf den scrollbalken zu kommen, musst du mit der maus über den hauptframe. wie wäre es dabei mit onMouseover?

freundl. Grüsse aus Berlin, Raik

[Gernot Back]

Hallo Raik,

um auf den scrollbalken zu kommen, musst du mit der maus über den hauptframe. wie wäre es dabei mit onMouseover?

Genau den Tipp hat mir eben jemand gegeben, den ich per Mail kontaktiert habe, das ist auch die Lösung, aber weißt du was komisch ist?:

Sogar, wenn man auf dem Weg zum Scrollbalken das Body-Element des Frames unten rechts gar nicht kreuzt, feuert der Event-Handler onMouseover, anders als onFocus, der selbst dann noch nicht feuert, wenn man auf die Scrolleiste klickt.

Man lernt nie aus, danke!

Gruß Gernot

[Mathias Bigge]

Hi Raik,

um auf den scrollbalken zu kommen, musst du mit der maus über den hauptframe. wie wäre es dabei mit onMouseover?

Schöner Geistesblitz. Da haben einige schon sehr lange daran herumgefrickelt. Danke!

Viele Grüße
Mathias Bigge

[Cybaer]

Hi,

Na also, was hindert die Frames-Verächter jetzt noch? Ich würde das ja gerne mal sehen, ob deine Vermutung mit dem Ruckeln wirklich stimmt!

Das läßt sich auf jeder beliebigen Seite feststellen, die feste Positionierung verwendet und den dafür notwendigen IE-Workaround benutzt (google mal nach "position fixed IE workaround" ;-)).

Da du ja sowieso in meiner Mannschaft bist, erwarte ich von dir keine solche framefreie Lösung,

Also wenn was mit CSS besser klappt (und auch die sonstigen Notwendigkeiten erfüllt), bin ich der erste, der CSS nutzt. =:-)

Technik ist kein Dogma, sondern eine Zwangsläufigkeit (oder auch nicht) ... ;)

aber vielleicht hast du ja eine Lösung für  mein Focus-Problem?

Nein. Spontan nicht, für mehr fehlt die Zeit ... =;-)

Vielleicht können wir dann diese müßigen Frames-Debatten hier im Forum ein für allemal beenden.

So wie die "C64 ./. Atari XL"-, "Atari ST ./. Amiga"-, "Windows ./. Linux"-Debatten beendet sind? =;->

Du leidest darunter du doch offensichtlich genauso wie ich!

Ne, keine Spur. Mich ärgern allerdings *prinzipiell* unsaubere/unlautere "Argumente". Da werde ich zwangsläufig zum "Advocatus Diaboli"! :-)) Das wäre also umgekehrt auch der Fall, wenn jemand Frames als "Allheilmittel" über den grünen Klee lobt, und IMHO unberechtigt andere Techniken niedermacht.

Hier falle ich nur auf, weil es hier a) relativ wenige "Pro-Framer" gibt, und b) ich nun dummerweise was davon verstehe und c) keine Probleme damit habe ... ;->

Was hältst du davon?

Ergo: Nüscht. ;-) Prinzipiell gibt es nicht "die bessere Technik", sondern nur die "von Fall zu Fall geeignetere Technik".

Bei *diesem* Problem ist allerdings CSS ungeeigneter (IMHO - halt alleine schon wg. der "Ruhe" der Framevariante und der Nähe zu der üblichen Spreadsheet-Software). Deswegen braucht man es erst auch gar nicht versuchen ... ;-)

... außer man ist pathologischer Frame-Hasser.

Gruß, Cybaer

[Utz]

Hallo Cybaer,

Das läßt sich auf jeder beliebigen Seite feststellen, die feste Positionierung verwendet und den dafür notwendigen IE-Workaround benutzt (google mal nach "position fixed IE workaround" ;-)).

http://www.microtool.de/objectif/de/index.asp hat zwar jede Menge Macken (kein Doctype, völlig unsinnige Stylesheets bei den meisten @media-Einbindungen, Conditional Comments, Tabellenlayout usw. usf.) aber es simuliert position fixed auf dem IE und ruckelt nicht.

Grüße,

Utz

[Cybaer]

Hi,

http://www.microtool.de/objectif/de/index.asp hat zwar jede Menge Macken (kein Doctype, völlig unsinnige Stylesheets bei den meisten @media-Einbindungen, Conditional Comments, Tabellenlayout usw. usf.) aber es simuliert position fixed auf dem IE und ruckelt nicht.

Weil das "Fixed-Menü" sich nicht über dem Content befindet, sondern neben dem Content?

Gruß, Cybaer

PS: Wow, so üblen Code habe ich bislang selten gesehen ... =:-)

[Utz]

Hallo Cybaer,

Weil das "Fixed-Menü" sich nicht über dem Content befindet, sondern neben dem Content?

Ne, weil's ne reine CSS[1]-Lösung ist - die JavaScript-Workarounds sind es, die ruckeln.

[1] Allerdings aber nicht valides CSS

Grüße,

Utz

[Cybaer]

Hi,

Ne, weil's ne reine CSS[1]-Lösung ist - die JavaScript-Workarounds sind es, die ruckeln.

Ähm, http://de.wikipedia.org/wiki/Rhetorische_Frage?

Die JavaScript-Workarounds werden benötigt, wenn der statische Content über dem flexiblem Content ist.

[1] Allerdings aber nicht valides CSS

So genau habe ich nicht hingeschaut - war ja eh nichts valide oder auch nur wohlgeformt ... =:-)

Gruß, Cybaer

[Gernot Back]

Hallo Cybear!

Also wenn was mit CSS besser klappt (und auch die sonstigen Notwendigkeiten erfüllt), bin ich der erste, der CSS nutzt. =:-)

So sehe ich das auch.

aber vielleicht hast du ja eine Lösung für mein Focus-Problem?

Nein. Spontan nicht, für mehr fehlt die Zeit ... =;-)

Du Glücklicher, du gehörst zu den Werktätigen!

Vielleicht können wir dann diese müßigen Frames-Debatten hier im Forum ein für allemal beenden.
Was hältst du davon?

So wie die "C64 ./. Atari XL"-, "Atari ST ./. Amiga"-, "Windows ./. Linux"-Debatten beendet sind? =;->
Ergo: Nüscht. ;-) Prinzipiell gibt es nicht "die bessere Technik", sondern nur die "von Fall zu Fall geeignetere Technik".

Ich will nur die Debatte beenden, es gäbe immer eine bessere Lösung als Frames, das ist nämlich Quatsch! Deshalb verstehe ich dich hier jetzt gerade nicht, aber dein Zeitproblem muss ich natürlich akzeptieren. Ich kann mir das auch nur leisten, weil ich arbeitslos bin, und das Projekt, um das es hier geht, ist auch nicht meines.

http://forum.de.selfhtml.org/archiv/2004/7/84595/#m496115

Gruß Gernot

[Geistiger Hohlraum]

Hat jemand eine Idee, wie ich das Problem beheben kann?

Der Büchsenmacher?

[Thomas Meinike]

Hallo,

über die Adresszeile im Anschluss an Scrollversuche über Leisten bestätigt, wird der Focus dabei offensichtlich nicht neu gesetzt.

Wenn ich das richtig verstehe, dann behebt ein Klick auf die große Tabelle das Problem. Probiere es also man damit, ein click-Ereignis zu simulieren -- also etwas in der Richtung parent.frames["framename"].document.body.click() oder parent.frames["framename"].document.getElementById("div_mit_tabelle_id").click().

MfG, Thomas

[Gernot Back]

Hallo Thomas,

Wenn ich das richtig verstehe, dann behebt ein Klick auf die große Tabelle das Problem. Probiere es also man damit, ein click-Ereignis zu simulieren -- also etwas in der Richtung parent.frames["framename"].document.body.click() oder parent.frames["framename"].document.getElementById("div_mit_tabelle_id").click().

Bei simulierten Klick-Events über die Methode click() tat sich bei meinen Versuchen mit MSIE 6.0 gar nichts am Focus. Außerdem glaube ich nicht, dass mir das wirklich helfen würde, denn ebenso könnte ich ja auch gleich den Inhalt der Variablen aktFrame neu setzen. Die Frage ist nur, an welches Event ich das dann wiederum binden soll.

Das onScroll-Event das ich mit Scrolleistenbewegung auslöse, scheidet aus, weil der Eventhandler dann auch aus dem Frame mitfeuert, der nur passiv über meine Koordinierungsfunktion mitscrollt.

Ich fürchte, ich werde das Scrollen einfach in den anderen Frames ganz unterbinden müssen, was natürlich nicht sonderlich benutzerfreundlich ist. Da treibe ich den Teufel mit Beelzebub aus.

Trotzdem danke für deinen Tipp!

Gruß Gernot

[Gunnar Bittersmann]

http://www.sprachlernspiele.de/anzeige2/tabelle.html

Hi Gernot,
Ich denke, dein eigentliches Problem ist die mangelnde Unterstützung der Anzeige von Tabellen durch die Browser. Es gibt zwar th vs. td und thead/tfoot vs. tbody, aber man kann die Browser mit CSS nicht dazu bewegen, die Spalten-/Zeilenköpfe nicht wegzuscrollen.

Wenn Browser das nicht können, warum lässt du die Tabelle beim Nutzer nicht durch ein Programm anzeigen, welches das kann? Du könntest die Tabelle z.B. als Excel-Datei anbieten und alle, die Excel oder Open Office etc. auf ihrem System haben, können sie lesen.

Für die wenigen anderen (wenn es sie gibt) sollte natürlich alternativ eine HTML-Variante zur Verfügung stehen.

Gruß,
Gunnar

[Gernot Back]

Hallo Gunnar,

Wenn Browser das nicht können, warum lässt du die Tabelle beim Nutzer nicht durch ein Programm anzeigen, welches das kann? Du könntest die Tabelle z.B. als Excel-Datei anbieten und alle, die Excel oder Open Office etc. auf ihrem System haben, können sie lesen.

Das kann man machen, nur ist die Excel-Tabelle dann auch gleichzeitig für den Nutzer editierbar, und das soll sie ja nicht sein.

Außerdem reicht es nicht, Excel auf seinem System zu haben, man muss auch noch zusätzlich irgendwelche Active-X-Steuerelemente installieren, damit schreckt man die meisten Nutzer wohl ab und ich befürchte, das Ganze läuft dann auch nur mit MSIE.

Für die wenigen anderen (wenn es sie gibt) sollte natürlich alternativ eine HTML-Variante zur Verfügung stehen.

Ich glaube die, bei denen es entweder an Excel oder den entsprechenden Active-X-Elementen oder an MSIE-Nutzungsbereitschaft  fehlt, sind die Mehrheit. Das Event-Handler-Problem ist übrigens dank der Mithilfe aus dem Forum inzwischen gelöst.

http://www.sprachlernspiele.de/anzeige2/tabelle.html

Jetzt warte ich nur noch auf die framefreie Lösung, damit ich vergleichen kann, welche Technik im vorliegenden Fall besser funktioniert. Ich bin mir sicher, die framelose Variante ist auch möglich, natürlich aber auch nur in Kombination mit JavaScript.

Ich schreibe auf jeden Fall einen Feature-Artikel dazu.

Gruß Gernot

[Gunnar Bittersmann]

Das kann man machen, nur ist die Excel-Tabelle dann auch gleichzeitig für den Nutzer editierbar, und das soll sie ja nicht sein.

Die HTML-Datei ist auch vom Nutzer lokal editierbar. Editierbar heißt ja nicht, dass jemand die Tabelle auf deinem Server überschreiben kann.

Außerdem kann man das Editieren für Excel-Dateien sperren (dann nur noch mit Passwort).

Außerdem reicht es nicht, Excel auf seinem System zu haben, man muss auch noch zusätzlich irgendwelche Active-X-Steuerelemente installieren, damit schreckt man die meisten Nutzer wohl ab und ich befürchte, das Ganze läuft dann auch nur mit MSIE.

Sollten nicht alle Browser für Dateitypen, die sie nicht selber öffnen können, beim Betriebssystem anfragen, mit welchem Programm die Datei geöffnet werden (bzw. heruntergeladen werden soll)?

Ich sehe da keine Abhängigkeit vom IE und ActiveX.

Ich glaube die, bei denen es entweder an Excel ... fehlt, sind die Mehrheit.

Open Office dürfte auch mit Excel-Dateien klarkommen.

Das Event-Handler-Problem ist übrigens dank der Mithilfe aus dem Forum inzwischen gelöst. ... Ich bin mir sicher, die framelose Variante ist auch möglich, natürlich aber auch nur in Kombination mit JavaScript. Ich schreibe auf jeden Fall einen Feature-Artikel dazu.

Gut, dass du das machst. Schlecht, dass du das machen musst. Ist ja ein Hack. Besser wär's, die Browser würden von sich aus - entsprechendes Markup (thead, tbody, ...) vorausgesetzt - Tabellen vernünftig anzeigen.
Gunnar

[Ingo Turski]

Hi,

ich finde eine HTML Lösung weitaus sinnvoller als Excel zu verwenden. Nach Möglichkeit sollten alle Daten im Netz ohne Plugins verfügbar gemacht werden und Excel wäre ein Plugin, welches zumindest weniger weit verbreitet sein dürfte als Java oder Flash. Außerdem sind Excel-Dateien unnötig groß.
Ok, hin und wieder setze ich auch eine Excel-Datei ins Netz, aber nur, wenn der Aufwand sie in HTML umzusetzen, zu groß wäre.
Und die Lösung hier funktioniert doch - sogar ohne Javascript sind die Daten verfüg- und nutzbar.

freundliche Grüße
Ingo

[Gunnar Bittersmann]

ich finde eine HTML Lösung weitaus sinnvoller als Excel zu verwenden.

Ja, was direkt im Browser läuft, ist schon für den Nutzer am besten.

Außerdem sind Excel-Dateien unnötig groß.

Zippen? ;-)

Und die Lösung hier funktioniert doch - sogar ohne Javascript sind die Daten verfüg- und nutzbar.

War nur eine Idee, die Darstellung einer Tabelle eben dem Tabellenkalkulationsprogramm des Nutzers zu überlassen.

Ich glaub, ich würd selber auch eine andere Lösung vorziehen. Und wenn Gernot seinen Artikel fertig hat, wüsste ich auch, wo ich danach suche. :-)

Gunnar

[Ingo Turski]

Hi,

Zippen? ;-)

:-))

War nur eine Idee, die Darstellung einer Tabelle eben dem Tabellenkalkulationsprogramm des Nutzers zu überlassen.

da habe ich ja auch nichts gegen - nur welchem? Die HTML-Tabelle (die ja ohne Javascript wunderbar formatiert ist) kann sich jeder Besucher bei Bedarf in die Tabellenkalkulation seiner Wahl inportieren...

freundliche Grüße
Ingo

[Gunnar Bittersmann]

Ja, was direkt im Browser läuft, ist schon für den Nutzer am besten.

Ergänzung: In einem Intranet, wo alle IE und Excel haben, ist die Excel-Lösung durchaus praktikabel (wird direkt im Browserfenster angezeigt) und einfacher zu realisieren.
Gunnar