Excel: Blatt fixieren mit VBA (Buggy?)

R_o_b · 12. November 2019 um 00:26

Salute zusammen,

ich weiß, daß die Aktion FreezePanes eine der wenigen ist, die wohl nur mit Select bzw. Activate funktioniert. Verrückterweise aber fixiert Excel nicht links und oben der aktuellen Markierung, sondern auch noch in Abhängigkeit der Scrollposition (wenn ich ins Blatt reingescrollt habe, verschiebt sich der Fixierpunkt nach innen ins Blatt).

ThisWorkbook.Worksheets("Bla").Activate
Cells(y, x).Select
ActiveWindow.FreezePanes = True

funktioniert also nicht. Ich muß anpassen

ThisWorkbook.Worksheets("Bla").Activate
MerkeColumn = ActiveWindow.ScrollColumn
MerkeRow = ActiveWindow.ScrollRow

ActiveWindow.ScrollColumn = 1
ActiveWindow.ScrollRow = 1
Cells(y, x).Select
ActiveWindow.FreezePanes = True

ActiveWindow.ScrollColumn = MerkeColumn
ActiveWindow.ScrollRow = MerkeRow

Dann hauts hin.

Geht das nicht auch einfacher? Und was soll die undurchsichtige Freeze-Abhängikeit von der Scroll-Position?

Danke und Grüße vom
-Rob.

Thomas_Ramel · 12. November 2019 um 00:26

Grüezi Rob

Verrückterweise aber fixiert Excel nicht links und oben der
aktuellen Markierung, sondern auch noch in Abhängigkeit der
Scrollposition (wenn ich ins Blatt reingescrollt habe,
verschiebt sich der Fixierpunkt nach innen ins Blatt).

Was genau verstehst Du unter ‚ins Blatt reingescrollt‘ und ‚nach innen im Blatt‘?

Kann man sagen, dass bei .Select die der sichtbare Bereich des Tabellenblattes so verschoben wird, dass die selektierte Zelle dann sichtbar wird?

ThisWorkbook.Worksheets(„Bla“).Activate
Cells(y, x).Select
ActiveWindow.FreezePanes = True

funktioniert also nicht.

Das funktioniert schon, aber die selektierte Zelle liegt dann im sichtbaren Bereich und nicht wie vorher wohl ausserhalb desselben.

Geht das nicht auch einfacher? Und was soll die
undurchsichtige Freeze-Abhängikeit von der Scroll-Position?

Die Zelle an der fixiert werden soll muss sichtbar sein, da die Eigenschaften sich auf das Fenster und nicht auf das Tabellenblatt beziehen.

Do kannst also nichts anderes tun, als dir den sichtbaren Bereich vorher zu merken. Oder Du stellst die fixzierung gleich zu Beginn ein.

Mit freundlichen Grüssen

Thomas Ramel

MVP für MS-Excel -

R_o_b · 12. November 2019 um 00:27

Excel: Blatt fixieren mit VBA (Buggy!)
Salu Thomas,

Was genau verstehst Du unter ‚ins Blatt reingescrollt‘ und
‚nach innen im Blatt‘?

Naja, damit meine ich, daß die Scrollposition aben nicht 1,1 ist, sondern daß vermittels der Scrollbalken nach rechts und/oder unten gescrollt wurde, daß also die Zelle A1 nicht mehr im sichtbaren Bereich liegt.

ThisWorkbook.Worksheets(„Bla“).Activate
Cells(y, x).Select
ActiveWindow.FreezePanes = True

funktioniert also nicht.

Das funktioniert schon, aber die selektierte Zelle liegt dann
im sichtbaren Bereich und nicht wie vorher wohl ausserhalb
desselben.

Nunja, der Code „funktioniert“ in dem Sinne, daß er keinen Fehler auswirft. Aber er funktioniert nicht so, wie er soll, nämlich daß sich die Fixierung nur an der selektierten Zelle ausrichtet, und es nicht zu merkwürdigen Fixierungen kommt, wenn das Fenster vor Aufruf gescrollt wurde.

Die Zelle an der fixiert werden soll muss sichtbar sein, da
die Eigenschaften sich auf das Fenster und nicht auf das
Tabellenblatt beziehen.

Do kannst also nichts anderes tun, als dir den sichtbaren
Bereich vorher zu merken. Oder Du stellst die fixzierung
gleich zu Beginn ein.

