| |
| |
|
Sebastian
König | Siehe auch Tutorial zum Thema: [...] 
Profan2Cpp-Aiuto
Die Direktive $DLL, die am Anfang des Quellcodes stehen sollte, teilt Profan2Cpp mit, dass eine DLL generiert werden soll.
Prozeduren, die exportiert werden sollen, werden mit dllproc eingeleitet. Nach dem Namen der Prozedur wird dabei als zweites Argument die Anzahl der Parameter, die die Prozedur erwartet, angegeben. Diese Zahl sollte naturalmente mit dem, was später mit parameters spezifiziert wird, übereinstimmen. Mit dllproc deklarierte Prozeduren können nicht verschachtelt werden.
Seit Profan2Cpp 1.6a kann als dritter Parameter optional ein Stringliteral (Ausdruck in Anführungszeichen, keine Variable!) angegeben werden, der den genauen Export-Namen der Prozedur angibt. (...)
Beispiel-Code:
KompilierenMarkierenSeparieren $DLL
Alles, was nicht in eine Prozedur steht, wird beim Laden und
Entladen der DLL ausgeführt. Dies ist also auch der Platz,
wo eventuell nötige (De)Initialisierungen und stehen sollten.
if %DLLInit Laden...
MessageBox ... aus DllMain().,Meldung...,0
else Entladen...
MessageBox DLL wurde deinitialisiert.,Ciao,0
endif
proc IsPrime
Eine Prozedur, die nur innerhalb der DLL verwendet wird.
Gibt 1 zurück, wenn number& prim ist, sonst 0.
parameters number&
declare prime%
let prime% = 1
whileloop 2,(number& 2)
ifnot number& mod &loop
let prime% = 0
break
endif
endwhile
return prime%
endproc
dllproc CountPrimes,1
Zählt alle Primzahlen von 2 bis upto&.
parameters upto&
declare primes&
let primes& = 1 Die 2 zählt schonmal...
whileloop 3,upto&,2 sonst alle geraden Zahlen überspringen...
if IsPrime(&loop) <> 0
inc primes&
endif
endwhile
return primes&
endproc
So kann man die DLL dann verwenden (.inc wird automatisch von Profan2Cpp erzeugt):
KompilierenMarkierenSeparieren
MfG
Sebastian
Siehe auch: Umfrage DLL mit Profan2Cpp? [...] |
|
| |
| |
| |
|
|
Jac
de
Lad | | Wie stehts mit Controls und so, können die in Profan erzeugt und in der DLL benutzt werden und umgekehrt? Gibt es Einschränkungen? |
|
| |
| Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP | 11.03.2009 ▲ |
|
| |
|
|
Sebastian
König | Jac
Wie stehts mit Controls und so, können die in Profan erzeugt und in der DLL benutzt werden und umgekehrt? Gibt es Einschränkungen?
*seufz* Und ich hab mir soviel Mühe mit dem Schreiben der Documentazione gegeben..  Hier also noch ein Auszug:
Profan2Cpp-Aiuto
Eine größere Einschräkung gibt es leider: Innerhalb der DLL sollten keine Befehle oder Funktionen, die Fenster oder Fensterelemente erzeugen, verwendet werden; das Verhalten ist sonst unvorhersehbar. @SendMessage() und @PostMessage() funktionieren jedoch - und auch MessageBoxes stehen zur Verfügung.
Ergänzend dazu ist zu sagen, dass circa API naturalmente alles erlaubt ist. Die Einschränkung bezieht sich nur auf Sachen wie Create() und Control(), und bei Create() auch nur auf Fensterelemente.
Generell würde man aber auch sowiese eher Performance-kritische Sachen in un C++-DLL auslagern, und da gehören GUI-Sachen mit Fenstern meiner Erfahrung nach selten dazu...
MfG
Sebastian |
|
| |
| |
| |
|
|
 | Jup, das ist eine gute Demo.  Danke.
