| |
|
|
- Seite 1 - |
|
| >> Erzeugen von DLLs aus Profan²/XProfan-Codes
Eine Beschreibung, wie man Funktionen exportiert habe ich leider nicht gefunden. Eine kurze Erläuterung wäre nett. |
|
|
| |
|
|
|
| |
|
- Seite 1 - |
|
| Danke erstmal für den Hinweis mit der Hilfe , ich habe nur in der Versionhistorie geschaut. Meinen ansonsten funktionierenden Testcode hänge ich hier mal ran. Bitte umbenennen in zip. |
|
|
| |
|
|
|
Fernando Santos | Hallo Sebastian
Habe versucht mit dein Beispiel eine DLL zu erstellen, es wird eine dll mit der grösse von etwa 350KB generiert und wenn ich versuche das beispielprogramm zu starten erscheint die meldung das die namedll.inc nicht gefunden wird. Ich muss irgendwie etwas falsch machen, oder???
Gruss
Pedro |
|
|
| |
|
|
|
| Prf2CPP erzeugt beim erzeugen der DLL auch noch eine dazugehörige Includedatei. Diese sollte im selben Verzeichnis liegen wie die PRF welche die Includedatei benötigt. Kopiere die erzeugt Include also in Dein Programmierverzeichnis.
Salve, iF. |
|
|
| |
|
|
|
| Hallo Sebastian, Code ausserhalb von Proceduren wird der DLLMain() hinzugefügt. Damit kann ich also globale Deklarationen ausführen. Dies entspricht ja in etwa AttachThread(), Jetzt fehlt mir aber das Gegenstück DetachThread() zum automatischen Aufräumen und Speicher freigeben. Auf das was bei FreeDLL passiert habe ich ja sonst keinerlei Einfluß. Wird vielleicht nur selten gebraucht, jedoch wenn eine Umsetzung keine großen Probleme bereitet wäre es doch schön wenn Du dieses noch einbauen könntest |
|
|
| |
|
|
|
Sebastian König | [quote:32e8acf1bc]Hallo Sebastian, Code ausserhalb von Proceduren wird der DLLMain() hinzugefügt. Damit kann ich also globale Deklarationen ausführen. Dies entspricht ja in etwa AttachThread(), Jetzt fehlt mir aber das Gegenstück DetachThread() zum automatischen Aufräumen und Speicher freigeben. Auf das was bei FreeDLL passiert habe ich ja sonst keinerlei Einfluß. Wird vielleicht nur selten gebraucht, jedoch wenn eine Umsetzung keine großen Probleme bereitet wäre es doch schön wenn Du dieses noch einbauen könntest[/quote:32e8acf1bc] Hallo Thomas,
stimmt, so etwas wäre wirklich sinnvoll. Mal sehen, wie ich das am besten umsetze... was hältst Du von einer Art CleanUp-Prozedur, welche - wenn vorhanden - automatisch beim Entladen der DLL aufgerufen wird?
MfG
Sebastian |
|
|
| |
|
|
|
| Hallo Sebastian, genau soetwas meine Ich. Vielleicht sollte auch die Main optinal in eine DLLProc gelegt werden können (wegen der Übersichtlichkeit). Z.B.: DLLProc DLL_Init,0 DLLProc DLL_End,0
Müßte dann noch drauf hingewiesen werden, das diese Funktionen automatisch ausgeführt werden und nicht aufgerufen werden können.
Wäre toll wenn Du das in irgendeiner Form integrieren könntest |
|
|
| |
|
|
|
Sebastian König | [quote:ea11fb37e0]genau soetwas meine Ich. Vielleicht sollte auch die Main optinal in eine DLLProc gelegt werden können (wegen der Übersichtlichkeit). Z.B.: DLLProc DLL_Init,0 DLLProc DLL_End,0
Müßte dann noch drauf hingewiesen werden, das diese Funktionen automatisch ausgeführt werden und nicht aufgerufen werden können.
Wäre toll wenn Du das in irgendeiner Form integrieren könntest[/quote:ea11fb37e0] Hallo Thomas,
ich überlege noch, wie ich das am besten löse... Eins so, das andere so gefällt mir auch nicht - aber zwei verschiedene Möglichkeiten zur Initalisierung sind eher verwirrend, denke ich.
Irgendwie bietet sich der Bereich des Hauptprogramms auch wirklich an... Meine favorisierte Idee ist deshalb im Moment, beides an der gleichen Stelle unterzubringen und das Hauptprogramm beim Laden und Entladen der DLL aufzurufen. Zur Unterscheidung würde ich dann eine neue Profan2Cpp-spezifische Systemvariabele einführen. So könnte das dann aussehen: Was hältst Du (und wer sonst mitliest ) davon?
MfG
Sebastian |
|
|
| |
|
|
|
| @Sebastian: Mache es wie es am Reibungslosesten abläuft.
Im Endeffekt behaupte ich ist es egal wie das ganze gehandelt wird.
Ich würde warscheinlich einfach festlegen: Wenn eine DLL exportiert werden soll - so müssen folgende 2 Prozeduren im Quelltext vorhanden sein. dllproc DllInit und dllproc dllexit. Also eine Ein- und Ausstiegsprozedur. Wie Du das dann intern regelst sollte in den Bereich Deiner Erfahrung fallen - womit Du entscheidest was am besten funktioniert.
Salve, iF. |
|
|
| |
|
|
|
| DLLCode ausserhalb von Prozeduren empfinde ich auch eher als unüblich. Ich schließe mich erstmal iFs Vorschlag an, obwohl im Endeffekt ist mir die Syntax nicht so wichtig, nur die Möglichkeit zählt |
|
|
| |
|
|
| |
|
- Seite 2 - |
|
|
Sebastian König | Ich habe es jetzt so gemacht wie oben beschrieben - also mit %DLLInit. Gefällt mir wirklich am besten und ließ sich auch am einfachsten umsetzen .
Ist ein bischen an Delphi angelehnt, wenn ich mich nicht irre. Da wird auch der Code im Hauptteil (zwischen begin und end.) beim Laden ausgeführt, aber zum Aufräumen müsste man doch eine extra Prozedur erstellen... (und das gefiel mir ja nicht...)
Wie auch immer, ich hoffe, so wie es jetzt ist sind alle einigermaßen zufrieden .
MfG
Sebastian |
|
|
| |
|
|
|
| Hallo Sebastian, Ist es richtig, das die Systemvariable immer ausgewertet werden muß? KompilierenMarkierenSeparierenfunktioniert Erwartungsgemäß KompilierenMarkierenSeparierenhier hätte ich nicht erwartet, das die erste Messagebox 2x erscheint.
Nochwas: Autocompress-Plugin macht jedesmal vorm packen eine Messagebox, die wahr vorher nicht da. |
|
|
| |
|
|
|
Sebastian König | [quote:f157a845ad]Ist es richtig, das die Systemvariable immer ausgewertet werden muß? [...] Nochwas: Autocompress-Plugin macht jedesmal vorm packen eine Messagebox, die wahr vorher nicht da.[/quote:f157a845ad] Hallo Thomas,
ja, %DLLInit sollte immer (wenn etwas initialisiert oder aufgeräumt werden muss) abgefragt werden. Es wird immer das komplette Hauptprogramm aufgerufen - geht ja auch nicht anders, da alles zusammen in einer Funktion landet.
Die MessageBox bei AutoCompress ist eine Debug-Ausgabe (eingebaut um die Sache mit %1 zu korriegieren), die ich versehentlich nicht entfernt habe - sorry! Wird in der nächsten Beta natürlich weg sein .
MfG
Sebaitian |
|
|
| |
|
|