Rechenblatt : eine besondere Ebene vorn, BIS

Hallo Jacques

Es ist konsequent, dass du in einem von einer Stammseite abhängigen Layout nichts ändern kannst, was auf der Stammseite definiert ist. Es ist deshalb logisch, dass dein Versuch, im abhängigen Layout die Lage des Rechenblatts zu ändern, welches auf der Stammseite definiert ist, zur besagten Meldung führen muss: "Komponenten, die von Stammseiten stammen, können nicht geändert werden. Wollen Sie mit einem unabhängigen Duplikat weitermachen?"

Was dagegen unlogisch ist: Die angezeigte Lage des Rechenblatts im abhängigen Layout ändert sich nicht, wenn die angezeigte Lage auf der Stammseite gewechselt wird - wie du selbst festgestellt hast. Das riecht ein wenig nach "Bug"!

Mit Klick auf "Duplizieren" in der besagten Meldung bleibt die Seite zwar von der Stammseite abhängig, ausser dass im betreffenden Container eine Kopie des Rechenblatts, welches auf auf der Stammseite installiert ist, angelegt wird. Selbst eine Veränderung der Koordinaten des Containers mit dem Rechenblatt auf der Stammseite wird im Layout nachvollzogen. Du wirst deshalb mit zwei verschiedenen Rechenblättern arbeiten - mit dem auf der Stammseite und demjenigen im sonst abhängigen Layout. Diese sind zwar (wenigstens im Moment des Duplizierens) identisch. Spätere Änderungen beeinflussen aber das jeweils andere Rechenblatt nicht. Das könnte höchstens damit erreicht werden, dass die Zellinhalte mittels Formeln (oder einer einzigen Suchlaufformel) von einem Rechenblatt ins andere übertragen würden. Für Füllungen lässt sich das aber nicht machen und auch nicht für die Art des Zelleninhalts (Auto/Text/Mehrzeiler), nur für die Zelleninhalte selbst. Damit du nicht mit diesem Problem konfrontiert bist, hast du dich entschieden, das ursprünglich auf der Stammseite installierte Rechenblatt zu löschen.

Eigentlich hast du damit das gemacht, was mit den Stammseiten eigentlich das normale Vorgehen ist: Auf den Stammseiten werden nur diejenigen Objekte und Komponenten angelegt, die auf den abhängigen Seiten genau so übernommen und dort auch nie geändert werden sollen. Der direkte Weg wäre gewesen, den Rahmen für das Rechenblatt zwar auf der Stammseite anzulegen, aber mit "Kein Inhalt" zu belassen und erst im abhängigen Layout den Rahmen zu einem Container mit Inhalt "Rechenblatt" zu machen.

Gruss, Thomas

Das hat zwar eine gewisse Logik, aber:

wenn ich z. B. sicher weiß, dass an dieser Stelle des Layouts ein Rechenblatt stehen soll, und wenn ich insbesondere weiß, dass es z. B. bestimmte Spaltenbreiten besitzen soll (von bestimmten vorgegebenen Formeln wie D? = A?*B?*C? usw. ganz zu schweigen), dann ist es doch das naheliegenste, diese Einstellungen auf ein Stammlayout zu schieben - aber auch dann: Werteeingabe unmöglich.

Ich kann mir aber sehr gut z. B. ein Raumbuch vorstellen, in dem für ein größeres Gebäude sämtliche Räume in einheitlichem Layout mit teils textlichen, teils rechnerischen und auch mit logisch verknüpften Informationen - also optimal z. T. in einem Rechenblatt - dargestellt werden. Die Aufnahme neuer Daten (deren Relevanz anfangs noch nicht zu erkennen war) oder die Veränderung von Daten (mit z. B. zunehmend länger werdenden Texten) mag irgendwann eine Anpassung des Stammlayoutes erfordern.
Solange ich diesen Änderungsaspekt außer acht lasse, ist copy+paste sicher eine legitime Lösung (mit Schutz einzelner Zellen), kleinere Layoutveränderungen können dann sicher auch noch gut integriert werden (Verschieben von Rechenblättern z. B., aber bitte kein Verbreitern...)
Aber dann ist sense.

