CD brennen mit XE-7 -> DLL erstellen

[mm1256]

Hallo,

ich habe seit 2006 die Komponente "Magic CD/DVD Burner Pro" im Einsatz. Auch beim letzten Update 2012 nicht die Quelltexte dazu gekauft. Ist die einzige Komponente, zu der ich nicht den kompletten Quelltext habe. das rächt sich nun beim Wechsel zu XE-7. Das Problem ist, dass die bpl nicht installiert bzw. compiliert werden kann. Auf der Homepage des herstellers ist es ziemlich ruhig, die letzte Newsmeldung ist 2 Jahre alt, und auf meine Mail antwortet keiner.

Also bleibt mir wohl nichts anderes übrig, als mit XE-2 eine DLL zu erstellen, auf die ich dann mit XE-7 zugreife. Soweit der Grundgedanke. Nur, ich brauche ja auch Rückmeldungen von der DLL an die App über Fortschrittanzeige usw. Wenn ich der DLL das Handle der aufrufenden Form übergebe, müsste das doch klappen. Dann könnte ich eine "Fortschritt-Message" an das aufrufende Fenster schicken, mit den Werten in WParam und LParam...oder so ähnlich. Bin da jungfräulich, habe sowas noch nicht gemacht.

Weil die Komponente ja eigentlich für den VCL-Einsatz gedacht ist, muss ich das Brenner-Objekt zur Laufzeit in der DLL erzeugen. Da ich damit wenig Erfahrung habe, gibt es allgemein gültige Dinge die man da beachten muss? Oder welche Stolperfallen lauern da generell?

Bin dankbar für jeden Hinweis bzw. Tipp!

[Mavarik]

Du kannst doch einfach aus Deinem bestehenden Projekt eine DLL machen - bzw. aus dem Form.

ggf. kannst Du die DLL einfach aus einem gepackten Memory-Stream laden, der als Resource in Deine XE7 app eingebunden ist (Windows).

Fertig.

[mm1256]

Zitat:

Zitat von Mavarik (Beitrag 1281277)

Du kannst doch einfach aus Deinem bestehenden Projekt eine DLL machen - bzw. aus dem Form.

Wegen einer Form die komplette VCL in eine DLL packen, das wäre Ressourcenverschwendung. Außerdem, die Form hat auch Datenbankzugriff, was ich zum Brennen ja gar nicht brauche. Es geht darin um die komplette Abwicklung von Datensicherung und Rücksicherung (Assistenten für die verschiedenen Funktionen). Wenn ich das alles unverändert rein packe (hab ich schon testweise gemacht) gibt's eine DLL mit knapp 12 MB. Außerdem ist die Form von anderen Forms abgeleitet, erbt also Inhalte die wiederum in anderen Programm-Modulen verwendet werden.

Ich müsste also bei Updates/Programmänderungen Quelltexte mehrfach pflegen, und genau das will ich ja mit der DLL-Variante vermeiden. Die erstell ich einmal, und dann isses gut für die nächsten Jahre, egal was mit Delphi kommt - bzw. von diesem Hersteller nicht mehr kommt. Die Auswahl an Brennerkomponenten ist nämlich sehr übersichtlich. Die von Binary Magic ist die Einzige die es gibt und dieses Nero-Api-Gedöns ist keine Alternative :oops:

[Bernhard Geyer]

Bietet Windows nicht seit XP auch eine Brenn-API?
Siehe: http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

Ich glaube so ein Build-In-API wird für viele Komponentenherstellen in diesem Bereich negativ aufs geschäft geschlagen haben.

[mm1256]

Hallo Bernhard,

mit deiner Vermutung über die Rentabilität liegst du wahrscheinlich richtig. Übrigens, es ist kein Build-In-Api sondern eine VCL-Komponente, die es auch mit Quellcode für 1.299,- Dollar gibt.

Vielen Dank für den Link. Ich hatte den schon mal im Visier als ich die letzte Version für XE-2 upgedated habe. Kostet ja jedes mal ein paar Euronen.

