Writer/Calc: echte relative Referenzierung in Tabelle

de-users
#1

Hallo,

ich schlage mich gerade mit einem Problem herum, für das ich bisher
keine saubere Lösung finden konnte. Sicherlich kann mir hier jemand auf
die Sprünge helfen. Dafür schon im voraus vielen Dank!

Aufgabe:
In einer Writer-Vorlage gibt es eine Tabelle mit Platzhaltern in einer
Zeile, die von einem externen Programm in benötigter Anzahl kopiert und
mit Daten gefüllt wird (die Zeile, nicht die Tabelle) [1]. Oberhalb
dieser Zeile und auch direkt darunter stehen feste Daten bzw Formeln,
die Berechnungen anhand der eingefügten Daten vornehmen. Also etwa so:

        SpalteA | SpalteB
Zeile1: NAME | ANZAHL
Zeile2: <name> | <cnt>
Zeile3: Summe: | sum(<B2>:<B2>)

Problem:
Die Vorlage weiss nicht, wie viele Zeilen eingefügt werden. Mal wird nur
eine Zeile genutzt, es können aber auch ein Dutzend oder mehr Zeilen
eingefügt werden. Den Beginn der Summenfunktion kann ich dabei noch
direkt adressieren, doch das Ende bekomme ich nicht zu fassen. Rein
logisch betrachtet ist es "die Zelle oberhalb der aktuellen Zelle". Doch
die angebliche relative Referenzierung ist ja faktisch eine absolute
Referenzierung, die bei Verschiebeoperationen mitgezogen wird. Da Writer
in Bezug auf die Tabellenfunktionen extrem begrenzt ist, habe ich auch
versucht, das Problem direkt in Calc zu lösen.

Folgendes habe ich getestet:

1) relative Referenzierung: sum(<B2>:<B2>)
Dies wird beim Einfügen weiterer Zeilen nicht erweitert, sondern
mitgezogen. Dies war auch absehbar, da LO nicht weiss, dass es die eine
Referenz belassen und die andere mitziehen soll.

2) relative + absolute Referenzierung: summe($B$2:B2)
Diese Möglichkeit aus Calc bietet Writer offenbar nicht an. Doch auch in
Calc wird diese Referenzierung nicht erweitert, sondern es werden beide
Referenzen mitgezogen.

3) Eine Adressierung über eine benannte Zelle funktioniert sowieso
nicht, da dies entweder die Überschrift wäre oder die zu kopierende
Zelle mit dem Platzhalter. Beides ist hier sinnlos.

4) Adressierung über VERSCHIEBUNG() in Calc
Da die Adressierung einer Zelle mitgezogen wird, dachte ich, ich könnte
die erste Zelle per VERSCHIEBUNG() referenzieren. Das funktioniert sogar
recht gut. Die Funktion "=SUMME(VERSCHIEBUNG(D2;1;0):D3)" wird beim
Einfügen zweier Zeilen geändert in "=SUMME(VERSCHIEBUNG(D2;1;0);D5)".
Leider gibt es die Funktion in Writer nicht.

Kennt jemand eine Lösung für Writer, die diese Aufgabe erledigen kann?
Mir geht es nicht speziell um VERSCHIEBUNG(), sondern um die
Aufsummierung einer unbekannten Anzahl von Zeilen.

System:
LMDE 64bit, LO 4.4.0.1, deutschsprachige Oberfläche

[1] Das Programm greift per UNO-Schnittstelle auf LO zu und geht dabei
folgendermaßen vor: die Zeile mit den Platzhaltern wird kopiert und
anschließend zeilenweise in benötigter Anzahl oberhalb der vorhandenen
Zeile eingefügt. Dann werden die Platzhalter durch die entsprechenden
Daten ersetzt.

Gruß
Ben

#2

ich schlage mich gerade mit einem Problem herum, für das ich bisher
keine saubere Lösung finden konnte. Sicherlich kann mir hier jemand auf
die Sprünge helfen. Dafür schon im voraus vielen Dank!

Aufgabe:
In einer Writer-Vorlage gibt es eine Tabelle mit Platzhaltern in einer
Zeile, die von einem externen Programm in benötigter Anzahl kopiert und
mit Daten gefüllt wird (die Zeile, nicht die Tabelle) [1]. Oberhalb
dieser Zeile und auch direkt darunter stehen feste Daten bzw Formeln,
die Berechnungen anhand der eingefügten Daten vornehmen. Also etwa so:

        SpalteA | SpalteB
Zeile1: NAME | ANZAHL
Zeile2: <name> | <cnt>
Zeile3: Summe: | sum(<B2>:<B2>)