Nun gut, ich sehe auch ein, dass man hier mit solchen Überlegungen sehr, sehr tief in den Grundstrukturen eines Programmes arbeitet. So etwas ist schwer umzusetzen - leere Zellen innerhalb eines Stammlayoutes anders zu behandeln als gefüllte.
Und abgesehen davon ist anzunehmen, dass einige Cracks hier ohnehin eine Umgehungsstraße kennen.

Irgendwie ist dieses RagTime super, weil man wirklich sehr, sehr viel damit machen kann. Wir denken indes darüber nach - nicht zuletzt wegen der guten Einbettung und Formatierbarkeit von Rechenblättern - die ganze Firma damit auszustatten. Dann alllerdings kann das mit dem Handling eine doch etwas diffizile Sache werden... (Ich dag nur mal Rückwärts-Button, das schreckt einfach ab. Man würde ein Protokoll erwarten, dass nebenbei auch Einstellungen, nicht nur Eingaben berücksichtigt...)

Mal sehen.

Hallo Gerald,

das Problem, das Du im ersten Absatz beschreibst, ist der Grund, weshalb man einem Container in einem Stammlayout sagen kann, dass auf abhängigen Seiten automatisch eine Kopie der Komponente angelegt werden soll. (»Zeichnungsinformation - Objekte«, dort »Abhängigkeit - Kopie der Komponente in abhängigem Container anlegen«.)

Dann ist eine Tabelle im Stammlayout nur eine Vorlage, die Formatierungen und Formeln enthalten kann, die Kopien im Layout aber können geändert werden.

Das mit dem »leere Zellen … anders zu behandeln als gefüllte« ist in der Tat ein Problem, das ganz unten in der RagTime-Konzeption steckt: Komponenten, die in zwei Containern installiert sind (z.B. im Stammlayout und im Layout) sind im ganz strikten Sinn dieselbe Komponente und existieren auch nur einmal in der Datei. Du siehst dasselbe Rechenblatt im Stammlayout-Fenster und im Layout-Fenster (und wenn Du die Komponente im eigenen Fenster öffnest - wo sie übrigens bearbeitet werden kann - dann in einem dritten).

Das eingangs in diesem Thread von Jacques ist natürlich wirklich inkonsistent: Entweder muss die Lagenwahl im Stammlayout auf das Layout durchschlagen, oder aber sie muss im Layout änderbar sein.

Gruß

www.j-schell.de

Hallo Gerald

Ich kann deinen Überlegungen nicht so ganz folgen, frage mich aber, ob du das Konzept des Stammlayouts ganz verstanden hast. Ein Stammlayout ist primär für die fixe Anordnung von Objekten in allen abhängigen Layouts gedacht, mit der Möglichkeit, diese Anordnung auf allen abhängigen Seiten mit einer einzigen Änderung (eben im Stammlayout) zu bewirken. In den allermeisten Fällen finden sich also im Stammlayout nur folgende Objekte:
- Leere Rahmen - erst im abhängigen Layout wird festgelegt, was sich in jedem Rahmen befindet
- Fixe Texte und Grafiken, z.B. Logos und Firmennamen
- Variable Texte (vielfach in Kopf- oder Fusszeilen - ausschliesslich mit Textwerkzeug "A" erstellt!), die auf allen abhängigen Seiten mit der gleichen (typisch - aber nicht zwingend - von der Seitennummer und/oder einem Datum abhängigen) Formel berechnet werden.

Ein Rechenblatt, das auf verschiedenen Seiten vorkommen soll, wird auf einer Seite erzeugt (möglicherweise in einem Rahmen, der im Stammlayout, von dem die Seite abhängt, angeordnet wurde) und dann aus dem Inventar in den (gleichen) Rahmen auf den anderen Seiten gezogen, so dass es auf allen diesen Seiten ein und dasselbe Rechenblatt ist. So ist eine in diesem Rechenblatt gemachte Änderung - egal ob Spaltenbreite, Zeilenhöhe, Zellinhalt oder irgend eine Formatierung - sofort auch auf allen anderen Seiten vorhanden. In einem solchen Rechenblatt können natürlich Zellen geschützt sein. Was natürlich nicht möglich ist: Formeln die von der Seite abhängen - da das identische Rechenblatt auf mehreren Seiten steht kann RagTime eine solche Formel nicht berechnen und das Ergebnis ist deshalb zwingend ein NV!-Fehler.

