| |
| |
|
| - page 1 - |
|
Jac
de
Lad | allô Roland!
Wäre es possible une Execute-Befehl pour Compilate trop faire? je sais, c'est sûrement schwierig, là es pas sinnvoll ist, den ganzen Interpreter dans qui Runtime trop quetschen  mais wäre es possible peut-être compilierte Programmezeilen auszuführen (et trop dem Zweck im grenier wieder trop decompilieren?)  Je mets mir cela très pratique avant, zum Beispiel pour größere Programme, pour qui on ensuite Plugins programmieren pourrait..  qui könnten ensuite direct ins Programme intervenir, quoi im Moment encore pas possible ist, sauf avec DLL beispielsweise, qui mais aussi pas simple so Profan-Variablen mettons peut...
Jac  |
|
| |
| 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 | 18.08.2006 ▲ |
|
| |
|
|
| |
| |
| - page 1 - |
|
 | eh bien Jacob à quelque chose comme J'ai eu aussi déjà gedacht - et und dir réellement!
j'ai prévu hierfür une Include trop écrivons (ou bien une Unit?) - cet soll ensuite XProfanCode selbst interpretieren et effectuer. un XProfan im XProfan sozusagen. je crois cela allez. Bien sûr wird es lente son - mais je crois jouer ensuite seulement une Nebenrolle. |
|
| |
| |
| |
|
|
| Nachtrag:
cela XProfan im Xprofan peux une eigene - une encore einfachere Syntax comme XProfan avons.
Es serait quasi une Programmiersprache avec XProfan programmiert.
je peux oui chez Gelegenheit hierfür la fois une Anfang faire. |
|
| |
| |
| |
|
|
RGH | allô Jacob,
quoi oui c'est ca schwebt Dir avant?
1. qui un compiliertes XProfan-Programme XProfan-Quellcode effectuer peux?
ou bien 2. qui qui XProfan-Interpreter compilé XProfan-Code effectuer peux?
ou bien 3. qui un compilertes XProfan-Programme compilé XProfan-Code so effectuer peux?
Version 1 et 2 avons cela Problem, qui ensuite qui Interpreter aussi qui Runtime enthalten devrait et qui Runtime aussi den Interpreter. c'est sûrement pas so simple machbar, mais un interessanter idée.
Version 3 wäre dans qui einfachsten variante une Entsprechung des Execute-Befehls pour compilierte Programme, chez dem une PRC-Dossier zur Laufzeit so eingebunden serait, comme wäre vous partie des Programmes. vous greift alors sur qui gleichen Variablen, etc. trop. aussi pas sans.
quoi oui déjà toujours (depuis Version 1.3) allez, ist folgendes: un compiliertes et zur EXE gelinktes Programme peux comme Runtime pour weitrere PRC-Module dienen. cet sommes mais eigenständige Programme et zur Datenübergabe würden sich INI-Fichiers ou bien Registry-Einträge empfehlen.
quoi mir encore vorschwebt (peut-être pour XPRofan 11, 12 ou bien 13?) sommes XPDLs, XProfan Dynamic Librarys. cet könnten Objekte, Prozeduren, etc. dans compiliertem XProfan-Code enthalten, qui de chaque compilé XProfan-Programme, cela vous einbindet, aufgerufen volonté pourrait. une Wrapper-DLL, qui naturellement qui Runtime enthalten ou bien nutzen devrait, pourrait cet Funktionalitäten aussi anderen Windowsprogrammen zur Disposition se mettre. Bislang exitiert so quelque chose allerdings seulement dans mon tête et einigen handschriftlichen Notizzetteln ...
mais vorerst veux je XProfan 10 fertig bekommen, et là wird es sûrement aucun weiteren neuen Features plus donner.* (je denke, cela quoi jusqu'alors récente à XProfan 9 ist, hätte aussi bien et volontiers pour 2 Versionssprünge gereicht.)
Salut
Roland
* Ok, Version RC2 wird comme letzten paramètre chez oGL(Init,...) pas seulement 0 et 1 zulassen, mais 0 - 5 et somit 5 verschiedene Lichtarten bieten, mais c'est wirklich qui dernier Erweiterung. |
|
| |
| Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 18.08.2006 ▲ |
|
| |
|
|
Jac
de
Lad | Hm...meiner attitude pour ist qui Interpreter so ou bien so presque überflüssig. je teste alle mon Programme presque ausschließlich im compilé Modus, weil dans qui Vergangenheit toujours la fois wieder kleine Abweichungen de Interpreter et Runtime aufgetaucht sommes. pas entier überflüssig ist qui Interpreter pour mich seulement, weil il im piège eines Fehlers la plus part du temps viel genauere Auskunft sur qui Ursache donner peux, qui Runtime gibt la plus part du temps seulement faute dans la ligne soundso aus, quoi ensuite gemappt volonté muss...très compliqué et zeitaufwändig.
mon concept ist, dass je Plugins écrivons peux, quasi comment pour Firefox. là peut qui Plugins aussi direct cela Vrehalten des Browsers changement et avons offensichtlich Zugriff sur qui Variablen de Firefox. je hab déjà deux Programme dans Profan geschrieben, l'autre comme Plugins effectuer et qui Runtime des aufrufenden Programms verwenden, soweit funktionierts pas mal. Sobald cela aufgerufene Proggi mais, beispielsweise, im %HWnd des aufrufenden Proggis un Steuerelement erstellen veux, wirds Mist, weil mir entweder qui Rechte manquer ou bien anderer Kram dazukommt.
Deswegen habe je d'abord gedacht, dass on quasi den Befehl Execute 1:1 umsetzen pourrait, en supplément müssten qui Plugins mais uncompiliert son, et si doch compilé wird cela Ganze unnötig schwer...
alors hab je versucht une eigene Batchsprache trop entwickeln (qui je oui mühelos verschlüsseln, compilieren, quoi que + subj., peux). malheureusement wir ddas Ganze ensuite doch sehhhhhr lente et so richtigen Zugriff (je erwähne ici encore fois le im Hauptprogramm declarierten Variablen) sur ALLES habe je pas. une gute concept wäre naturellement encore so quoi comment dynamische Unités. alors Unités, qui pas direct im Hauptprogramm stecken, mais dans einer anderen Dossier. cela serait im Sinne de Plugins mais seulement marcher, si le Pfade et Dateinamen en supplément dynamisch, alors dans Stringvariablen, angegeben volonté könnten. et ensuite devrait cela Hauptprogramm aussi dans qui situation son, den entsprechenden Code pas chez Programmstart trop magasin, mais tantôt à qui entsprechenden Programmzeile.
Versteht son worauf je hinaus veux???
Jac  |
|
| |
| 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 | 18.08.2006 ▲ |
|
| |
|
|
Jac
de
Lad | | @Michael: cela Prinzip des Aufrufs qui Runtime avec PRC-Dossier ist bien sûr. cela habe je bisher aussi benutzt. cela Ganze wirkt aussi droite joli avec SetParent, weil on ensuite, den impression hat, dass cela Ganze wirklich un Plugin ist. malheureusement gehts entweder so, dass je qui relevanten Variablen dans un INI schreibe ou bien comme paramètre übergebe, c'est pas très elegant et effectif. Aussi gibts toujours wieder Anzeigeprobleme si cela la fenêtre verdeckt wird...très mühsam! |
|
| |
| 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 | 18.08.2006 ▲ |
|
| |
|
|
Jac
de
Lad | @iF: je hab la fois quelque chose comme comment une Programmiersprache avec XProfan 8 geschrieben, était mais am Ende assez sinnlos. cela devrait ensuite déjà direct dans qui Runtime integriert son ou bien une DLL son, weil sonst ists trop lente. et chez ner DLL, denke je, ists relativ schwer hinzukriegen, dass on sur ALLES Zugriff hat...
Jac |
|
| |
| 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 | 18.08.2006 ▲ |
|
| |
|
|
| | eh bien je denke pas cela es Sinn pouvoir sur alles Zugriff trop avons. Den Zugriff sollte cela Hauptprogramm steuern - alors ist es doch plutôt une Frage dessen comment cela Hauptprogramm qui PlugInNachrichten verarbeitet - ou bien? |
|
| |
| |
| |
|
|
Michael
Dell | XProfan Dynamic Librarys, klingt Spannend! puis trop attendre lohnt bestimmt! (mais mon armen Nerven...  ) |
|
| |
| Salu Michael...
Hab zwar krumme Fieß awer dofir e' ecklich Gsicht! | 19.08.2006 ▲ |
|
| |
|
|
Michael
Wodrich | dans FireFox wird den PlugIns une API zur Disposition gestellt. qui regelt, sur quoi on Zugriff hat. sur cet Weise pourrait es aussi dans Profan programmiert volonté. et qui Datenzugriff sollte pas global gesehen volonté, mais comment chez Objekten: là sagt on aussi gib la fois Wert X ou bien mets Wert Y. Pour qui Ausführung ist ensuite cela objet zuständig - trifft aussi sur selbsterstellte API-Funktionen trop.
qui de Roland angesprochene Profan-DLL: DLL volonté oui im Speicherbereich des Hauptprogrammes fonctionnement. avec cela tomber ensuite déjà la fois quelques Begrenzungen weg - une gute concept.
belle Grüße
Michael Wodrich |
|
| |
| Programmieren, das spannendste Detektivspiel der Welt. | 19.08.2006 ▲ |
|
| |
|
|
Jac
de
Lad | | Profan-DLL et XPDL klingt bien! So dans etwa lieu je mir cela avant... |
|
| |
| 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 | 20.08.2006 ▲ |
|
| |
|
| |
| |
| - page 2 - |
|
|
Michael
Dell | | jusqu'à dahin, peut-être une Kombination aus PRC-Modul et FileMapping. |
|
| |
| Salu Michael...
Hab zwar krumme Fieß awer dofir e' ecklich Gsicht! | 20.08.2006 ▲ |
|
| |
|
|
Jac
de
Lad | So mach ego jusqu'à maintenant aussi! Ist eigentlich droite effectif, mais comment dit, alles quoi aufgerufen wird est un Extraprogramm et steckt pas direct im Hauptprogramm drin.
Jac 
@Alle qui qui Dossier downloaden: Über Sinn et Unsinn des Programms wird encore diskutiert! cela Programme était eigentlich pas zum Release vorgesehen et ist encore pas vollständig ausgereift, zeigt mais qui aktuellen Probleme des FileMappings. -> partiellement Darstellungsfehler. et s'il te plaît pas sur den Namen beschweren, je suis un großer Leslie Nielsen-Fan! (cela Bild stammt aus Dracula), Jedenfalls zeigt es joli, comment je jusqu'à maintenant mon Plugins realisiere...
Benutzung sur eigene péril! |
|
| |
| 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 | 20.08.2006 ▲ |
|
| |
|
(770)
Deutsch
English
Français
Español
Italia