Problem:
Die Vorlage weiss nicht, wie viele Zeilen eingefügt werden. Mal wird nur
eine Zeile genutzt, es können aber auch ein Dutzend oder mehr Zeilen
eingefügt werden. Den Beginn der Summenfunktion kann ich dabei noch
direkt adressieren, doch das Ende bekomme ich nicht zu fassen. Rein
logisch betrachtet ist es "die Zelle oberhalb der aktuellen Zelle". Doch
die angebliche relative Referenzierung ist ja faktisch eine absolute
Referenzierung, die bei Verschiebeoperationen mitgezogen wird. Da Writer
in Bezug auf die Tabellenfunktionen extrem begrenzt ist,

Yepp; in Writer ist es wohl das sinnvollste, nicht Zeilen /einzufügen/,
sondern einfach von vornherein eine /fixe/ (maximale) Anzahl Zeilen zur
Verfügung zu stellen. Evtl. kannst Du dann im Nachhinein sogar noch die
Höhe der leeren Zeilen auf Null setzen o. ä., dann hast Du quasi, was Du
willst (nur von hinten her aufgezogen).

3) Eine Adressierung über eine benannte Zelle funktioniert sowieso
nicht, da dies entweder die Überschrift wäre oder die zu kopierende
Zelle mit dem Platzhalter. Beides ist hier sinnlos.

Und wenn Du jeweils eine Leerzeilen einfügst, in denen sich die
benannten Zellen befinden? Dies Hilfszeilen kannst Du ja notfalls
ausblenden (Zeile markieren, Tabelle => Tabelleneigenschaften =>
Umrandung => Abstand zum Inhalt: 0; Format => Zeichen => Schrifteffekt
=> [X] Ausgeblendet; ist aber unschön, weil man irgend wann vergisst,
dass da ein ausgeblendeter Text existiert).

Kennt jemand eine Lösung für Writer, die diese Aufgabe erledigen kann?
Mir geht es nicht speziell um VERSCHIEBUNG(), sondern um die
Aufsummierung einer unbekannten Anzahl von Zeilen.

Nein; das Problem ist, dass Writer ein Textverarbeitungsprogramm und
kein Tabellenverarbeitungsprogramm ist. Tabellen und Formeln sind da nur
sehr rudimentär vorhanden, und letztere werden bei Änderungen nicht
wirklich gut angepasst; das musst Du im Prinzip jedes mal selber machen.

Wolfgang

#3

Problem:
Die Vorlage weiss nicht, wie viele Zeilen eingefügt werden. Mal wird nur
eine Zeile genutzt, es können aber auch ein Dutzend oder mehr Zeilen
eingefügt werden. Den Beginn der Summenfunktion kann ich dabei noch
direkt adressieren, doch das Ende bekomme ich nicht zu fassen. Rein
logisch betrachtet ist es "die Zelle oberhalb der aktuellen Zelle". Doch
die angebliche relative Referenzierung ist ja faktisch eine absolute
Referenzierung, die bei Verschiebeoperationen mitgezogen wird. Da Writer
in Bezug auf die Tabellenfunktionen extrem begrenzt ist,

Yepp; in Writer ist es wohl das sinnvollste, nicht Zeilen /einzufügen/,
sondern einfach von vornherein eine /fixe/ (maximale) Anzahl Zeilen zur
Verfügung zu stellen. Evtl. kannst Du dann im Nachhinein sogar noch die
Höhe der leeren Zeilen auf Null setzen o. ä., dann hast Du quasi, was Du
willst (nur von hinten her aufgezogen).

Eine bestimmte Zeilenanzahl vorzugeben wäre zwar möglich, aber dann
müsste es eher so laufen, dass diese von vornherein auf unsichtbar
gesetzt sind und dann durch den Inhalt erst sichtbar werden. Die Anzahl
müsste aber, um auf der sicheren Seite zu sein, eher bei hunderten
anstatt bei dutzenden liegen. Insgesamt keine schöne Lösung.

3) Eine Adressierung über eine benannte Zelle funktioniert sowieso
nicht, da dies entweder die Überschrift wäre oder die zu kopierende
Zelle mit dem Platzhalter. Beides ist hier sinnlos.

Und wenn Du jeweils eine Leerzeilen einfügst, in denen sich die
benannten Zellen befinden? Dies Hilfszeilen kannst Du ja notfalls
ausblenden (Zeile markieren, Tabelle => Tabelleneigenschaften =>
Umrandung => Abstand zum Inhalt: 0; Format => Zeichen => Schrifteffekt
=> [X] Ausgeblendet; ist aber unschön, weil man irgend wann vergisst,
dass da ein ausgeblendeter Text existiert).

Leere Zeilen wären tatsächlich eine Variante. Allerdings habe ich jetzt
gar nicht geschaut, ob ich in Writer a) eine einzelne Zelle benennen
kann (ich weiss nur, dass Tabellen benannt werden) und b) dann diese
benannte Zelle referenzieren kann. In Calc sollte das problemlos möglich
sein.

