| |
| |
|
Sebastian
König | Siehe aussi Tutoriels zum Thema: [...] 
Profan2Cpp-Aider
qui Direktive $DLL, qui am Anfang des Quellcodes stehen sollte, teilt Profan2Cpp avec, dass une DLL generiert volonté soll.
Prozeduren, qui exportiert volonté devoir, volonté avec dllproc eingeleitet. Pour dem Namen qui Procédure wird dabei comme zweites Argument le nombre qui paramètre, qui qui Procédure erwartet, angegeben. cet numéro sollte naturellement avec dem, quoi später avec parameters spezifiziert wird, übereinstimmen. avec dllproc deklarierte Prozeduren peut pas verschachtelt volonté.
depuis Profan2Cpp 1.6a peux comme dritter paramètre optionnel un Stringliteral (Ausdruck dans Anführungszeichen, aucun Variable!) angegeben volonté, qui den genauen Export-Namen qui Procédure angibt. (...)
Beispiel-Code:
KompilierenMarqueSéparation $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 peux on qui DLL ensuite verwenden (.inc wird automatisch de Profan2Cpp erzeugt):
KompilierenMarqueSéparation
MfG
Sebastian
Siehe aussi: sondage DLL avec Profan2Cpp? [...] |
|
| |
| |
| |
|
|
Jac
de
Lad | | comment stehts avec Controls et so, peut qui dans Profan erzeugt et dans qui DLL benutzt volonté et renversé? 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
comment stehts avec Controls et so, peut qui dans Profan erzeugt et dans qui DLL benutzt volonté et renversé? Gibt es Einschränkungen?
*seufz* et je hab mir soviel Mühe avec dem écrivons qui Documentation gegeben..  ici alors encore un Auszug:
Profan2Cpp-Aider
une größere Einschräkung gibt es malheureusement: dedans qui DLL devrait aucun Befehle ou bien Funktionen, qui la fenêtre ou bien Fensterelemente erzeugen, verwendet werden; cela Verhalten ist sonst unvorhersehbar. @SendMessage() et @Poster un message() marcher cependant - et MessageBoxes stehen zur Disposition.
Ergänzend en supplément ist trop dire, dass sur API naturellement alles erlaubt ist. qui Einschränkung bezieht sich seulement sur Sachen comment Créer() et Contrôle(), et chez Créer() aussi seulement sur Fensterelemente.
Generell serait on mais aussi sowiese plutôt Performance-kritische Sachen dans un C++-DLL auslagern, et là gehören GUI-Sachen avec Windows meiner Erfahrung pour selten en supplément...
MfG
Sebastian |
|
| |
| |
| |
|
|
 | Jup, c'est une gute Demo.  merci.
