Excel generieren ohne Office

[himitsu]

PChar ist ein sehr ungünstiger Exporttyp.

Ich empfehle dringend auf PAnsiChar zu ändern, da die DLL ja mit Delphi 7 erstellt wurde und die DLL demnach als PAnsiChar deklariert wurde.

Zitat:

Die DLL wurde unter folgenden Betriebssystemen getestet: WIN 98, WIN 2000, XP, VISTA (32Bit, 64Bit),
WIN 7 (32Bit, 64Bit)

PS: Der Versuch eine Datei in C:\... zu erstellen kann seit Win7 (mit ordentlichen Benutzerrechten, bzw. mit aktivem UAC noch nie funktioniert haben. (eigentlich schon seit Win2000, mit Benutzerrechte ging das nicht ... Zugriff verweigert)

Und eigentlich ist die Übergabe von Objekten, über die DLL-Grenzen hinweg, sowieso keine soooo gute Idee.

[marky522]

Zitat:

PS: Der Versuch eine Datei in C:\... zu erstellen kann seit Win7 (mit ordentlichen Benutzerrechten, bzw. mit aktivem UAC noch nie funktioniert haben. (eigentlich schon seit Win2000, mit Benutzerrechte ging das nicht ... Zugriff verweigert)

Das ist ja nur ein Demoprojekt, welches die grundsätzliche Funktionsweise der DLL zeigen soll

Zitat:

Ich empfehle dringend auf PAnsiChar zu ändern, da die DLL ja mit Delphi 7 erstellt wurde und die DLL demnach als PAnsiChar deklariert wurde.

Diese Änderung kann von jedem bequem in der UXLS.pas vorgenommen werden.

[himitsu]

Zitat von marky522:

Das ist ja nur ein Demoprojekt, welches die grundsätzliche Funktionsweise der DLL zeigen soll

Nur daß der Test nicht funktioniert und mir demnach auch nichts zeigen kann.
Mein Explorer wird nicht virtualisiert (das ist der Standard) und demnach zeigt er mir die C:\test1+1.xls nicht an.


Bezüglich des Objektsharings: Mach aus dem Objekt ein Interface und gut ist es.
PS: Das .Free kann nicht funktionieren, da hier der falsche Speichermanager angesprochen wird.
(und PChar nicht vergessen oder auf WideString umsteigen)

[marky522]

Zitat:

Nur daß der Test nicht funktioniert und mir demnach auch nichts zeigen kann.
Mein Explorer wird nicht virtualisiert (das ist der Standard) und demnach zeigt er mir die C:\test1+1.xls nicht an.

Na da bin ich aber froh, dass du die Datei doch noch entdeckt hast

Zitat:

Bezüglich des Objektsharings: Mach aus dem Objekt ein Interface und gut ist es.

Da die DLL so funktioniert, wie sie ist, habe ich eigentlich nicht vor sie zu ändern.

Zitat:

PS: Das .Free kann nicht funktionieren, da hier der falsche Speichermanager angesprochen wird.

Ich habe das genauso gemacht, wie in dem berühmten Beispiel einer Objekt-DLL von A. Kosch.
Ausserdem habe ich 500 Excel Dateien in einer Schleife erzeugen lassen und konnte kein Speicherleck in der Anwendung finden

[himitsu]

Mit Delphi 7 und wenn man alle Interfaces (virtuelle Methoden) nutzt und oder die Codeoptimierung deaktiviert ist, dann funktioniert es.

Ab Delphi 2009 muß man mit dem PChar aufpassen und sobald Delphi "nichtgenutzte" Methoden aus der VMT entfernt, dann stimmen die Indize der nachfolgenden Methoden nicht mehr und das war's dann > Exceptions wären das Mindeste.

[marky522]

Na gut Himitsu, du hast mich überredet! Ich habe die Interface-Proceduren so
angepasst, dass die Klasse innerhalb der DLL bleibt.

Der Nachteil dieser Implementierung ist, dass jetzt von einer Application aus nicht
gleichzeitig (parallel), sondern nur nacheinander mehrere Excel Dateien erzeugt werden können, da nur immer
eine Instanz der Klasse angelegt sein kann (und zwar innerhalb der DLL).
Ausserdem musste ich für jede Eigenschaft eine Procedure anlegen, die das Setzten (Ändern)
ermöglicht. Das war aufwendiger als ich dachte.

Natürlich hat sich durch die Änderung die Schnittstelle komplett geändert, sodass ich
das Demoprojekt komplett überarbeiten musste.

[marky522]

Hallo,

ich musste die beiden Versionen der DLLs Usbiff8.dll und Usbiff8V2.dll updaten, da
ab ca 8000 unterschiedlichen Strings in einem Excel-Dokument ein Record überlief.

Ich habe beide DLLs und die beiden Demoapplikationen mit angehängt, es hat sich jedoch
jeweils nur die DLL geändert.

Viel Spaß beim testen!