Und das bedeutet dann wohl, daß es eben nur mit dem zweiten Script funktioniert (siehe mein erstes Posting), und das finde ich geradezu absurd: Daß FreezePane orientiert sich nicht an einer Vorgabe (z. B. an der selektierten Zelle), sondern es benötigt zwei Vorgaben , die für das gewünschte Freeze-Ergebnis stimmen müssen: Selektierte Zelle und Scroll-Position.

Aber dank Dir weiß ich nun, daß es wohl tatsächlich nicht anders geht. Dann blamier ich mich nicht mit diesem Code-Monster ;o)

Merci & viele Grüße
-Rob.

Reinhard_fb8cb7 · 12. November 2019 um 00:27

ich weiß, daß die Aktion FreezePanes eine der wenigen ist, die
wohl nur mit Select bzw. Activate funktioniert.
Verrückterweise aber fixiert Excel nicht links und oben der
aktuellen Markierung, sondern auch noch in Abhängigkeit der
Scrollposition (wenn ich ins Blatt reingescrollt habe,
verschiebt sich der Fixierpunkt nach innen ins Blatt).

Hallo Rob,

ich nehme eine neue Mappe, scrolle da nach unten und markiere sogar eine zelle, egal jetzt, sagen wir mal F68.

Dann lasse ich diesen Code laufen, der C5 markiert:

Sub tt()
With ThisWorkbook.Worksheets(1)
 .Cells(5, 3).Select 'C5
 ActiveWindow.FreezePanes = True
End With
End Sub

Danach ist Zeile 1:4 und Spalte A:B fixiert.
Das funktioniert auch wenn ich Spalte C und Zeile 5 ausblende.

Insofern verstehe ich gar nicht wo da dein Problem mit Scrollen liegen könnte. Sorry.
Was hab ich nicht kapiert?

Gruß
Reinhard

Thomas_Ramel · 12. November 2019 um 00:28

Grüezi Rob

ThisWorkbook.Worksheets(„Bla“).Activate
Cells(y, x).Select
ActiveWindow.FreezePanes = True

funktioniert also nicht.

Das funktioniert schon, aber die selektierte Zelle liegt dann
im sichtbaren Bereich und nicht wie vorher wohl ausserhalb
desselben.

Nunja, der Code „funktioniert“ in dem Sinne, daß er keinen
Fehler auswirft. Aber er funktioniert nicht so, wie er soll,
nämlich daß sich die Fixierung nur an der selektierten Zelle
ausrichtet, und es nicht zu merkwürdigen Fixierungen kommt,
wenn das Fenster vor Aufruf gescrollt wurde.

Die Zelle an der fixiert werden soll muss sichtbar sein, da
die Eigenschaften sich auf das Fenster und nicht auf das
Tabellenblatt beziehen.

Und das bedeutet dann wohl, daß es eben nur mit dem zweiten
Script funktioniert (siehe mein erstes Posting), und das finde
ich geradezu absurd: Daß FreezePane orientiert sich nicht an
einer Vorgabe (z. B. an der selektierten Zelle), sondern es
benötigt zwei Vorgaben , die für das gewünschte Freeze-Ergebnis
stimmen müssen: Selektierte Zelle und Scroll-Position.

Hmmm, sorry, aber ich komme da nicht so ganz mit.

Welchen Sinn macht es, wenn Du Zeilen/Spalten fixierst, die ausserhalb des sichtbaren Bereiches liegen?

Sinn und Zweck der Fixierung ist es ja gerade, dass diese Zeilen/Spalten dann immer innerhalb des sichtbaren Bereiches bleiben.

Und genau aus diesem Grunde greifen diese Eigenschaften auch nur im sichtbaren Bereich des Tabellenblattes.

Denn Du kannst z.b. folgendes tun, ohne die ‚fixierende‘ Zelle zu selektieren:

 With ActiveWindow
 .SplitRow = 3
 .SplitColumn = 3
 .FreezePanes = True
 End With

Das ‚Problem‘ dabei ist dann, dass je nach eingestelltem Bereich eben die dann sichtbaren ersten 3 Zeilen/spalten fixiert werden.

