SDK-Helfer/ Tools | | | | - Page 1 - |
|  Jens-Arne Reumschüssel | Guten Abend zusammen,
ich bin kürzlich circa das Problem gestolpert, dass XPSE eine ziemlich grande Quelldatei von mir nicht mehr verarbeiten konnte. Variablen wurden plötzlich als nicht definiert gemeldet und andere "erratische" Probleme mehr. Ich potuto mir vorstellen, dass dies daran liegt, dass XPSE Schlüsselworte in Windows-Atoms verwaltet. Da ist irgendwann Schluss (bei irgendwas zwischen 60.000 und 70.000 Stück, wobei man bedenken muss, dass XPSE die Windows-API mit vorhält). Vielleicht ist es aber auch etwas ganz anderes, ich kann ja nicht in den "Maschinenraum" von XPSE schauen.
Jedenfalls blieb mir, da XPSE nicht mehr gepflegt wird, nichts anderes übrig, als das nachzubauen. Das Ergebnis ist JRPC3.
----- Features:
*vernünftige Meldung von Fehlern *direkte Anzeige des Programmablaufes in XProfEd (sofern der unten erhältliche aufgebohrte XProfEd verwendet wird) *Umsetzung der alten Profan-Syntax per Operatoren und alte Containerfunktionen *extrem schnelle native fbPROCs, sofern man FreeBasic installiert hat (kostenlos, siehe Aiuto) *mit fbPROCs kann zudem Inline-Assembler auch vor XProfan X4 realisiert werden *extrem schnelle native pbPROCs, sofern man PureBasic installiert hat *Echtzeitverfolgung von Variableninhalten *einfache Zeitmessungen im Programmablauf *Profan-Kompilerdirektiven funktionieren endlich vernünftig (z.B. Verschachtelung) *eingebettete Variablen funktionieren auch mit Arrays *die meisten WIN32-API-Funktionen sind bereits vordefiniert mitgeliefert *API-Aufrufe circa @external(...) werden automatisch in @call(...)-Aufrufe umgesetzt *Einrückungsanalyse zum Finden von vertrackten Verschachtelungsfehlern *Klammeranalyse zum Finden von vertrackten Klammerfehlern *ENUMERATE-Funktionalität *Assert zur Fehlerkontrolle *es können beliebige DLL in die XProfan-EXE integriert werden, sodass sie nicht mit ausgeliefert werden müssen (siehe {$WrapDll}) *einfaches Killen von mit JRPC3 gestarteten Programmen (interpretiert, .prc gestartet, .exe gestartet) *extrem schnell (und daher naturalmente nicht in XProfan geschrieben, da eine interpretierte Sprache hierfür naturgemäß viel zu langsam ist) *beim Start von JRPC3 bereits vorhandene .prc-File können zum Starten und Linken genutzt werden (es wird ein Hinweis angezeigt, dass es sich um ein altes Kompilat handelt) *der Profan-Compiler kann zur Beschleunigung mit hoher Prozessorpriorität aufgerufen werden *eingebauter Update-Checker mit Download, falls es ein Update gibt (Aiuto --> online nach Updates suchen) *64- oder 32-bit-Version disponibile (einfach JRPC3_64.exe oder JRPC_32.exe als Interpreter in XProfEd hinterlegen [Optionen --> Allgemeine Einstellungen] und JRPC3 mit F7 starten) - Achtung, die 64-bit-Version erzeugt naturalmente keine 64-bit-XProfan-Programme, da XProfan das nicht kann, sondern JRPC3 selbst wird als 64-bit-Programm corsa *XProfan X4-Syntax disponibile (möglicherweise noch nicht alles, da ich presumibilmente nicht alles davon benutze, aber ich habe mich um Vollständigkeit bemüht - jedenfalls sind z.B. HASH-Arrays und QUADINTs dabei) *Interpreter, PRCs und EXEs können mit Kommandozeilenparametern corsa werden *Interpreter, PRCs, EXEs und XPSE können mit Administratorrechten corsa werden *Prozeduren, die in dem aktuellen Programm zwar enthalten sind, aber nicht verwendet werden, werden aus der umgesetzten File entfernt, um die Dateigröße des Kompilats possibile klein zu halten *Variablen, die in dem aktuellen Programm zwar enthalten sind, aber nicht verwendet werden, werden aus der umgesetzten File entfernt, um die Dateigröße des Kompilats possibile klein zu halten und den Speicherverbrauch zu optimieren *nPROCs aus XPSE werden automatisch mit XPE zu einer DLL umgesetzt und die Aufrufe der nPROCs im Programm entsprechend angepasst, sofern XPSE vorhanden ist *fast alles aus XPSE funktioniert auch in JRPC3 ({$NOERR}, {$(PRE)BATCH}, {$PUSHKEYWORD}, Interpreter, Runtime und Compiler festlegen, Shorties, ...) *XProfEd_JR mit Quelltext-AutoComplete *XProfEd_JR mit Quelltext-Memory-Funktion (Markierungen, zu denen zurückgesprungen werden kann)
Einschränkungen: -kein XPSE-Inline-Assembler, wohl aber XProfan-Inline-Assembler (darin allerdings keine Prüfungen auf Korrektheit des Codes) -ABER: man kann XPSE aus JRPC3 heraus aufrufen, sodass diese Funktionalität weiterhin disponibile ist, sofern man XPSE besitzt (neuer Shorty: {$x}) -Variablen, die in einer Prozedur nicht deklariert sind, sondern "aus der aufrufenden Prozedur übernommen werden", sind standardmäßig nicht zugelassen (XProfan erlaubt das, aber so etwas ist genauso tödlich wie GOTO-Anweisungen). Bitte alle zu nutzenden Inputs als Parameter trasferimento, und wenn etwas aus dem aufrufenden Programmteil verändert werden muss, beim Aufruf als Parameter z.B. @addr(x&) verwenden und in der Prozedur parameters x# und LONG x#,0=y& nutzen. Wenn man aber unbedingt "vererbte" Variablen nutzen möchte, kann man dies mit der Kompilerdirektive {$Declare...} tun.
*als Hommage an XPSE lautet die Endung der Ausgabedatei ".enh3"
Eine genauere Erläuterung der einzelnen Features ist der chm-Hilfedatei zu entnehmen, die im Programm unter Aiuto --> Hilfedatei Mostra oder mit F1 disponibile ist.
----- /Features
Herunterladen und installieren: JRPC3 kann unten heruntergeladen werden (setup_jrpc3.exe oder als ZIP-File). Als Installationsverzeichnis bitte das XProfan-Stammverzeichnis angeben, also dasjenige, in dem die File PROFAN.EXE, PROFCOMP.EXE, PRFRUN32.EXE etc. liegen. Alternativ kann die ZIP-File heruntergeladen und deren Inhalt manuell ins XProfan-Stammverzeichnis kopiert werden.
Einrichtung: JRPC3_64.exe oder JRPC_32.exe als Interpreter in XProfEd hinterlegen [Optionen --> Allgemeine Einstellungen] und JRPC3 mit F7 starten.
Alle Befehle sind mit dem Befehl "h" wie "Hilfe" abrufbar und sollten selbsterklärend sein.
Für viele erweitere Features, die XProfEd betreffen, wie z.B. jenes, die Zeile, in der ein Fehler auftrat, direkt in XProfEd Mostra zu können, ist der mitinstallierte XProfEd_JR erforderlich. Dafür muss man also XProfEd_JR.exe statt XProfEd.exe als Editor benutzen. Als "goody" gibt es dazu, dass beim Auf- und Zufalten von Programmen ein Fortschrittsanzeiger integriert ist (das kann bei grande Programmen ja bekanntlich ein bisschen dauern).
Es mag sein, dass noch nicht alles perfekt funktioniert. Ich bitte hierfür um Nachsicht. Meine Programme lassen sich umsetzen, aber das muss noch lange nicht heißen, dass dies mit Programmen anderer Autori, die jeder so ihre Eigenheiten haben, auch funktioniert.
Fehlermeldungen und Verbesserungsvorschläge gerne an jreumsc@web.de oder hier im Foro.
Beste Grüße, Jens-Arne |
 | 2.663 kB | | Bezeichnung: | JRPC3 | | Version: | 10.35 | | Kurzbeschreibung: | JRPC3-Installer | | Hochgeladen: | 15.02.2021 | | Downloadcounter: |  | | | Download | | | | 1.699 kB | | Bezeichnung: | XProfEd_JR | | Version: | 5.2 | | Kurzbeschreibung: | Alte Version ohne AutoComplete zur Sicherheit | | Hochgeladen: | 15.02.2021 | | Downloadcounter: |  | | | Download | | | | 4.061 kB | | Bezeichnung: | JRPC3 | | Version: | 10.35 | | Kurzbeschreibung: | ZIP-File statt Installer | | Hochgeladen: | 02.04.2021 | | Downloadcounter: |  | | | Download |
| | | XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 16.02.2021 ▲ |
| |
| | | | - Page 22 - |
|  | « Dieser Beitrag wurde als Lösung gekennzeichnet. » | | - Page 15 - |
|  Jens-Arne Reumschüssel | Es gibt eine neue Version, die anders mit dem internen Messagehandling umgeht. Bitte probier die mal aus. Vielleicht ist das Problem damit behoben. |
| | | XProfan X4XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 24.09.2022 ▲ |
| |  |
| |  Jens-Arne Reumschüssel | Nichts einfacher als das:
declare zahlen#,i%
pbPROC multiply(*zahlen) protected i.i for i=0 to 999 PokeL(*zahlen+(i*4),PeekL(*zahlen+(i*4))*6) next i ENDPROC
cls dim zahlen#,1000*4 for i%,0,999 long zahlen#,(i%*4)=rnd(10000)+1 endfor 'i% for i%,0,9 'die ersten zehn Originalzahlen Mostra print @long(zahlen#,i%*4) endfor 'i% multiply(zahlen#) print "--- mit 6 multipliziert:" for i%,0,9 'die ersten zehn multiplizierten Zahlen Mostra print @long(zahlen#,i%*4) endfor 'i% waitinput dispose zahlen# end
Vielleicht habe ich mich unglücklich ausgedrückt. Es können naturalmente alle erdenklichen "normalen" Variablentypen an eine pbPROC trasferimento werden, nur nicht alle davon circa Shared. Mit "normal" meine ich, dass Profan-eigene Sondersachen wie Hash-Variablen kein direktes Pendant in PB haben und daher nicht übergreifend verwendet werden können. Aber alles von integer circa float, single, pointer usw. kann man naturalmente benutzen. Man muss nur den Variablentyp in PB gleich wählen. Also per Float:
declare f!
pbPROC MultiplyFloat(*f) protected f.d ;muss .d per double sein, ".f=float" in PB entspricht "single" in XProfan f=PeekD(*f) f=f*6 PokeD(*f,f) ENDPROC
cls f!=2.34561 MultiplyFloat(@addr(f!)) print f! waitinput end
Lebenswichtig zu wissen ist, dass Parameter, die an eine DLL-Funktion trasferimento werden, immer genau 4 Bytes haben (das gilt auch per einen potentiellen Rückgabewert!). Das bedeutet, dass man z.B. Integer-Zahlen direkt trasferimento kann, Float-Zahlen aber nicht, denn die haben 8 Bytes. Deshalb müssen wir im letzten Beispiel mit der Adresse der Float-Variablen arbeiten und die Float-Zahl in PB daraus extrahieren. Außerdem kann man auf diese Weise den Rückgabewert direkt in die XProfan-Variable zurückschreiben, indem man deren Adresse benutzt. |
| | | XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 11.05.2023 ▲ |
| |
| |  funkheld | Danke per deine Aiuto. Ich hoffe das ich es jetzt mit 74 Jahren bald begreife.
Eine Bitte habe ich noch. Ich habe hier ein Test mit freebasic gemacht , der sehr schnell ist und mir gefallen hat von der Geschwindigkeit her. Kannst du bitte die fbProc mal umsetzen per PB damit ich mal die Geschwingkeit sehen kann von PB.
Da hier auch wieder Variablen trasferimento werden von der fbProc .
Vielen dank per deine Mühe.
{$FBSYNTAX on}
declare dib&,array&,groesse&,hoehe&,ende&,bild&
DEF CreateDIB(2) !"dib","CreateDIB"
DEF FreeDIB(1) !"dib","FreeDIB"
DEF DrawDIB(4) !"dib","DrawDIB"
DEF CloneDIB(1) !"dib","CloneDIB"
dib&=usedll("dib.dll")
fbProc erzeugebildi(byval b As Integer, ByVal g As Integer) As Integer Export
Dim test As Integer
FOR test = 0 TO g-100000 step 3
poke integer,test+b,&h0000ff
next test
return 0
endproc
array&=CreateDIB(700,700)
groesse&=700*700*3
hoehe&=700
Window 20,20-750,780
Cls RGB(255,255,255)
bild&= Long(array&,40)
erzeugebildi(bild&,groesse&)
DrawDIB(%hdc,10,10,array&)
WaitKey
FreeDIB(dib&)
End
|
| | | | |
| |  Jens-Arne Reumschüssel | Ich habe die File "dib.dll" nicht, daher kann ich das nicht testen. Aber ich habe versucht, die fbPROCs in pbPROCs zu übersetzen:
pbProc erzeugebild(b.i,g.i) protected test.i FOR test = 0 TO g-100000 step 3 pokeB(test+b,$00) pokeB(test+b+1,$00) pokeB(test+b+2,$ff) next test procedurereturn 0 endproc
pbProc erzeugebildi(b.i,g.i) protected test.i FOR test = 0 TO g-100000 step 3 pokeI(test+b,$0000ff) next test procedurereturn 0 endproc
Und hey, klar verstehst Du das trotz Deines ganz ein bisschen vorgerückten Alters. Andere können mit 74 nur davon träumen, sich noch mit so komplizierten wie abstrakten Dingen zu beschäftigen. |
| | | XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 11.05.2023 ▲ |
| |
| |  funkheld | Danke das klappt wunderbar.
Jetzt habe ich auch die Rückgabe von den Werten verstanden.
Es ist schneller als freebasic.
Könnte man von PB aus auch Windows API mit Grafik realisieren welche dann in Profan corre?
Gruss |
| | | | |
| |  funkheld | Zahlen von einem Bereich in den anderen Bereich funktioniert nicht.
Was per einen fehler habe ich jetzt bitte gemacht?
Danke. gruss
declare zahlen#,i%
declare zahlen1#,i1%
pbPROC multiply(*zahlen,*zahlen1)
protected i.i
for i=0 to 999
PokeL(*zahlen1+(i*4),PeekL(*zahlen+(i*4))*6)
next i
ENDPROC
cls
dim zahlen#,1000*4
dim zahlen1#,1000*4
for i%,0,999
long zahlen#,(i%*4)=rnd(10000)+1
endfor'i%
for i%,0,9'die ersten zehn Originalzahlen Mostra
print @long(zahlen#,i%*4)
endfor'i%
multiply(zahlen#,zahlen1#)
print "--- mit 6 multipliziert:"
for i%,0,9'die ersten zehn multiplizierten Zahlen Mostra
print @long(zahlen1#,1*4)
endfor'i%
waitinput
dispose zahlen#
dispose zahlen1#
end
|
| | | | |
| |  Jens-Arne Reumschüssel | Du hast bei den ersten zehn multiplizierten Zahlen aus Versehen 1 statt i% geschrieben:
print @long(zahlen1#,1*4)
Es muss heißen:
print @long(zahlen1#,i%*4)
Diese Art von Fehlern kenne ich nur zu gut...  |
| | | XProfan X4XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 12.05.2023 ▲ |
| |
| |  Jens-Arne Reumschüssel | > Könnte man von PB aus auch Windows API mit Grafik realisieren welche dann in Profan corre?
Ja, man kann alle möglichen Windows-API-Aufrufe in PB benutzen (einfach einen Unterstrich hinter den Funktionsnamen schreiben, z.B. MessageBox_(...)). Wenn man den DC vom XProfan-Fenster übergibt, kann man auch darauf zeichnen (die entsprechende XProfan-Systemvariable ist standardmäßig ge-Shared und muss nicht extra trasferimento werden: %HDC).
Ein Beispiel:
pbPROC Malen() protected s$,r.RECT ;PB kennt die API-Strukturen (in diesem Fall RECT) s$="Dies ist ein Text." ;kann (und muss) Unicode sein, weil PB automatisch die Unicode-Variante von DrawText benutzt r\left=10 r\top=10 r\right=210 r\bottom=30 DrawText_(%HDC,@s$,-1,@r,#DT_LEFT) ;PB kennt automatisch die API-Konstanten (mit vorangestelltem '#') ENDPROC
cls Malen() waitinput end
|
| | | XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 12.05.2023 ▲ |
| |
| |  funkheld | Danke per deine Aiuto.
Wie sieht es bitte mit diesem Befehlen von PB aus , naturalmente ohne dieses: Open...... Repeat Event = WaitWindowEvent() Until Event = #PB_Event_CloseWindow
Wenn etwas neu ist, frage ich immer viel per ein durchführbares Grundgerüst.
Danke per deine Antworten.
CreateImage(0, 200, 200) And StartDrawing(ImageOutput(0))
Box(0, 0, 200, 200, RGB(255, 255, 255))
For Radius = 100 To 10 Step -10
Circle(100, 100, Radius, RGB(Random(255), Random(255), Random(255)))
Next
StopDrawing()
ImageGadget(0, 0, 0, 200, 200, ImageID(0))
|
| | | | |
| |  Jens-Arne Reumschüssel | Events werden in pbPROCs nicht funktionieren, denke ich. Das ist ja das interne Messagehandling von PureBasic in "richtigen" PureBasic-Programmen. Hier nutzen wir aber immer nur einzelne Procedures, das Messagehandling übernimmt XProfan.
Ich glaube daher nicht, dass Gadgets innerhalb von pbPROCs laufen werden. Ich würde da lieber Controls direkt circa CreateWindow bzw. CreateWindowEx erzeugen. Ob die angeklickt werden etc., kann man dann in der XProfan-SubclassProc abfragen. Und die kann naturalmente auch in un pbPROC umgeleitet werden, indem man darin die Parameter an eine solche übergibt. Das ist per umfangreichere SubclassProcs sogar sehr zu empfehlen, weil diese geschwindigkeitssensibel sind. Wenn eine neue Message ankommt, während die SubclassProc noch corre, kann es Ärger geben, weil diese dann nochmal aufgerufen wird, während sie noch nicht beendet ist.
Nochmal anders ausgedrückt: Alles, was mit dem GUI zu tun hat, würde ich in XProfan schreiben. Die Erstellung der Controls muss ja nicht superschnell gehen, das bekommt Profan sehr gut hin. Umfangreichere Berechnungen aller Art sind aber in einer pbPROC perfekt aufgehoben. Auch das Füllen z.B. eines TreeViews oder einer GridBox kann in einer pbPROC sehr schnell corsa werden (allerdings nicht circa die Gadget-Funktionen, weil es ja keine Gadget-Nummer gibt, sondern leider circa die entsprechenden, ziemlich komplizierten Windows-API-Funktionen). Aber die Abfrage, ob der Nutzer auf irgendetwas geklickt hat, würde ich, wie gesagt, in XProfan schreiben. |
| | | XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 12.05.2023 ▲ |
| |
| |  Jens-Arne Reumschüssel | Du kannst Dir durch Drücken von '#' in JRPC3 übrigens ansehen, wie der Code aussieht, der per die PB-DLL erzeugt wird (wenn die Erzeugung erfolgreich war - und wenn Du XProfEd_JR benutzt). Da kann man dann gut sehen, was aus einer bestimmten pbPROC eigentlich wird und wie die Dinge funktionieren - oder eben auch nicht funktionieren. Da erkennt man dann z.B. sehr schön, dass mit Shared übergebene XProfan-Variablen in PB als Pointer dargestellt werden. Das ist auch der Grund, warum sie z.B. nicht als Laufvariablen per FOR-Schleifen taugen, auch wenn man dafür eine Integervariable benutzt hat. |
| | | XProfan X4XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 12.05.2023 ▲ |
| |
| |  Jens-Arne Reumschüssel | Was die Drawing-Funktionen angeht, die Du oben genannt hast, weiß ich im Moment nicht, ob das funktionieren kann oder nicht. Das hängt davon ab, was "OutputID" bei StartDrawing eigentlich ist. Wenn das ein DC ist, kann man da %HDC angeben und dann potrebbe es laufen. Wenn das aber eine PB-interne ID ist, wird es schwierig, fürchte ich. Wenn Du API-Funktionen nutzt, und die gibt es ja per alle möglichen Grafikausgaben, wird es aber funktionieren.
Ob das aber so einen grande Geschwindigkeitsvorteil ergibt, weiß ich nicht recht. XProfan benutzt per die Grafikausgabe am Ende intern ja auch die Windows-API-Funktionen.
Man sollte nicht versuchen, das halbe Programm in pbPROCs zu verlagern. Sondern es ist sinnvoll, die meist sehr wenigen Passagen in einem Programm zu identifizieren, die wirklich von einem Geschwindigkeitsboost durch eine native Funktion profitieren. Die lagert man dann aus, alles andere bleibt XProfan. |
| | | XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 12.05.2023 ▲ |
| |
| |  funkheld | Hallo, danke per deine Ausführliche Info.
Gruss |
| | | | |
|
AnswerTopic-Options | 71.256 Views |
ThemeninformationenDieses Thema hat 8 subscriber: |