OpenOffice.info

Danke für die ausführliche Antwort, Stephan. Die Risiken sind mir bewusst. Und ich wäre, ehrlich gesagt, auch nicht von selbst auf die Idee gekommen, Standardfunktionen überschreiben zu wollen. Diese "Forderung" ergab sich aus der Diskussion. --> [i]"Kein normaler Mensch rechnet in Radiant! Und sich neue Funktionsnamen merken zu müssen, ist auch nicht optimal!"[/i] (Wobei ich der ersten Aussage zumindest bedingt zustimme *g* ). Ich hatte das Ganze als willkommene Gelegenheit gesehen, vlt. noch etwas lernen zu können.

Grüße
TC

Es gibt meines Wissens keine Spezifikation (Dokumentation) dafür, ich persönlich habe solche Namensgleichheiten aber bisher immer vemieden und dabei auch beachtet die internen englischsprachigen Namen der Funktionen nicht zu benutzen.

[size=85](Meine 'Warnung' hierbei ist das Verhalten wie OO z.B. mit Nummernkreisen umgeht, hierbei gibt es nämlich auch Konfusion wenn man einen eigenen Nummernkreis definiert denn Name dem internen Namen eines vorhandenen Nummernkreise entspricht (also selbstdefinierter Nummernkreis namens "table"/"Table" macht Probleme in einem deutschsprachigen OpenOffice obwohl dort der über die Benutzeroberfläche sichtbare Nummernkreis "Tabelle" heißt.)[/size]

Es wäre aber zweifelsohne interessant die Frage gleichen Tabellenfunktionsnamen einmal zu untersuchen, denn ich erinnere mich dunkel schon einmal Lösungen gesehen (vielleicht sogar selbst programmiert?) zu haben die bei *.xls die Möglichkeit nutzen in Excel aber nicht in OO verhandene Funktionen in OO namensgleich nachzubilden (z.B. DATEDIF() wäre eine solche Funktion) - aber nochmals: ich bin momentan nicht ganz sicher, vielleicht bilde ich mir das auch nur ein.

[quote]was ja im Normalfall auch eine sehr sinnvolle Einstellung ist[/quote]

Selbst wenn ich mir Dein Beispiel für eine Ausnahme ansehe erkenne ich nicht wirklich einen Vorteil bzw.: bitte wäge den Vorteil der Namensgleichheit gegen die quasi gesicherten [1] Risiken ab, denn wenn Du die Datei weitergibst kann sie versagen weil der andere Nutzer Makros blockiert hat, was dann aber garnicht auffallen würde weil zu erwarten ist das dann die gleichnamige Standardtabellenfunktion greift.
Es ist, meiner Ansicht nach, in Grenzfällen immer zu bevorzugen das potentiell riskannte Dinge dann zum Trtagen kommen wenn die Datei von einem Insider genutzt wird, d.h. wenn es Rahmenbedingungen gibt (geben kann) die Probleme erzeugen sollte i.A. sichergestellt sein das diese Bedingungen nicht bei 'normalen' Endanwendern auftreten die von der Existenz potenzieller Probleme ja nichts wissen (können).

[1]
mit gesichert meine ich hier das benutzerdefinierte Funktionen mit Sicherheit nicht funktionieren wenn Makroausführung nicht gestattet ist (im Gegensatz zu nur potentiellen Risiken, z.B. die FRage der Namensgleichheit die wir hier diskutieren)



Gruß
Stephan

'--- Test ---
function sin(x as single)
	sin = gsin(x)
	MsgBox("Override: SIN(" & x & "°) = " & sin)
end function

Ausprobiert habe ich, und bei meinem einfachen Test war es nicht möglich (was ja im Normalfall auch eine sehr sinnvolle Einstellung ist). Jedoch könnte es sein, dass es über Umwege, die ich nicht kenne, doch möglich wäre. Deshalb habe ich gepostet.

Edit:
[code]'--- Test ---
function sin(x as single)
sin = gsin(x)
MsgBox("Override: SIN(" & x & "°) = " & sin)
end function
[/code]

Wenn Du es mal ausprobiert hättest, dann wüsstest Du es.

Hallo,

ist es möglich, Calc-Funktionen durch benutzerdefinierte Funktionen gleichen Namens überschreiben? Das Ganze soll natürlich nur in einem bestimmten Dokument funktionieren, um Kollisionen zu vermeiden.

z.B. statt [b]=sin(rad(30))[/b] [sin(30°) als Calc-Funktion] möchte ich [b]=sin(30)[/b] [sin(30°) als UDF] schreiben, genauso
wie statt [b]=deg(arcsin(0,5))[/b] [als Calc-Funktion] soll [b]=arcsin(0,5)[/b] [als UDF] ein Ergebnis in Grad ausgeben soll.

Vielen Dank!

(ich war ja schon etwas entsetzt, dass Basic keine deg-, rad- und außer dem arctan keine Arcus-Funktionen implementiert hat)