Add-In / Installation XLA -> XLL (Excel 97 Developer's Kit)
Stefan Bennoit
leider Probleme verursacht.
Kollegen nutzen das Add-In und erstellen Dateien, die mein Add-In nutzen.
Tauschen diese Kollegen nun untereinander Dateien aus, mault Excel bei
meinen Funktionen, da das Add-In in unterschiedlichen Verzeichnissen
gespeichert und dem Add-In Manager registriert worden ist.
Hilft es mir weiter, wenn ich aus dem Add-in (.xla) mit Hilfe des "Excel 97
Developer's Kit" eine XLL baue? Hört dann das rumgeärgere mit den
Verzeichnissen auf oder werde ich das irgendwie sonst los.
C++ ist kein Problem, damit entwickele ich sowieso die DLL, in der meine
Funktionen Implementiert sind.
Die Lösung sollte für WinNt4/Excel97 und W2K/Office2000 tauglich sein und
wenn möglich (ohne Interferenzen mit anderen Add-Ins) eine eigene Katerorie
im Funktionsassistenten erstellen.
Vielen Dank für Eure Hilfe und in Erwartung von Lösungen und Schleichwegen,
Stefan.
Hans Hofmann
<stefan....@notes.kwu.siemens.de> wrote:
>Hallo, ich habe ein Add-In mit ca. 100 Funktionen entwickelt, dass mir
>leider Probleme verursacht.
>Kollegen nutzen das Add-In und erstellen Dateien, die mein Add-In nutzen.
>Tauschen diese Kollegen nun untereinander Dateien aus, mault Excel bei
>meinen Funktionen, da das Add-In in unterschiedlichen Verzeichnissen
>gespeichert und dem Add-In Manager registriert worden ist.
>
>Hilft es mir weiter, wenn ich aus dem Add-in (.xla) mit Hilfe des "Excel 97
>Developer's Kit" eine XLL baue? Hört dann das rumgeärgere mit den
>Verzeichnissen auf oder werde ich das irgendwie sonst los.
>C++ ist kein Problem, damit entwickele ich sowieso die DLL, in der meine
>Funktionen Implementiert sind.
Das hilft in soweit, als das xll-Addin und seine Funktionen einmal
registriert werden (im Addin-Manager) und die Funktionen sich praktisch wie
normale XL-Tabellen-Funktionen anfühlen. Dazu kommen aber andere Probleme,
die wohl zum Teil auf die verwendete Bib. zurückzuführen sind.
Evtl. PM, würde den Rahmen hier sprengen.
>
>Die Lösung sollte für WinNt4/Excel97 und W2K/Office2000 tauglich sein und
>wenn möglich (ohne Interferenzen mit anderen Add-Ins) eine eigene Katerorie
>im Funktionsassistenten erstellen.
XL97 ist ziemlich problematisch (ist bekannt, siehe oben), oder ich hab halt
spezifischen Ärger damit. Sind unterschiedliche Sprachversionen darunter?
Eine eigene Katagorie ist machbar. Aber ich frage mich, ob nicht Deine
vorhanden xla.Funktionen - via Excel4 REGISTER auch richtig registriert und
damit besser eingebunden werden können - wäre zu untersuchen?
>Vielen Dank für Eure Hilfe und in Erwartung von Lösungen und Schleichwegen,
>Stefan.
Trotzdem ist das Excel SDK eine faszinierende Lösung weil C++ (welcher
Compiler) und sehr speedy :-)....
Gruß HW
Peter Eichler
wir verwenden eine solche lösung in der firma, indem wir die add-in-datei
auf dem netzt speichern(schreibgeschütz) und somit jeder die selbe datei
(ein und die selbe) verwendet
gruß
pe
"Stefan Bennoit" <stefan....@notes.kwu.siemens.de> schrieb im
Newsbeitrag news:b0gr11$63t$1...@news.fth.sbs.de...
Stefan Bennoit
das lässt sich leider innerhalb des Konzerns nicht mehr durchsetzen. Dafür
ist der Laden zu groß :-)
Trotzdem vielen Dank für Deine Zeit,
Stefan.
"Peter Eichler" <PEic...@focus-consulting.de> wrote in message
news:b0h4d4$p8e0g$1...@ID-179136.news.dfncis.de...
Stefan Bennoit
> Evtl. PM, würde den Rahmen hier sprengen.
> Sind unterschiedliche Sprachversionen darunter?
Evtl. DE/Excel2000, sonst alles Englisch
> Eine eigene Katagorie ist machbar. Aber ich frage mich, ob nicht Deine
> vorhanden xla.Funktionen - via Excel4 REGISTER auch richtig registriert
und
> damit besser eingebunden werden können - wäre zu untersuchen?
Ich hatte wg. dem Wartungauswand die ganze Arbeit gespart.
Die Lösung komplett C++ (alles aus einem Guss) lässt mich nicht los....
> Trotzdem ist das Excel SDK eine faszinierende Lösung weil C++ (welcher
> Compiler) und sehr speedy :-)....
Ich verwende DeveloperStudio 6
Thomas Risi
Newsbeitrag news:b0gr11$63t$1...@news.fth.sbs.de...
> leider Probleme verursacht.
> Kollegen nutzen das Add-In und erstellen Dateien, die mein Add-In nutzen.
> Tauschen diese Kollegen nun untereinander Dateien aus, mault Excel bei
> meinen Funktionen, da das Add-In in unterschiedlichen Verzeichnissen
> gespeichert und dem Add-In Manager registriert worden ist.
Bei VBA-AddIns ist wohl der einzig gangbare Weg, alle AddIns in das
gleiche Verzeichnis zu installieren.
> Hilft es mir weiter, wenn ich aus dem Add-in (.xla) mit Hilfe des "Excel
97
> Developer's Kit" eine XLL baue? Hört dann das rumgeärgere mit den
> Verzeichnissen auf oder werde ich das irgendwie sonst los.
> C++ ist kein Problem, damit entwickele ich sowieso die DLL, in der meine
> Funktionen Implementiert sind.
Ich habe es jetzt mal mit einer XLL versucht, die auf drei Rechnern in
verschiedenen Ordner abgelegt ist, und es scheint zu funzen ...
> Die Lösung sollte für WinNt4/Excel97 und W2K/Office2000 tauglich sein und
> wenn möglich (ohne Interferenzen mit anderen Add-Ins) eine eigene
Katerorie
> im Funktionsassistenten erstellen.
Wenn es nur zusätzliche Tabellenfunktionen sind, würde ich es auf jeden
Fall als XLL schreiben, ansonsten ein COM-AddIn. Ein Beispiel für eine
XLL findest Du auf meiner Webseite.
Gruß
Thomas
Stefan Bennoit
news:b0h814$o5l$03$1...@news.t-online.com...
> "Stefan Bennoit" <stefan....@notes.kwu.siemens.de> schrieb im
> Newsbeitrag news:b0gr11$63t$1...@news.fth.sbs.de...
> Wenn es nur zusätzliche Tabellenfunktionen sind, würde ich es auf jeden
> Fall als XLL schreiben, ansonsten ein COM-AddIn. Ein Beispiel für eine
> XLL findest Du auf meiner Webseite.
> http://rtsoftwaredevelopment.de
Danke für die Info, ich habe mir das FRMWRK32-Beispiel mal gezogen und fange
das experimentieren an.
Also nochmals Danke für Deine Mühe,
Stefan.
Stefan Bennoit
Intern habe ich Exceptionhandling. Das wird mit Excel nix. Deshalb bin in
immer hergegangen und habe
ein Flag aus meiner Dll hochgereicht und im Falle eines Falles meine
double-Funktionen
CVErr(xlErrValue) zurückgeben lassen (innerhalb des VB-Codes).
Private Declare Function IF97_hVon_p_t Lib "H2o32Bit.dll" Alias "hVON_p_t" _
(ByRef erg As Double, ByVal Druck As Double, ByVal Temperatur As Double)
As Long
Public Function hVon_p_t(ByVal Druck As Double, ByVal Temperatur As Double,
Optional ByVal UseNewFormulation As Boolean = True) As Variant
Rem spezifische Enthalpie h in [kJ/kg]
Dim erg As Double
Dim aufrufOk As Long
If (UseNewFormulation) Then
aufrufOk = IF97_hVon_p_t(erg, Druck, Temperatur)
Else
aufrufOk = IFC67_hVon_p_t(erg, Druck, Temperatur)
End If
If (aufrufOk = 1) Then
hVon_p_t = erg
Else
hVon_p_t = CVErr(xlErrValue)
End If
End Function
Wie kennzeichne ich diesen Rückgabewert aus C++ in der XLL??
Danke,
Stefan.
"Thomas Risi" <thoma...@t-online.de> wrote in message
news:b0h814$o5l$03$1...@news.t-online.com...
Hans Hofmann
<stefan....@notes.kwu.siemens.de> wrote:
>Eine Frage bleibt (mindestens) noch offen:
8<----------
>
>Wie kennzeichne ich diesen Rückgabewert aus C++ in der XLL??
Da nimmst DU einen XLOPER den Du für die Rückgabe auf einen LPXLOPER
castest
static XLOPER xInfo
xInfo.xltype = xltypeErr;
xInfo.val.err = xlerrValue; //15;
return (LPXLOPER)&xInfo;
Gruß HW
Thomas Risi
"Hans Hofmann" <ha...@chefmail.de> schrieb im Newsbeitrag
news:etno2vgtal4aju174...@4ax.com...
Hallo HW, Stefan
Und die Funktion könnte dann etwa so aussehen ...
EXPORT LPXLOPER WINAPI IF97_hVon_p_t(...)
Gruß
Thomas
http://rtsoftwaredevelopment.de