Die Fixierung bezieht sich also immer auf den sichtbaren Bereich des Tabellenblattes. Willst Du nun eine Fixierung auf einer Zellen setzen die ausserhalb liegt musst Du selbige Zelle eben zuerst in den sichtbaren Bereich bringen.
Für mich ist hier eine gewisse Logik durchaus ersichtlich.

Mit freundlichen Grüssen

Thomas Ramel

MVP für MS-Excel -

Thomas_Ramel · 12. November 2019 um 00:28

Grüezi Reinhard

ich nehme eine neue Mappe, scrolle da nach unten und markiere
sogar eine zelle, egal jetzt, sagen wir mal F68.

Dann lasse ich diesen Code laufen, der C5 markiert:

Sub tt()
With ThisWorkbook.Worksheets(1)
.Cells(5, 3).Select 'C5
ActiveWindow.FreezePanes = True
End With
End Sub

Danach ist Zeile 1:4 und Spalte A:B fixiert.
Das funktioniert auch wenn ich Spalte C und Zeile 5 ausblende.

Insofern verstehe ich gar nicht wo da dein Problem mit
Scrollen liegen könnte. Sorry.
Was hab ich nicht kapiert?

F68 dürfte dann ausserhalb des sichtbaren Fenster liegen und es ist nicht mehr derselbe Ausschnitt des Tabellenblatts sichtbar wie vor dem Fixieren.

Mit freundlichen Grüssen

Thomas Ramel

MVP für MS-Excel -

R_o_b · 12. November 2019 um 00:28

Okay, so isset halt…
Salu Thomas,

danke für Deine Überlegungen. Aber ich sehe das doch etwas anders …

Hmmm, sorry, aber ich komme da nicht so ganz mit.

Welchen Sinn macht es, wenn Du Zeilen/Spalten fixierst, die
ausserhalb des sichtbaren Bereiches liegen?

Ich möchte Buttons im Tabellenblatt haben, die bewirken, daß bestimmte Spalten ausgeblendet werden und daß eine bestimmte Fixierung eingerichtet ist. Damit die Buttons failsafe sind, müssen sie natürlich auch dann eine richtige Fixierung liefern, wenn der User wer weiß wohin gescrollt hat.

Sinn und Zweck der Fixierung ist es ja gerade, dass diese
Zeilen/Spalten dann immer innerhalb des sichtbaren Bereiches
bleiben.

Und genau aus diesem Grunde greifen diese Eigenschaften auch
nur im sichtbaren Bereich des Tabellenblattes.

Denn Du kannst z.b. folgendes tun, ohne die ‚fixierende‘ Zelle
zu selektieren:

With ActiveWindow
.SplitRow = 3
.SplitColumn = 3
.FreezePanes = True
End With

Das ‚Problem‘ dabei ist dann, dass je nach eingestelltem
Bereich eben die dann sichtbaren ersten 3 Zeilen/spalten
fixiert werden.

Okay, das wäre das Workaround mit Split statt Freeze. Ist halt nicht so elegant und für den unbedarften User vielleicht auch problematisch.

Die Fixierung bezieht sich also immer auf den sichtbaren
Bereich des Tabellenblattes. Willst Du nun eine Fixierung auf
einer Zellen setzen die ausserhalb liegt musst Du selbige
Zelle eben zuerst in den sichtbaren Bereich bringen.
Für mich ist hier eine gewisse Logik durchaus ersichtlich.

Wie gesagt: Für VBA ausgelöstes Fixieren ist dieses Verhalten nicht so vorteilhaft (s. o.). Und warum dieses Verhalten logisch notwendig sein soll, weiß ich auch nicht. Man könnte doch einfach den Befehl

Cells(x, y).FreezePane

einfach so laufen lassen. Wenn der links/oben fixierte Bereich zum Ausführungszeitpunkt nicht sichtbar ist, wird er eben in den sichtbaren Bereich gezogen, der verschiebbare Bereich rechts/unten bleibt, wo er ist.

Mich interessiert nämlich auch, wo das derzeitige Verhalten sinnvoll anzuwenden ist, bzw. wo das von mir vorgeschlagene Verhalten nachteilig wäre!?

Liebe Grüße ins Sommerwetter :o)
-Rob.

Thomas_Ramel · 12. November 2019 um 00:28

Grüezi Rob

