Ist eine Funktionalität von MSO-/VBA, welche in OO-/BASIC übertragen wurde, nur dann Teil von OpenOffice, wenn man darüber nicht "Option... " schreibt?
Prinzipiell ja.
(Ich schreibe deshalb "prinzipiell", weil ich mir nicht sicher bin ob das Ganze programmintern an jeder Stelle sauber getrennt ist.
Generell gilt jedoch 'VBA-Befehle' (Der Begriff ist strenggenommen falsch, denn ich rede hier eigentlich über Methoden etc. der MSO-API) das diese nicht ohne die Kompatibilitäts-Option im Code ausführbar sein dürfen.)
es gibt zumindest zwei Gründe dafür:
OO muß plattformunabhängig laufen, gleichzeitig garantiert MS (natürlich) nicht das alles was 'makrotechnisch' in MSO läuft auch in MSO abgelegt ist, d.h. es ist jedeerzeit damit zu rechnen das MS intern auf Teile des Betriebssystems zurückgreift, da ja klar ist das MSO nur für Windows (meinethalben auch für Mac) gemacht ist.
OO sollte gewährleisten versionsunabhängig (in Bezug auf MSO) zu bleiben, gleichzeitig gibt es dazu (natürlich) keine Abstimmung mit MS.
Würde OO nun Teile von VBA bzw. der MSO-API für sich 'nativ' übernehmen ist nie auszuschließen das es seitens MS Änderungen (z.B. Fehlerbereinigungen, denn Änderungen sind nicht negativ zu verstehen) macht, auf Welche OO keinen Einfluß hat.
Oder hätte ich die Frage - um mich im vorliegenden Forum gut aufgehoben zu fühlen - erst gar nicht stellen dürfen,
Das Problem ist eher das Du die Dinge (aus Unverständnis?) versuchst zu verallgemeinern, was Dich in die falsche Richtung führt, z.B. weil:
VBA und StarBasic sind fast 100%ig identisch (ja, wirklich), was aber praktisch ziemlich irrevant ist weil es nicht auf die Programmiersprachen ankommt sondern auf das jeweilige Objektmodell und diese unterscheiden sich. (z.B. ist "Application.OnTime" faktisch null VBA sondern 100% MSO-Objektmodell)
StarBasic z.B. ist allein durch die Befehle definiert die Du in der OO-Hilfe findest (bei VBA ist der Umfang ähnlich gering), der große Rest den Du bei der Programmierung im Code nutzt ist API/Objektmodell und nicht Teile der Sprache "StarBasic" (oder VBA).
Die Kompatibilitätsoption (Option VBASupport 1)) in den Code zu schreiben heißt definitiv nicht das damit nun alle VBA-'Befehle' laufen würden, sondern es heißt nur das diejenigen Befehle die OO aus dem MSO-Objektmodell 'beherrscht' jetzt laufen sollten.
Diese Aussage ist nicht formal, denn ein großer Teil der VBA-'Befehle' laufen trotz KOmpatibilitätsoption nicht, wobei ich keine detaillioerte Aufstellung kenne welche 'Befehle' funktionieren, zumal sich das sehr schnell ändert da OO hier zunehmend an Funktionalität gewinnt.
(VBA-'Befehle' in Hochkomma, weil es praktisch überwiegend um Methoden etc. des MSO-Objektmodell geht)
lorbass?
Es ist wohl ungünstig mich hier einzumischen, aber:
Du solltest im Blick haben das sich die Mehrheit der Helfenden hier nicht als Verteidiger eines Programms (z.B. OOo, AOO, LO) versteht sondern als neutrale Helfer.
Insbesondere heißt das auch die Dinge so zu erklären wie sie sind, nicht wie sie sein sollten (und wie sie die Programme/Projekte OOo, AOO, LO teils quasi als Werbung darstellen) und das heißt hier das es letztlich nicht so ganz günstig ist VBA in OOo/AOO/LO zu verwenden und man das deshalb besser meiden sollte.
Die Formulierung "die Dinge so zu erklären wie sie sind" meint hierbei insbesondere Wege/Lösungen aufzuzeigen die aus Erfahrung praktisch funktionieren und nicht WEge die nur funktionieren sollten (z.B. weil sie so in der Programmhilfe stehen).
Gruß
Stephan
[quote]Ist eine Funktionalität von MSO-/VBA, welche in OO-/BASIC übertragen wurde, nur dann Teil von OpenOffice, wenn man darüber nicht "Option... " schreibt?[/quote]
Prinzipiell ja.
(Ich schreibe deshalb "prinzipiell", weil ich mir nicht sicher bin ob das Ganze programmintern an jeder Stelle sauber getrennt ist.
Generell gilt jedoch 'VBA-Befehle' (Der Begriff ist strenggenommen falsch, denn ich rede hier eigentlich über Methoden etc. der MSO-API) das diese nicht ohne die Kompatibilitäts-Option im Code ausführbar sein dürfen.)
es gibt zumindest zwei Gründe dafür:
OO muß plattformunabhängig laufen, gleichzeitig garantiert MS (natürlich) nicht das alles was 'makrotechnisch' in MSO läuft auch in MSO abgelegt ist, d.h. es ist jedeerzeit damit zu rechnen das MS intern auf Teile des Betriebssystems zurückgreift, da ja klar ist das MSO nur für Windows (meinethalben auch für Mac) gemacht ist.
OO sollte gewährleisten versionsunabhängig (in Bezug auf MSO) zu bleiben, gleichzeitig gibt es dazu (natürlich) keine Abstimmung mit MS.
Würde OO nun Teile von VBA bzw. der MSO-API für sich 'nativ' übernehmen ist nie auszuschließen das es seitens MS Änderungen (z.B. Fehlerbereinigungen, denn Änderungen sind nicht negativ zu verstehen) macht, auf Welche OO keinen Einfluß hat.
[quote]Oder hätte ich die Frage - um mich im vorliegenden Forum gut aufgehoben zu fühlen - erst gar nicht stellen dürfen,[/quote]
Das Problem ist eher das Du die Dinge (aus Unverständnis?) versuchst zu verallgemeinern, was Dich in die falsche Richtung führt, z.B. weil:
VBA und StarBasic sind fast 100%ig identisch (ja, wirklich), was aber praktisch ziemlich irrevant ist weil es nicht auf die Programmiersprachen ankommt sondern auf das jeweilige Objektmodell und diese unterscheiden sich. (z.B. ist "Application.OnTime" faktisch null VBA sondern 100% MSO-Objektmodell)
StarBasic z.B. ist allein durch die Befehle definiert die Du in der OO-Hilfe findest (bei VBA ist der Umfang ähnlich gering), der große Rest den Du bei der Programmierung im Code nutzt ist API/Objektmodell und nicht Teile der Sprache "StarBasic" (oder VBA).
Die Kompatibilitätsoption (Option VBASupport 1)) in den Code zu schreiben heißt definitiv nicht das damit nun alle VBA-'Befehle' laufen würden, sondern es heißt nur das diejenigen Befehle die OO aus dem MSO-Objektmodell 'beherrscht' jetzt laufen sollten.
Diese Aussage ist nicht formal, denn ein großer Teil der VBA-'Befehle' laufen trotz KOmpatibilitätsoption nicht, wobei ich keine detaillioerte Aufstellung kenne welche 'Befehle' funktionieren, zumal sich das sehr schnell ändert da OO hier zunehmend an Funktionalität gewinnt.
(VBA-'Befehle' in Hochkomma, weil es praktisch überwiegend um Methoden etc. des MSO-Objektmodell geht)
[quote]lorbass?[/quote]
Es ist wohl ungünstig mich hier einzumischen, aber:
Du solltest im Blick haben das sich die Mehrheit der Helfenden hier nicht als Verteidiger eines Programms (z.B. OOo, AOO, LO) versteht sondern als neutrale Helfer.
Insbesondere heißt das auch die Dinge so zu erklären wie sie sind, nicht wie sie sein sollten (und wie sie die Programme/Projekte OOo, AOO, LO teils quasi als Werbung darstellen) und das heißt hier das es letztlich nicht so ganz günstig ist VBA in OOo/AOO/LO zu verwenden und man das deshalb besser meiden sollte.
Die Formulierung "die Dinge so zu erklären wie sie sind" meint hierbei insbesondere Wege/Lösungen aufzuzeigen die aus Erfahrung praktisch funktionieren und nicht WEge die nur funktionieren sollten (z.B. weil sie so in der Programmhilfe stehen).
Gruß
Stephan