Danke für deine Antwort, Stephan!
Stephan hat geschrieben:
Ich würde versuchen die Formelausdrücke durch Stringbearbeitung aufzulösen, wie aufwändig das wird kann ich schwer einschätzen, andererseits ist aber durchaus überschaubar was alles auftreten kann und auch die Klammersetzung ist eindeutig aufzulösen.
An die Stringauswertung hatte ich auch schon gedacht, aber ich würde das eher als Notlösung sehen.
Stephan hat geschrieben:
Im Beispiel 2 kann ich mit "com.sun.star.sheet.XFunctionAccess, callFunction()" den Wert der inneren Funktion (PRODUKT) berechnen.
Aber wie bekomme ich überhaupt die Argumente der äußeren Funktion (SUMME), sodass ich die innere Funktion auswerten kann?
Na das ist doch einfach, WENN Du bereits das Produkt berechnen kannst ist das Ergebnis dieser Berechnung einer der Parameter von SUM und der zweite Parameter/Summand ist die 8 - oder ich verstehe die Frage falsch.
Jein. Der Folgepfeil geht in die andere Richtung: WENN ich das Argument habe und es ist eine Formel (also im Bsp PRODUKT), DANN kann ich sie berechnen, da ich die Funktion zum Berechnen kenne (callFunction()). Aber dazu muss ich das Argument erst auswerten können oder überhaupt erst mal bekommen. Die Antwort dazu hast du mir quasi damit gegeben:
Stephan hat geschrieben:
[...] indem Du den Formelstring von links beginnend zeichenweise liest und dabei auf öffnende Klammern, Funktionsnamen und schließende Klammern achtest, die erste schließende Klammer liefert gemeinsam mit der davor aufgetretenen öffnenden Klammer das was ich obenstehend schon "'Gesamt-Parameter-Inhalt' einer Funktion" nannte und die zugehörige Funktion ist die letzte davor identifizierte Funktion.
Damit hast Du eine Funktion und ihre Parameter und alle anderen Funktionen muss Du in gleicher Art und Weise rekursiv auflösen.
Wie gesagt, empfinde ich die Stringauswertung als Notlösung und ich hatte gehofft es gebe eine elegantere Lösung.
Die Gefahr einen Fall zu vergessen sehe ich ziemlich groß, da ich ja die Benutzung der Calc-Formeln und die Schreibweisen nicht einschränken möchte.
Ich denke auch, dass die Performance darunter leiden wird.
Und ist dann nicht auch die Nutzung meines Programmes an die bestehenden Versionen von OOCalc geknüpft, da es wenig flexibel auf Änderung reagieren kann?
Mittlerweile ziehe ich es immer mehr in Betracht. Auch weil ich an der Antwortzahl im Forum merke, dass es wohl kein "kleines", schnell zu lösendes Problem ist.
Dann gibt es allerdings einige Fälle zu beachten:
1. Argumente sind:
a) int -> String beginnt mit Zahl und enthält kein Komma
b) double -> String beginnt mit Zahl und enthält ein Komma
c) String -> String beginnt mit Anführungszeichen
d) boolean ? (Kommt der Fall überhaupt vor?)
e) Verweise -> String beginnt mit Buchstabe
f) Bereichsverweise -> String beginnt mit Buchstabe und enthält einen Doppelpunkt
g) Formeln -> String beginnt mit Buchstabe und enthält eine öffnende Klammer und eine schließende Klammer
Bei 1.e) und folglich auch 1.f) ist noch zu beachten, dass der String die absolute Adresse des Verweises enthält -> Absolute Adresse des Verweises (zB "B4") muss in "com.sun.star.CellAddress" umgewandelt werden (also in "Sheet 0, Column 1, Row 3"). Dazu kenne ich keine Methode. Kennt jemand dazu eine Methode? Ansonsten müsste ich das auch noch "händisch" machen.
Außerdem kann die Adresse auch mit Tabellenblatt angezeigt werden "Tabelle1.B4". Wenn also ein Punkt in dem Verweisstring enthalten ist, ist in dem Wort vor dem Punkt nur die Ziffer interessant und die Adresse nach dem Punkt muss wieder, wie im vorherigen Satz angedeutet, ausgewertet werden.
2. Zeichen in der Formel:
a) Formel enthält mehrere Argumente -> Formel enthält Semikolon, die Argumente von einander trennen
b) Formel enthält nur ein Argument oder Bereichsverweise -> Formel enthält kein Semikolon
Das sind ziemlich viele verschachtelte Bedingungen. Aber das sind jetzt nur die Fälle, die mir einfallen. Und es sind bestimmt nur die üblichsten Fälle. Dabei habe ich jetzt beispielsweise "named ranges" keine Beachtung geschenkt.
Verstehst du meine Bedenken?