Ich möchte Buttons im Tabellenblatt haben, die bewirken, daß
bestimmte Spalten ausgeblendet werden und daß eine bestimmte
Fixierung eingerichtet ist. Damit die Buttons failsafe sind,
müssen sie natürlich auch dann eine richtige Fixierung
liefern, wenn der User wer weiß wohin gescrollt hat.

Ja das klappt ja auch, einzig die Sichtweise aufs Tabellenblatt ist dann nicht mehr dieselbe.

Das ‚Problem‘ dabei ist dann, dass je nach eingestelltem
Bereich eben die dann sichtbaren ersten 3 Zeilen/spalten
fixiert werden.

Okay, das wäre das Workaround mit Split statt Freeze. Ist halt
nicht so elegant und für den unbedarften User vielleicht auch
problematisch.

Am Ende wird ja auch wieder mit Freeze gearbeitet - aber ich glaube Du hast den Sinn meiner Ausführungen noch nicht so ganz verstanden.

Wie gesagt: Für VBA ausgelöstes Fixieren ist dieses Verhalten
nicht so vorteilhaft (s. o.). Und warum dieses Verhalten
logisch notwendig sein soll, weiß ich auch nicht. Man könnte
doch einfach den Befehl

Cells(x, y).FreezePane

einfach so laufen lassen. Wenn der links/oben fixierte Bereich
zum Ausführungszeitpunkt nicht sichtbar ist, wird er eben in
den sichtbaren Bereich gezogen, der verschiebbare Bereich
rechts/unten bleibt, wo er ist.

Mich interessiert nämlich auch, wo das derzeitige Verhalten
sinnvoll anzuwenden ist, bzw. wo das von mir vorgeschlagene
Verhalten nachteilig wäre!?

Ich glaube, das ist die 50/50 Chance die jeder Programmierer hat wenn er sich zwischen zwei Möglichkeiten entscheiden muss.

Generell ist das Fixieren ein Vorgang der zu Beginn, beim Layouten eines Tabellenblattes (oder allenfalls zwischendrin mal) eine Rolle spielt. Warum muss das denn bei dir über Buttons immer wieder gemacht werden?

Mit freundlichen Grüssen

Thomas Ramel

MVP für MS-Excel -

Reinhard_fb8cb7 · 12. November 2019 um 00:28

Insofern verstehe ich gar nicht wo da dein Problem mit
Scrollen liegen könnte. Sorry.
Was hab ich nicht kapiert?

F68 dürfte dann ausserhalb des sichtbaren Fenster liegen und
es ist nicht mehr derselbe Ausschnitt des Tabellenblatts
sichtbar wie vor dem Fixieren.

Grüezie Thomas,

okay, wenn es daran hängt, dann soll halt Rob das nehmen:

Sub ttt()
Dim Zelle As Range
With ThisWorkbook.Worksheets(1)
 Set Zelle = ActiveCell
 .Cells(5, 3).Select 'C5
 ActiveWindow.FreezePanes = True
 Zelle.Select
End With
End Sub

Gruß
Reinhard

Reinhard_fb8cb7 · 12. November 2019 um 00:28

F68 dürfte dann ausserhalb des sichtbaren Fenster liegen und
es ist nicht mehr derselbe Ausschnitt des Tabellenblatts
sichtbar wie vor dem Fixieren.

Grüezie Thomas,

ich glaube ich habe jetzt entdeckt was Rob plagt und was dieses „nach innen gerückt“ bedeutet.
Das liegt an ScreenUpdating True oder False.
Teste mal nachfolgenden Code, mal wie er ist mal ohne die Zeile
Application.ScreenUpdating=False

Im ersten Falle werden die obersten 99 Zeilen fixiert und 26 Spalten, im zweiten Fall wie gesgt Zeile 1:4 und A:B.

Gruß
Reinhard

Sub ttt()
Dim Zelle As Range
ActiveWindow.FreezePanes = False
Application.ScreenUpdating = False
With ThisWorkbook.Worksheets(1)
 .Range("AA100").Select
 Set Zelle = ActiveCell
 .Cells(5, 3).Select 'C5
 ActiveWindow.FreezePanes = True
 Zelle.Select
End With
Application.ScreenUpdating = True
End Sub

R_o_b · 12. November 2019 um 00:36

Servus Thomas,