Wenn nur die Dimensionierung der Zeilen/Spalten auf allen Layoutseiten identisch sein soll, dann ist im Prinzip das gleiche Vorgehen sinnvoll. Auf jeder Seite wird dann aber eine Lage zum Rechenblatt hinzugefügt. Jetzt können die Zellen auf jeder Seite völlig unabhängige Inhalte haben. Natürlich können sich Formeln in allen Lagen auf zentrale Basiswerte beziehen, die vielleicht in Lage 1, oder aber in einem anderen Rechenblatt festglegt werden. Zu beachten ist, dass auch in diesem Fall von der Seitennummer abhängige Formeln einen NV!-Fehler ergeben. Denn auf jeder Seite liegt das ganze Rechenblatt, ausgewählt ist lediglich, welche Lage des Rechenblatts auf dieser Seite sichtbar ist. Um das zu vermeiden muss die Formel stattdessen von der Lage abhängig gemacht werden, was möglich ist, da ja bekannt ist, auf welcher Seite welche Lage zu sehen ist.

Eine interessante Möglichkeit besteht auch noch darin, zwei gleich dimensionierte Rechenblatt-Container hintereinander zu legen, wobei der vordere eine transparente Füllung haben muss. Wenn im hinteren Container z.B. Lage 1 eines Rechenblattes liegt und im vorderen eine beliebige Lage des gleichen Rechenblatts (alle Zellen, durch welche hindurch die Lage 1 sichtbar sein soll, müssen auch transparente Füllung haben), so sind alle Werte von Lage 1 ohne zusätzliche Formeln sofort auf allen Seiten sichtbar und in der vorne liegenden Lage können auf jeder Seite verschiedene Werte eingegeben oder berechnet werden. In diesem Fall könnte der hintere Rahmen sogar bereits im Stammlayout mit Inhalt Rechenblatt versehen werden. Die Werte von Lage 1 lassen sich dann nur im Stammlayout verändern, während die Zellen in den übrigen Lagen im Layout verändert werden können.

Gruss, Thomas

Hallo Thomas,

klar ist das Stammlayout eben gerade so konstruiert, dass sich darauf v. a. Layout-komponenten und Seitenabhängige Dinge, insbsd. Zählungen befinden.

Was die Rechenblätter betrifft:

Das Arbeiten mit einer Standard-Stammlayout-Layout-Hintergrund-Rechentabelle zum Formatieren und einer Tabelle, die jeweils als Dublikat erstellt wird, mit Transparenzen ist jedenfalls ein gewichtiger Schritt.
Damit lassen sich schon viele Punkte lösen. Aber bei Änderungen, die über die Anordnung der Tabelle oder deren Farben hinausgehen, muss man natürlich jede bereits existente neu konfigurieren: z. B. Spaltenbreite, andere Konstante, neues Berechnungsverfahren.

Ein und das selbe Rechenblatt einfach im INventar anzulegen und mehrmals auf verschiedene Seiten anzuwenden scheint mir dabei wenig sinnvoll: Sofern ich nicht etwas explizit falsch verstanden haben sollte bei meinem Nachahmen, dann wirkt sich hier auch eine Eingabe einer Zahl auf alle Seiten aus. Also nicht nur Berechnung und Layout sondern auch Dateninhalt bleiben sich gleich.

Interessant finde ich nun die Idee mit den Lagen. Dazu habe ich ein wenig experimentiert, finde aber in der (schließlich sehr guten) Funtkionssammlung nur "Lage", d. h. die Lage der aktuellen Zelle.
Wie aber kann ich die Befehle so kombinieren, dass ein ich sage einmal "aktuelle_Lage" sich nicht auf die Zelle, sondern auf die Anzeige bezieht?.
Ich denke in Richtung von:

[x]A3: manuelle Dateneingabe für jeweilige Lage (wobei man per Hand einstellt, dass jeweils [x] "=" Seite wäre).

[1]B3=Das hinterlegte Berechnungsverfahren, z. B. [1]B3=[aktuelle_Lage]A3*2,55-1,38

[x]C3=[1]B3

So scheitert das natürlich, weil ich eine Zelle als Durchlaufformel missbrauchen würde. Aber Sinn soll natürlich sein, dass ich eine Formel, die ich auf 100 Seiten anwenden möchte nur einmal hinterlegen möchte und nur einmal ändern und dann zumindest ähnlich einfach übertragen, wie man z. B. zeilenweise durch simples Ziehen sämtliche Formeln überträgt.