Habe es dann aber wieder sein lassen, weil ich VB nicht kann, und weil ich auch kein Delphi-Beispiel hierzu fand, was mich durchaus wundert. Es muss nämlich 100%-ig funktionieren, d.h. der Anwender darf gar nicht die Möglichkeit haben, irgend etwas falsch zu machen. Es geht schließlich um seine Daten (Datenbanken). Diese Sicherheit sehe ich bei dem VB-Script irgendwie nicht. Man müsste es halt mal ausprobieren.

[himitsu]

Zitat:

For an example that burns a disc image, see VBScript example.

Beispielcode in VBScript ... man kann diese API natürlich auch von Delphi aus ansprechen. :angel:

Delphi-Beispielcode: http://pblog.ru/?p=333

z.B. delphi IFileSystemImage

[Bernhard Geyer]

Zitat:

Zitat von mm1256 (Beitrag 1281308)

mit deiner Vermutung über die Rentabilität liegst du wahrscheinlich richtig. Übrigens, es ist kein Build-In-Api sondern eine VCL-Komponente, die es auch mit Quellcode für 1.299,- Dollar gibt.

Vielen Dank für den Link. Ich hatte den schon mal im Visier als ich die letzte Version für XE-2 upgedated habe. Kostet ja jedes mal ein paar Euronen.

Die Kompo kenne ich. Hatten wir auch mal im Einsatz. Irgendwann hat der Kunde auf eine Brennstation mit Spezieller API umgestellt und wir musstn diese Unterstütztn.

[mm1256]

Hallo,

vielleicht nochmals zurück zu meiner eigentlichen Frage bzw. Problem.

Auszug aus der DLL:

Delphi-Quellcode:

var
  CdBurner : TMCDBurnerPro;

{------------------------------------------------------------------------------}
{- Initialisierung des Burner's -----------------------------------------------}
{- aClientHandle: Handle des aufrufenden Formulares ---------------------------}
{- aOwner: Aufrufendes Formular/Application -----------------------------------}
{- aOnWriteDoneProc: Wird aufgerufen wenn der Brennvorgang abgeschlossen ist --}
{------------------------------------------------------------------------------}
function Burner_Open(aClientHandle: THandle; aOwner: TComponent;
                     aOnWriteDoneProc: TOnWriteDoneProc): boolean;
var
  i: integer;
begin
  Result := false;
  ClientHandle := aClientHandle;
  CdBurned := false;
  try
    CdBurner := TMCDBurnerPro.Create(aOwner); ==> hier knallt es schon: Zugriffsverletztung beim lesen von Adresse 00000081
    CDBurner.InitializeASPI(False);
    CDBurner.OnWriteDone := aOnWriteDoneProc;
    Result := Burner_AutoSelect;
  except
    on E:Exception do Burner_SendMessage(E.Message);
  end;
end;

Ich vermute mal, dass die Kompo im Constructor irgendwie feststellt, dass sie nicht auf einem Formular liegt. Ist das möglich?

[DeddyH]

Du kannst nicht über Modulgrenzen hinweg Objektinstanzen übergeben. Wozu brauchst Du denn den Owner? Du kannst doch genausogut nil als Owner setzen, nur musst Du die Komponente dann am Ende selbst wieder freigeben.

[himitsu]

Schnittstelle EXE <-> DLL :

• nichts was die Speicherverwaltung vom Delphi benutzt (außer man verwendet ShareMem u.ä.)
• niemals irgendwelche Delphi-Objekt-Instanzen übergeben
  allemein nichts übergeben, was die RTTI benutzt
• nichts aus der VCL (keine TComponent, maximal HWND ala MyComponent.Handle)
• ...

• Interfaces (IInterface) sind erlaubt (keine direkten Objekte)
• ShortString, PChar, PAnsiChar, PWideChar oder WideString sind erlaubt (keine String, AnsiString, UnicodeString usw.)

Wäre alles erlaubt, wenn man Packages nutzt, aber das würde deinem Vorhaben entgegen stehen.