Ich möchte Buttons im Tabellenblatt haben, die bewirken, daß
bestimmte Spalten ausgeblendet werden und daß eine bestimmte
Fixierung eingerichtet ist. Damit die Buttons failsafe sind,
müssen sie natürlich auch dann eine richtige Fixierung
liefern, wenn der User wer weiß wohin gescrollt hat.

Ja das klappt ja auch, einzig die Sichtweise aufs
Tabellenblatt ist dann nicht mehr dieselbe.

Nein, das klappt eben leider nicht. Ich schwöre Dir: Wenn die Scrollposition irgendwo weiter rechts unten ist, dann freezt Excel anders als wenn auf 1,1 gescrollt ist, und das bei identischer Markierung!!! Es ist wirklich so. Und eine nutzbringende Anwendung für dieses Verhalten fällt mir nicht ein.

Das ‚Problem‘ dabei ist dann, dass je nach eingestelltem
Bereich eben die dann sichtbaren ersten 3 Zeilen/spalten
fixiert werden.

Okay, das wäre das Workaround mit Split statt Freeze. Ist halt
nicht so elegant und für den unbedarften User vielleicht auch
problematisch.

Am Ende wird ja auch wieder mit Freeze gearbeitet - aber ich
glaube Du hast den Sinn meiner Ausführungen noch nicht so ganz
verstanden.

Achso, meintest Du: zuerst Split, dann .FreezePane, dann Split aufheben?

Wie gesagt: Für VBA ausgelöstes Fixieren ist dieses Verhalten
nicht so vorteilhaft (s. o.). Und warum dieses Verhalten
logisch notwendig sein soll, weiß ich auch nicht. Man könnte
doch einfach den Befehl

Cells(x, y).FreezePane

einfach so laufen lassen. Wenn der links/oben fixierte Bereich
zum Ausführungszeitpunkt nicht sichtbar ist, wird er eben in
den sichtbaren Bereich gezogen, der verschiebbare Bereich
rechts/unten bleibt, wo er ist.

Mich interessiert nämlich auch, wo das derzeitige Verhalten
sinnvoll anzuwenden ist, bzw. wo das von mir vorgeschlagene
Verhalten nachteilig wäre!?

Ich glaube, das ist die 50/50 Chance die jeder Programmierer
hat wenn er sich zwischen zwei Möglichkeiten entscheiden muss.

Hmm, das sehe ich anders. Wenn es 50:50 wäre, würde es sich lohnen, beide Varianten zu codieren (etwa FreezePane und FreezePane2)

Generell ist das Fixieren ein Vorgang der zu Beginn, beim
Layouten eines Tabellenblattes (oder allenfalls zwischendrin
mal) eine Rolle spielt. Warum muss das denn bei dir über
Buttons immer wieder gemacht werden?

Tja, auch wegen eines Workarounds: Ich habe ein Blatt, daß in den ersten acht Spalten links genau den Inhalt eines anderen Blattes wiedergibt. Möchte ich jetzt die Ansicht verkleinern, damit mehr Inhalt auf einmal sichtbar ist, klappt das mit dem Zeilenumbruch nicht mehr, und die Inhalte jener acht Spalten sind teilweise nicht mehr vollständig in ihren jeweiligen Zellen sichtbar, da Spalten-/Zeilengröße und Schriftgröße nicht in gleicher Proportion verändert werden (dazu gabs auch schon einen Thread). Selbst .AutoFit ändert das nicht: eine dreizeilig befüllte Zelle bei 80 %-Ansicht bewirkt bei AutoFit keine Höhenanpassung! Daher muß ich das Tabellenblatt auf andere Weise übersichtlicher machen, und so baue ich halt Knöppkens ein, die einige Spalten ausblenden (die Gliederungsbuttons sind dafür weniger gut geeignet). Das wiederum zieht die Notwendigkeit geänderter Freezes nach sich, die dann eben im Script miterledigt werden müssen.

Wie gesagt: Ich habe mir damit beholfen, indem ich die Scroll- und die Markierungspositionen (also drei Werte) speichere, vor dem Freese ein .Select durchführe und Scroll- und Markierungswerte wiederherstelle.

Bestliche Grüße
-Rob.

P. S.:
Ich finde die Ribbons extrem unpraktisch und vermisse die Möglichkeit, die Symbolleiste(n) wie auch die Icons hochfein anzupassen, und alles Einstellungen bequem abzuspeichern wie das bei MS Office bis 2003 möglich war. Schade, daß die Ribbons das alte Prinzip ersetzt, und nicht einfach nur ergänzt haben.