Na, ensuite peux je oui einiges chez meinem Programmen la fois remodeler/auslagern.
mfg |
|
| |
| |
| |
|
|
Detlef
Jagolski | | j'ai mir avec Profan2Cpp pour mon Owner-Draw Menüs une Dll gebaut avec encore weitern Funktionen qui je toujours brauche. |
|
| |
| XProfan X4, PRFellow, Profan2Cpp - Version 2.0c-pre5, Windows 11 | 11.03.2009 ▲ |
|
| |
|
|
Sebastian
König | Detlef Jagolski
j'ai mir avec Profan2Cpp pour mon Owner-Draw Menüs une Dll gebaut avec encore weitern Funktionen qui je toujours brauche.
un schönes Beispiel, cela gleichzeitig zeigt, dass aussi la fenêtre-bezogene Dinge possible sommes.
mon eigene Aussage de dessus (Antwort and Jac) habe je dabei nochmal näher attentive et muss eh bien dire: c'est wohl pas seulement chez Dingen, pour qui une hohe Geschwindigkeit important ist, sinnvoll vous dans un DLL auszulagern. peut-être voudrais on aussi simple une DLL zur Verwendung dans mehreren Projekten et/ou bien zur Veröffentlichung erstellen.
qui Zwischenstand qui sondage (si aussi pas très repräsentativ) peut mich avec dem Gedanken spielen, une Workshop trop dem Thema trop erstellen. je pourrait mir zum Beispiel présenter, une Anfang meiner SKControl.DLL dans XProfan nachzubauen...
MfG
Sebastian |
|
| |
| |
| |
|
|
Sebastian
König | Jac
encore ne blöde Frage: si je dans XProfan quoi dans qui interne Listboxliste fülle, ensuite peux je dans einer DLL, qui avec Prf2CPP erstellt wurde pas puis zugreifen ou bien? et renversé sûrement aussi pas? cela wäre einer qui Gründe sur DLL-Erstellung trop verzichten, im entsprechenden le cas jedenfalls.
Simple Frage - qui Antwort ist quelque chose compliqué sans es probiert trop avons, serait je aus dem mémoire dire, dass dedans des DLL-Codes folgendes gilt:
* Füllen et Changement qui liste funktioniert
* MoveListToStr$/Mem/Array() aussi
* MoveListToHandle() funktioniert pas avec List- et ComboBoxes, avec Edits mais déjà
qui Gründe hierfür liegen y, dass de Profan2Cpp-Anwendungen un MultiThread-Konzept benutzen, DLL mais pas et je pour MoveListToHandle() keinen Fil-Test incorporé habe.
cela ganze gilt aussi pour un paire weitere Dinge. Im Einelfall: simple ausprobieren et mich ggf. um Anpassung bitten.
si Du meinst, dass Du dans XProfan qui liste füllst et ensuite dans qui DLL avec cela travailler vouloir: cela allez naturellement pas - avec aucun DLL, car qui sais oui rien de XProfans interner liste... EDIT: Ok, Du meinst wohl oui c'est ca cela - j'étais quelque chose trop vite avec qui obigen Antwort, mais peut-être ist cela quand même intéressant.
MfG
Sebastian |
|
| |
| |
| |
|
|
| Hmmm..., comment wird une Bereichsvariable b# transfert à qui DLL, wohin qui grösse wechselt?
Soll eien Dll volonté.
Übergabe wert&,b#,c# et Retour z&.
KompilierenMarqueSéparation
mfg. |
|
| |
| |
| |
|
|
Sebastian
König | Peter Bierbachh
Hmmm..., comment wird une Bereichsvariable b# transfert à qui DLL, wohin qui grösse wechselt?
qui DLL-Funktion muss pour chacun Bereichsvariable savons, comment grand vous ist. D.h. qui Größen doit comme paramètre transfert volonté. Beispiel:
KompilierenMarqueSéparation
si plusieurs Bereiche qui gleiche Taille avons, peux on sich naturellement überflüssige paramètre ersparen...
MfG
Sebastian |
|
| |
| |
| |
|
|
| Irgend quelque chose stimmt ici pas.
si je dans qui DLL seulement wieder récente dimensionieren muss....cet Bereichsvariablen.
Es beisst sich quoi... 
peux pas stimmen...ou bien...
Wird wahrscheinlich pour den Programmablauf doch zeitaufwendiger, si je dans qui DLL wieder avec den zuweisungen chez zéro anfangen muss.
mfg |
|
| |
| |
| |
|
|
Sebastian
König | j'ai den Fil justement sous dem neuen Namen wiedergefunden...
Peter Bierbachh
Irgend quelque chose stimmt ici pas. si je dans qui DLL seulement wieder récente dimensionieren muss....cet Bereichsvariablen. Es beisst sich quoi... peux pas stimmen...ou bien... Wird wahrscheinlich pour den Programmablauf doch zeitaufwendiger, si je dans qui DLL wieder avec den zuweisungen chez zéro anfangen muss.
alors là la hâte Du irgendwas faux verstanden... c'est pas nötig, den Bereich dans qui DLL récente trop dimensionieren. und dir seulement tout autor, dass Du einer exportierten Procédure, qui Bereiche comme paramètre erwartet, mitteilen musst, comment grand cet im aufrufenden Code dimensioniert wurden.
c'est völlig analog trop qui travail avec API-Funktionen comment zum Beispiel ZeroMemory(). là übergibt on oui aussi une Bereich (i.e. aiguille) et qui zugehörige Taille...
MfG
Sebastian |
|
| |
| |
| |
|
|
| ah sooooo,....J'ai eu maintenant faux verstanden vom Beispiel. Wäre oui aussi sonst paradoxe.
mfg |
|
| |
| |
| |
|
(849)
Deutsch
English
Français
Español
Italia