Kennt jemand eine Lösung für Writer, die diese Aufgabe erledigen kann?
Mir geht es nicht speziell um VERSCHIEBUNG(), sondern um die
Aufsummierung einer unbekannten Anzahl von Zeilen.

Nein; das Problem ist, dass Writer ein Textverarbeitungsprogramm und
kein Tabellenverarbeitungsprogramm ist. Tabellen und Formeln sind da nur
sehr rudimentär vorhanden, und letztere werden bei Änderungen nicht
wirklich gut angepasst; das musst Du im Prinzip jedes mal selber machen.

Und eben diese historisch bedingte Trennung der Funktionalitäten kann
ich heute nicht mehr ganz nachvollziehen. Klar wäre es ein enormer
Aufwand, alle Funktionen zentral zu sammeln und je nach Oberfläche die
wichtigeren hervorzuheben. Aber letztlich spricht doch nichts dagegen,
in einer Tabelle in einem Textdokument die gleichen Funktionen zur
Verfügung zu haben wie in einer Tabellenkalkulation. Genauso wie es
möglich sein sollte, in einem Textfeld in einer Tabelle alle
Formatierungs- und Gliederungsoptionen einer Textverarbeitung zur
Verfügung zu haben.

Gruß
Ben

#4

Das geht prinzipiell auch; Du musst nur einen Bereich einer
Tabellenkalkulation Kopieren und in das Textdokument kopieren; das wird
dann dort defaultmäßig als Embedded Object eingebunden. Ich bezweifle
nur, dass Deine Importfunktion dann damit klar kommt ...

Aber möglicherweise wäre das trotzdem eine Überlegung wert. Von Calc aus
kann man ja auf externe Datenquellen zugreifen. Vielleicht sind ja auch
diese Sourcen von Calc einlesbar?

Unabhängig davon: Eine Eierlegende Wollmilchsau, wie Du sie Dir
vorstellst, krankt in der Regel daran, dass sie so überladen mit
Funktionen und Möglichkeiten ist, dass kein Schwein mehr sie bedienen kann.

Wolf 'das ist das grundlegende Problem der Featuritis' gang

#5

Und eben diese historisch bedingte Trennung der Funktionalitäten kann
ich heute nicht mehr ganz nachvollziehen. Klar wäre es ein enormer
Aufwand, alle Funktionen zentral zu sammeln und je nach Oberfläche die
wichtigeren hervorzuheben. Aber letztlich spricht doch nichts dagegen,
in einer Tabelle in einem Textdokument die gleichen Funktionen zur
Verfügung zu haben wie in einer Tabellenkalkulation.

Das geht prinzipiell auch; Du musst nur einen Bereich einer
Tabellenkalkulation Kopieren und in das Textdokument kopieren; das wird
dann dort defaultmäßig als Embedded Object eingebunden. Ich bezweifle
nur, dass Deine Importfunktion dann damit klar kommt ...

Diese OLE-Krücke hat mich schon vor 20 Jahren mit MS-Office und auch
Star-Office zur Verzweiflung getrieben. Mit OOo und LO ist es leider
nicht besser geworden. Es ist ein Behelf, aber keine Lösung.
Meine Meinung.

Aber möglicherweise wäre das trotzdem eine Überlegung wert. Von Calc aus
kann man ja auf externe Datenquellen zugreifen. Vielleicht sind ja auch
diese Sourcen von Calc einlesbar?

Unabhängig davon: Eine Eierlegende Wollmilchsau, wie Du sie Dir
vorstellst, krankt in der Regel daran, dass sie so überladen mit
Funktionen und Möglichkeiten ist, dass kein Schwein mehr sie bedienen kann.

Jetzt wird es reichlich OT, daher nur kurz: das Problem ist nicht die
Anzahl der Funktionen, denn die sind auch jetzt vorhanden. Wenn es zu
viele sind, sind es JETZT zu viele. Die Entwickler scheitern i.d.R.
daran, diese Funktionen intuitiv zu verpacken. Meterlange Menüs und
achtmal verschachtelte Optionenfenster kann jeder Depp zusammenklöppeln.
Was fehlt, ist die intuitive, logische und auf das aktuell notwendige
reduzierte Umgebung. Ein kleiner Schritt in diese Richtung ist z.B. die
Ausblendung der Tabellenoptionen in Writer, wenn keine Tabelle
ausgewählt ist. Apple soll in der Richtung einiges bewirkt haben, aber
das sind für mich nur Gerüchte, da ich mit OS X nichts zu tun habe.

Gruß
Ben

P.S.: Mein bevorzugtes Tool, wenn ich mich auf Text-Schreiben
konzentrieren will, ist Focuswriter. Ein OOo Ableger mit einer
standardmäßig leeren, bildschirmfüllenden Seite. Herrlich ablenkungslos!