Thomas_Ramel · 12. November 2019 um 00:36

Grüezi Rob

Das ‚Problem‘ dabei ist dann, dass je nach eingestelltem
Bereich eben die dann sichtbaren ersten 3 Zeilen/spalten
fixiert werden.

Okay, das wäre das Workaround mit Split statt Freeze. Ist halt
nicht so elegant und für den unbedarften User vielleicht auch
problematisch.

Am Ende wird ja auch wieder mit Freeze gearbeitet - aber ich
glaube Du hast den Sinn meiner Ausführungen noch nicht so ganz
verstanden.

Achso, meintest Du: zuerst Split, dann .FreezePane, dann Split
aufheben?

Ja, genau so habe ich das gemeint und auch gezeigt.

Mich interessiert nämlich auch, wo das derzeitige Verhalten
sinnvoll anzuwenden ist, bzw. wo das von mir vorgeschlagene
Verhalten nachteilig wäre!?

Ich glaube, das ist die 50/50 Chance die jeder Programmierer
hat wenn er sich zwischen zwei Möglichkeiten entscheiden muss.

Hmm, das sehe ich anders. Wenn es 50:50 wäre, würde es sich
lohnen, beide Varianten zu codieren (etwa FreezePane und
FreezePane2)

Ja, dass Du das momentan so siehst ist mir klar und auch gut nachvollziehbar…

Generell ist das Fixieren ein Vorgang der zu Beginn, beim
Layouten eines Tabellenblattes (oder allenfalls zwischendrin
mal) eine Rolle spielt. Warum muss das denn bei dir über
Buttons immer wieder gemacht werden?

Tja, auch wegen eines Workarounds: Ich habe ein Blatt, daß in
den ersten acht Spalten links genau den Inhalt eines anderen
Blattes wiedergibt. Möchte ich jetzt die Ansicht verkleinern,
damit mehr Inhalt auf einmal sichtbar ist, klappt das mit dem
Zeilenumbruch nicht mehr, und die Inhalte jener acht Spalten
sind teilweise nicht mehr vollständig in ihren jeweiligen
Zellen sichtbar, da Spalten-/Zeilengröße und Schriftgröße
nicht in gleicher Proportion verändert werden (dazu gabs auch
schon einen Thread). Selbst .AutoFit ändert das nicht: eine
dreizeilig befüllte Zelle bei 80 %-Ansicht bewirkt bei AutoFit
keine Höhenanpassung! Daher muß ich das Tabellenblatt auf
andere Weise übersichtlicher machen, und so baue ich halt
Knöppkens ein, die einige Spalten ausblenden (die
Gliederungsbuttons sind dafür weniger gut geeignet). Das
wiederum zieht die Notwendigkeit geänderter Freezes nach sich,
die dann eben im Script miterledigt werden müssen.

OK, für graphische Ausgaben die dann erst noch konsistent sind, ist Excel halt nunmal nicht ausgelegt, da beisst keine Maus einen Faden ab.

Ich finde die Ribbons extrem unpraktisch und vermisse die
Möglichkeit, die Symbolleiste(n) wie auch die Icons hochfein
anzupassen, und alles Einstellungen bequem abzuspeichern wie
das bei MS Office bis 2003 möglich war. Schade, daß die
Ribbons das alte Prinzip ersetzt, und nicht einfach nur
ergänzt haben.

Ab xl2010 kannst Du dir wieder beliebige eigene Ribbons anlegen.
Die Zeit der Symbolleisten war wohl wirklich zu Ende und das Ganze System ausgereizt. Es gibt belegte Studien, dass Neu-Einsteiger (auch älteren Semesters) mit den neuen Ribbons erheblich besser zurecht kommen, als damals mit den Symbolleisten.
Ich denke, es ist in erster Linie eine Frage der Gewohnheit.

In 10 Jahren werden wir vermutlich zurückblicken und uns fragen wie
wir je mit dem Symbolleisten haben effizient arbeiten können…

Mit freundlichen Grüssen

Thomas Ramel

MVP für MS-Excel -

R_o_b · 12. November 2019 um 00:38

OT: Ein paar Worte zu den Ribbons
Servus Thomas,