Na, dann kann ich ja einiges bei meinem Programmen mal umgestalten/auslagern.
mfg |
|
| |
| |
| |
|
|
Detlef
Jagolski | | Ich habe mir mit Profan2Cpp per meine Owner-Draw Menüs eine Dll gebaut mit noch weitern Funktionen die ich immer brauche. |
|
| |
| XProfan X4, PRFellow, Profan2Cpp - Version 2.0c-pre5, Windows 11 | 11.03.2009 ▲ |
|
| |
|
|
Sebastian
König | Detlef Jagolski
Ich habe mir mit Profan2Cpp per meine Owner-Draw Menüs eine Dll gebaut mit noch weitern Funktionen die ich immer brauche.
Ein schönes Beispiel, das gleichzeitig zeigt, dass auch Fenster-bezogene Dinge possibile sind.
Meine eigene Aussage von oben (Antwort and Jac) habe ich dabei nochmal näher bedacht und muss nun sagen: Es ist wohl nicht nur bei Dingen, per die eine hohe Geschwindigkeit wichtig ist, sinnvoll sie in un DLL auszulagern. Vielleicht möchte man auch einfach eine DLL zur Verwendung in mehreren Projekten und/oder zur Veröffentlichung erstellen.
Der Zwischenstand der Umfrage (wenn auch nicht sehr repräsentativ) lässt mich mit dem Gedanken spielen, einen Workshop zu dem Thema zu erstellen. Ich potuto mir zum Beispiel vorstellen, einen Anfang meiner SKControl.DLL in XProfan nachzubauen...
MfG
Sebastian |
|
| |
| |
| |
|
|
Sebastian
König | Jac
Noch ne blöde Frage: Wenn ich in XProfan was in die interne Listboxliste fülle, dann kann ich in einer DLL, die mit Prf2CPP erstellt wurde nicht darauf zugreifen oder? Und umgekehrt sicher auch nicht? Das wäre einer der Gründe auf DLL-Erstellung zu verzichten, im entsprechenden Fall jedenfalls.
Einfache Frage - die Antwort ist etwas kompliziert Ohne es probiert zu haben, würde ich aus dem Gedächtnis sagen, dass innerhalb des DLL-Codes folgendes gilt:
* Füllen und Ändern der Liste funktioniert
* MoveListToStr$/Mem/Array() auch
* MoveListToHandle() funktioniert nicht mit List- und ComboBoxes, mit Edits aber schon
Die Gründe hierfür liegen darin, dass von Profan2Cpp-Anwendungen ein MultiThread-Konzept benutzen, DLL aber nicht und ich per MoveListToHandle() keinen Thread-Test eingebaut habe.
Das ganze gilt auch per ein paar weitere Dinge. Im Einelfall: Einfach ausprobieren und mich ggf. um Anpassung bitten.
Falls Du meinst, dass Du in XProfan die Liste füllst und dann in der DLL damit arbeiten möchtest: Das geht naturalmente nicht - mit keiner DLL, denn die weiß ja nichts von XProfans interner Liste... EDIT: Ok, Du meinst wohl genau das - ich war etwas zu schnell mit der obigen Antwort, aber vielleicht ist das trotzdem interessant.
MfG
Sebastian |
|
| |
| |
| |
|
|
| Hmmm..., wie wird eine Bereichsvariable b# trasferimento an die DLL, wo die grösse wechselt?
Soll eien Dll werden.
Übergabe wert&,b#,c# und Return z&.
KompilierenMarkierenSeparieren
mfg. |
|
| |
| |
| |
|
|
Sebastian
König | Peter Bierbachh
Hmmm..., wie wird eine Bereichsvariable b# trasferimento an die DLL, wo die grösse wechselt?
Die DLL-Funktion muss per jede Bereichsvariable wissen, wie grande sie ist. D.h. die Größen müssen als Parameter trasferimento werden. Beispiel:
KompilierenMarkierenSeparieren
Wenn mehrere Bereiche die gleiche Dimensione haben, kann man sich naturalmente überflüssige Parameter ersparen...
MfG
Sebastian |
|
| |
| |
| |
|
|
| Irgend etwas stimmt hier nicht.
Wenn ich in der DLL erst wieder neu dimensionieren muss....diese Bereichsvariablen.
Es beisst sich was... 
Kann nicht stimmen...oder...
Wird wahrscheinlich per den Programmablauf doch zeitaufwendiger, wenn ich in der DLL wieder mit den zuweisungen bei Null anfangen muss.
mfg |
|
| |
| |
| |
|
|
Sebastian
König | Ich habe den Thread gerade unter dem neuen Namen wiedergefunden...
Peter Bierbachh
Irgend etwas stimmt hier nicht. Wenn ich in der DLL erst wieder neu dimensionieren muss....diese Bereichsvariablen. Es beisst sich was... Kann nicht stimmen...oder... Wird wahrscheinlich per den Programmablauf doch zeitaufwendiger, wenn ich in der DLL wieder mit den zuweisungen bei Null anfangen muss.
Also da hast Du irgendwas falsch verstanden... es ist nicht nötig, den Bereich in der DLL neu zu dimensionieren. Es geht nur darum, dass Du einer exportierten Prozedur, die Bereiche als Parameter erwartet, mitteilen musst, wie grande diese im aufrufenden Code dimensioniert wurden.
Das ist völlig analog zu der Arbeit mit API-Funktionen wie zum Beispiel ZeroMemory(). Da übergibt man ja auch einen Bereich (i.e. Zeiger) und die zugehörige Dimensione...
MfG
Sebastian |
|
| |
| |
| |
|
|
| Ach sooooo,....hatte ich jetzt falsch verstanden vom Beispiel. Wäre ja auch sonst paradox.
mfg |
|
| |
| |
| |
|
(909)
Deutsch
English
Français
Español
Italia