Oder ist dieses Ziehen die Lösung? kann man irgendwie von "Draufsicht" auf "Ansicht" der Tabelle wechseln quasi? Wäre ja super!

Als Lösungsansatz kommt mir ansonsten gerade während dem Tippen:
Auf der Layout-Seite stehen zwei(oder mehr) 1*1-Rechenblätter: Eingabewerte und Ausgabewerte, Position und Aussehen nach Stammlayout.
Irgendwo im Inventar aber auf keiner Seite liegt dann die 2D-Tabelle in Form A7 = Wert A1 vom Rechenblatt Eing. von Seite 7. B7 = daraus (und ggfs. aus weiteren Zellen) gerechneter Wert, sprich Formel, die per Ziehen leicht auf Zeilen 8-99 übertragen werden kann.
Auf Seite 7 im Ausgaberechenblatt steht dann quasi: A1 = Wert B7 vom zentralen Rechenblatt.
Abgesehen davon, dass ich mich dann aber noch ins gegenseitige Referenzieren einlesen muss (v. a. richtige Schreibweise), stellt sich natürlich die Frage, ob sich die in der Folge 201 Rechenblätter namenstechnisch gut organisieren kann, und was passiert, wenn ich zwischen Seite 7 und Seite 8 eine neue Seite einfügen will, im Inventar aber ReBl_Eing_007 und ReBl_Eing_008 schon vergeben sind, oder ob man hier gar irgendeine Automatisierung austüfteln kann. Und nachdem ich das irgendwie hinbekommen hätte, ob dann noch irgendjemand damit arbeiten kann....

Ganz frech würde ich nun behaupten, dass "ohne Inhalt" sich eigentlich logisch auf "leere Zelle" übertragen ließe und - softwaretechnisch schwierig - bedienungstechnisch super wäre.
Aber andererseits ist mir klar, dass das fast schon exotische Forderungen an eine ohnehin schon fast eierlegende Wollmilchsau sind.
Wenn dieses Nutztierchen mal ein paar Schritte mehr rückwärts laufen könnte, wären schon wichtigere Punkte erledigt...

Gerald

Hallo Gerald

So scheitert das natürlich, weil ich eine Zelle als Durchlaufformel missbrauchen würde. Aber Sinn soll natürlich sein, dass ich eine Formel, die ich auf 100 Seiten anwenden möchte nur einmal hinterlegen möchte und nur einmal ändern und dann zumindest ähnlich einfach übertragen, wie man z. B. zeilenweise durch simples Ziehen sämtliche Formeln überträgt.

Zu deinem Vorbehalt zwei Kommentare:

1. Zwar nicht durch Ziehen, aber doch sehr einfach lässt sich eine Formel über alle Lagen kopieren.

Annahme: In Zelle C1 von Lage 1 stehe die Formel

A1*[$1]$B$1

so kopiert man diese Formel wie folgt in die Zellen C1 aller übrigen Lagen:
- Zelle C1 in Lage 1 auswählen und in Zwischenablage kopieren
- mit gedrückter Umschalttaste in der Werkzeugleiste (oder im Rechenblattmenü/Lage) die letzte Lage auswählen
- Einsetzen
Wie im zweidimensionalen Rechenblatt werden bei diesem Kopieren/Einsetzen alle relativen Adressteile (im Beispiel also "A1") relativ bleiben und die absoluten (im Beispiel also "[$1]$B$1") absolut.

2. Alternativ geht es mit einem Suchlauf, also einer Formel in nur einer einzigen Zelle. Diese Formel lautet, wenn das Rechenblatt 5 Lagen hat:

Suchlauf(A1:[5]A1;1;0;SetzeZelle([$1]$B$1*LfdZelle;C1:[5]C1;LfdIndex))

Diese Formel kann in irgend einer Zelle in Lage 1 liegen, z.B. in Zelle D1. Allerdings hat sie gegenüber normalen Suchläufen einen gewichtigen Nachteil: Während bei einem VSuchlauf der Suchbereich offen definiert, z.B. die ganze Spalte A, und mit der Bedingung, z.B. LfdZelle≠'', auf die genutzte Tabelle eingeschränkt werden kann, muss beim Suchlauf über Lagen die höchste Lage explizit angegeben werden. Wird hier einfach eine sehr hohe Zahl gewählt, so wird automatisch die entsprechende Anzahl Lagen erzeugt. Allerdings gibt es auch hier - mit der RagTime-Erweiterung "MetaFormel-Funktionen" - eine Ausweichmöglichkeit. So könnte in Zelle E1 die Anzahl Lagen angegeben werden. Die Formel in Zelle D1 würde dann heissen:

RechneText('Suchlauf(A1:['&E1&']A1;1;0;SetzeZelle([$1]$B$1*LfdZelle;C1:['&E1&']C1;LfdIndex))')

Stolperstein: Damit die Textformel sicher berechnet wird, muss eine neue Lage zuerst erzeugt und die für die Lage spezifischen Werte (im Beispiel in Zelle A1) eingegeben werden, bevor die neue Lagenzahl in Zelle E1 eingegeben wird. Die Berechnung kann natürlich auch mit "Alles rechnen" erzwungen werden. Mit Vorteil wird dieser Befehl mit einem Knopf ausgelöst – er wird so weniger vergessen.

Gruss, Thomas

Das mit dem Suchlauf ist ein sher guter Tipp, danke.

das Einfügen mit Umschalttaste erbrachte leider nicht den erwünschten Erfolg. Ich kann mir auch kaum vorstellen, dass das an Windows liegt, denn dort hat die Umschalttaste ja uch diese "von-bis"-Bedeutung.

Ich frage mich gerade, ob man in Ragtime - oder ggfs. anderen Tabellenkalkulationen - ggfs. auch Funktionen global oder Dokumentintern definieren kann. Das wäre doch an sich auch interessant.

Gerald

Das mit dem Suchlauf ist ein sher guter Tipp, danke.

das Einfügen mit Umschalttaste erbrachte leider nicht den erwünschten Erfolg. Ich kann mir auch kaum vorstellen, dass das an Windows liegt, denn dort hat die Umschalttaste ja uch diese "von-bis"-Bedeutung.

Ich frage mich gerade, ob man in Ragtime - oder ggfs. anderen Tabellenkalkulationen - ggfs. auch Funktionen global oder Dokumentintern definieren kann. Das wäre doch an sich auch interessant.

Gerald

Hallo Gerald

das Einfügen mit Umschalttaste erbrachte leider nicht den erwünschten Erfolg. Ich kann mir auch kaum vorstellen, dass das an Windows liegt, denn dort hat die Umschalttaste ja uch diese "von-bis"-Bedeutung.

Bei mir funktioniert die Auswahl über mehrere Lagen mit der Umschalttaste auch unter Windows (XP) perfekt.

Mach mal den folgenden Versuch:
1. Neues Dokument - "Urrahmen" löschen
2. Links auf der Seite einen kleinen Rahmen aufziehen
3. Inhalt: Rechenblatt (dadurch wird der Rahmen zum Container)
4. Daneben einen zweiten, etwa gleich grossen Rahmen aufziehen
5. Aus dem Inventar das "Rechenblatt 1" in diesen Rahmen ziehen
6. In Zelle A1 die Formel "Lage" eingeben (egal in welchem der beiden Container)
Jetzt siehst du in beiden Containern das gleiche Rechenblatt. In beiden steht in Zelle A1 eine 1, weil es sich in beiden Containern um Lage 1 des gleichen Rechenblatts handelt.
7. Öffne die Objektkoordinatenpalette
8. Klick im zweiten Rahmen irgendwo ins Rechenblatt und hänge zwei Lagen an (NB: Zelle A1 ist in diesem Container jetzt leer!)
9. Wähl im ersten Container Zelle A1 aus
10. Kopieren
11. Mit gedrückter Umschalttaste klickst du in Zelle A1 des zweiten Containers
Jetzt siehts du im obersten Feld der Objektkoordinatenpalette die Anzeige des ausgewählten Bereichs: A1:[3]A1
12. Einsetzen
Jetzt steht in Zelle A1 des rechten Containers eine 3, weil die Formel eben in den ganzen Bereich [1]A1:[3]A1 eingesetzt wurde. Du kannst auch mit dem Lagenselektor in der Werkzeugleiste zu Lage 2 wechseln und wirst feststellen, dass dort erwartungsgemäss eine 2 steht.

Fazit: Ein ausgewählter Bereich ist, wenn er mehrere Lagen umfasst, nicht immer an der Markierung erkennbar, wohl aber aufgrund der Angabe in der Objektkoordinatenpalette!

Gruss, Thomas