Hmm, das sehe ich anders. Wenn es 50:50 wäre, würde es sich
lohnen, beide Varianten zu codieren (etwa FreezePane und
FreezePane2)

Ja, dass Du das momentan so siehst ist mir klar und auch gut
nachvollziehbar…

Ich bin immer dafür, Features zusätzlich zu integrieren, anstatt sich auf eines von zwei möglichen zu beschränken (siehe unten).

Ich finde die Ribbons extrem unpraktisch und vermisse die
Möglichkeit, die Symbolleiste(n) wie auch die Icons hochfein
anzupassen, und alles Einstellungen bequem abzuspeichern wie
das bei MS Office bis 2003 möglich war. Schade, daß die
Ribbons das alte Prinzip ersetzt, und nicht einfach nur
ergänzt haben.

Ab xl2010 kannst Du dir wieder beliebige eigene Ribbons
anlegen.

Eigene Ribbons? Ich bevorzuge (wie auch alle von mir befragten Kollegen) die Symbolleisten, nicht Ribbons. Im neuen Firefox wurde die Höhe der Titel-, Menü-, Symbol- und Statusleiste eigens stark reduziert, damit man mehr Platz für den Seiteninhalt hat (günstig für Netbooks), und Microsoft verschwendet viel vertikalen Platz für Layout-Vorschläge, die wie permanente Werbung wirkt („schauen Sie, was Sie alles machen könnten“). Auch bei Firefox finde ich das unhandlich, u. a. weil die nun eingeblendeten Informationen (Linkziel, Formularwerte speichern etc.) leicht fälschbar in der dargestellten Seite auftauchen. Gottlob kann man aber noch beinahe alles auf konventionelle Ansicht umstellen.

Die Zeit der Symbolleisten war wohl wirklich zu Ende und das
Ganze System ausgereizt. Es gibt belegte Studien, dass
Neu-Einsteiger (auch älteren Semesters) mit den neuen Ribbons
erheblich besser zurecht kommen, als damals mit den
Symbolleisten.
Ich denke, es ist in erster Linie eine Frage der Gewohnheit.

Genau das ist ein Irrtum! Ich kenne auch viele Menschen, die die Ribbons besser finden, das sind aber sämtlich Excel-Anfänger. Und ich gönne ihnen die Ribbons auch. Im Produktivgebrauch von Office-Software aber sind die Ribbons eindeutig von Nachteil, und das ist ebenfalls belegt, weil viele Funktionen nicht mehr direkt erreichbar sind (man muß erst das entsprechende Ribbon anwählen, dann oft auch noch in ein Untermenü gehen (suche nur einmal „Transparente Farbe bestimmen“) und für einige Funktionen muß auch noch der entsprechende Bereich in den Optionen aktiviert werden). Der hohe Grad an Konfigurierbarkeit (frei wählbare und gestaltbare Icons, mit oder ohne Text, zuweisbare Tastenkombinationen, eigene Menüs mit eigenen Tastenkombinationen ein-/ausblendbar, und all das noch in einer Datei ablegbar) hatte mich immer mit vielen Unzulänglichkeiten des MS-Office versöhnt und ich sah das als Zeichen professioneller Nutzeroberfläche an.

Jetzt ist Excel endlich funktionell erwachsen geworden (keine enge Zeilen-/Spaltenbegrenzung, mehr als drei Filter-/Bedingte-Formatierungs-Kriterien mehr etc.), aber das gut durchdachte GUI ist beim Teufel.

In 10 Jahren werden wir vermutlich zurückblicken und uns
fragen wie
wir je mit dem Symbolleisten haben effizient arbeiten
können…

Ich denke eher, daß wir in zehn Jahren begriffen haben, daß eine gute Office-Software für Einsteiger und Anfänger die Ribbons, für Produktiv-Nutzer die konfigurierbare Oberfläche vorhält. Es ist absolut nicht einzusehen, weshalb man mit der Einführung des einen Konzepts, das alte abgeschafft hat.

Aber vielleicht dauerts auch 15 Jahre, wenn man bedenkt, daß OpenOffice das Ribbon-Konzept demnächst auch zum alleinigen GUI machen will. Seufz …

Bestliche Grüße :o)
-Rob.

Thomas_Ramel · 12. November 2019 um 00:40

Grüezi Rob

Hmm, das sehe ich anders. Wenn es 50:50 wäre, würde es sich
lohnen, beide Varianten zu codieren (etwa FreezePane und
FreezePane2)

Ja, dass Du das momentan so siehst ist mir klar und auch gut
nachvollziehbar…

Ich bin immer dafür, Features zusätzlich zu integrieren,
anstatt sich auf eines von zwei möglichen zu beschränken
(siehe unten).

Dafür sein und die Zeit dazu haben sind in der ‚rauhen Wirklichkeit‘ immer zwei Paar Schuhe, die oft noch weit auseinander stehen…

…aber das soll kein Thread über MS-Gepflogenheiten werden…

Ab xl2010 kannst Du dir wieder beliebige eigene Ribbons
anlegen.

Eigene Ribbons? Ich bevorzuge (wie auch alle von mir befragten
Kollegen) die Symbolleisten, nicht Ribbons.

Nenn die Dinger wie Du willst…
Die Möglichkeit einer eigenen Gestaltung des ‚Manübandes‘ ist jedenfalls ab xl2010 wieder auf einfache Weise gegeben.

Die Zeit der Symbolleisten war wohl wirklich zu Ende und das
Ganze System ausgereizt. Es gibt belegte Studien, dass
Neu-Einsteiger (auch älteren Semesters) mit den neuen Ribbons
erheblich besser zurecht kommen, als damals mit den
Symbolleisten.
Ich denke, es ist in erster Linie eine Frage der Gewohnheit.

Genau das ist ein Irrtum! Ich kenne auch viele Menschen, die
die Ribbons besser finden, das sind aber sämtlich
Excel-Anfänger. Und ich gönne ihnen die Ribbons auch. Im
Produktivgebrauch von Office-Software aber sind die Ribbons
eindeutig von Nachteil, und das ist ebenfalls belegt, weil
viele Funktionen nicht mehr direkt erreichbar sind (man muß
erst das entsprechende Ribbon anwählen, dann oft auch noch in
ein Untermenü gehen (suche nur einmal „Transparente Farbe
bestimmen“) und für einige Funktionen muß auch noch der
entsprechende Bereich in den Optionen aktiviert werden).

Profis, die mit Tasten-Kombinationen arbeiten, haben diesen Eindruck nicht, da diese Tastenkombis alle auch in xl2007/2010 funktionieren.

Der
hohe Grad an Konfigurierbarkeit (frei wählbare und gestaltbare
Icons, mit oder ohne Text, zuweisbare Tastenkombinationen,
eigene Menüs mit eigenen Tastenkombinationen ein-/ausblendbar,
und all das noch in einer Datei ablegbar) hatte mich immer mit
vielen Unzulänglichkeiten des MS-Office versöhnt und ich sah
das als Zeichen professioneller Nutzeroberfläche an.

Wie gesagt, kannst Du solches wieder tun - für xl2007 hat es offenbar nicht gereicht diese (einfache) Konfigurierbarkeit wieder anzubieten, aber ab xl2010 steht das wieder zur Verfügung.

Für Office 2007 sind da in der Zwischenzeit aber auch mehrere AddIns entwickelt worden, welche dies auch wieder möglich machen.

In 10 Jahren werden wir vermutlich zurückblicken und uns
fragen wie
wir je mit dem Symbolleisten haben effizient arbeiten
können…

Ich denke eher, daß wir in zehn Jahren begriffen haben, daß
eine gute Office-Software für Einsteiger und Anfänger die
Ribbons, für Produktiv-Nutzer die konfigurierbare Oberfläche
vorhält. Es ist absolut nicht einzusehen, weshalb man mit der
Einführung des einen Konzepts, das alte abgeschafft hat.

Ja, nach Möglichkeit beide Teile des 50/50 Jokers pflegen, gell…

Lassen wirs gut sein - wir werden diese Entwicklung nicht beeinflussen oder gar aufhalten können. Aber wenn ich auch in 10 Jahren die Applikationen noch bedienen können will, muss ich mich mit der neuen Oberfläche ‚anfreunden‘, oder ich treffe bewusst die Entscheidung, das bleiben zu lassen und xl2003 nicht zu verlassen (was aber eigentlich auch schade ist).

Mit freundlichen Grüssen

Thomas Ramel

MVP für MS-Excel -