SDK-Helfer/ Tools | | | | - Seite 1 - |
| Jens-Arne Reumschüssel | Guten Abend zusammen,
ich bin kürzlich über das Problem gestolpert, dass XPSE eine ziemlich große Quelldatei von mir nicht mehr verarbeiten konnte. Variablen wurden plötzlich als nicht definiert gemeldet und andere "erratische" Probleme mehr. Ich könnte 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 für Operatoren und alte Containerfunktionen *extrem schnelle native fbPROCs, sofern man FreeBasic installiert hat (kostenlos, siehe Hilfe) *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 über @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 DLLs 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 natürlich nicht in XProfan geschrieben, da eine interpretierte Sprache hierfür naturgemäß viel zu langsam ist) *beim Start von JRPC3 bereits vorhandene .prc-Dateien 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 (Hilfe --> online nach Updates suchen) *64- oder 32-bit-Version verfügbar (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 natürlich keine 64-bit-XProfan-Programme, da XProfan das nicht kann, sondern JRPC3 selbst wird als 64-bit-Programm ausgeführt *XProfan X4-Syntax verfügbar (möglicherweise noch nicht alles, da ich vermutlich 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 ausgeführt werden *Interpreter, PRCs, EXEs und XPSE können mit Administratorrechten ausgeführt werden *Prozeduren, die in dem aktuellen Programm zwar enthalten sind, aber nicht verwendet werden, werden aus der umgesetzten Datei entfernt, um die Dateigröße des Kompilats möglichst klein zu halten *Variablen, die in dem aktuellen Programm zwar enthalten sind, aber nicht verwendet werden, werden aus der umgesetzten Datei entfernt, um die Dateigröße des Kompilats möglichst 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 verfügbar 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 übergeben, 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 Hilfe --> Hilfedatei anzeigen oder mit F1 verfügbar ist.
----- /Features
Herunterladen und installieren: JRPC3 kann unten heruntergeladen werden (setup_jrpc3.exe oder als ZIP-Datei). Als Installationsverzeichnis bitte das XProfan-Stammverzeichnis angeben, also dasjenige, in dem die Dateien PROFAN.EXE, PROFCOMP.EXE, PRFRUN32.EXE etc. liegen. Alternativ kann die ZIP-Datei 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 anzeigen 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 großen 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 Autoren, die jeder so ihre Eigenheiten haben, auch funktioniert.
Fehlermeldungen und Verbesserungsvorschläge gerne an jreumsc@web.de oder hier im Forum.
Beste Grüße, Jens-Arne |
| 2.584 kB | | Bezeichnung: | JRPC3 | | Version: | 10.29 | | Kurzbeschreibung: | JRPC3-Installer | | Hochgeladen: | 15.02.2021 | | Ladeanzahl: | | | | Herunterladen | | | | 1.699 kB | | Bezeichnung: | XProfEd_JR | | Version: | 5.2 | | Kurzbeschreibung: | Alte Version ohne AutoComplete zur Sicherheit | | Hochgeladen: | 15.02.2021 | | Ladeanzahl: | | | | Herunterladen | | | | 3.777 kB | | Bezeichnung: | JRPC3 | | Version: | 10.29 | | Kurzbeschreibung: | ZIP-Datei statt Installer | | Hochgeladen: | 02.04.2021 | | Ladeanzahl: | | | | Herunterladen |
| | | XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 16.02.2021 ▲ |
| |
| | | | - Seite 19 - |
| | « Dieser Beitrag wurde als Lösung gekennzeichnet. » | | - Seite 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 | Ah, danke, ich hatte nach "VarFinder" gesucht, nicht nach "Var-Finder". |
| | | XProfan X4XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 25.10.2022 ▲ |
| |
| | RudiB. | Hallo Jens-Arne,
mir ist wieder mal ein merkwürdiger Fehler in JRPC3 aufgefallen...
...das sollte eigentlich keine Fehlermeldung verursachen... Der Quelltext ist der XProfed.prf von Roland...
Gruß Rudi |
| | | Xprofan X4 Rudolf Beske / München
Hardware: NB Intel I9 - 16GByte RAM | 30.10.2022 ▲ |
| |
| | Jens-Arne Reumschüssel | Naja, der Fehlertext ist doch selbsterklärend. In der Hilfe von XProfan steht, dass "date$" in Zukunft nicht mehr unterstützt wird. Also sollte man das auch nicht mehr verwenden. Mit {$UseOldProf} kann man das aber trotzdem tun, wenn man denn unbedingt möchte. Es ist zwar inzwischen hochbedauerlicherweise unwahrscheinlich geworden, dass es künftig noch einmal eine Version von XProfan geben wird, in der die Unterstützung für alte Funktionen tatsächlich rausfliegt, aber wir sollten die Codes trotzdem dafür einrichten, falls doch noch ein Wunder geschieht.
Beste Grüße, Jens-Arne |
| | | XProfan X4XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 30.10.2022 ▲ |
| |
| | funkheld | Habe jetzt deine neueste Version runtergeladen Jens-Arne. Es ist Toll wie du es weiter verbesserst das JRPC3.
Ich freue mich das jetzt sogar in München dieses Freebasic mit eingebaut wird.
Danke und Gruss |
| | | | |
| | Jens-Arne Reumschüssel | Version 8.25:
Neben ungezählten Bugfixes in den vorangegangenen Versionen habe ich mich in letzter Zeit intensiver damit beschäftigt, wie man Sound- und Grafikdateien hardcoden und aus dem Speicher abspielen/anzeigen kann.
Hierzu gab es bislang ja schon die DATA-Funktionen von JRPC3. Allerdings wird die Datenübergabe mit long-Zeilen sehr intensiv, wenn man größere Dateien hardcoden möchte. Dann startet das XProfan-Programm schon sehr langsam, weil es u.U. zehntausende Zeilen einlesen muss, und die Datenübergabe zur Laufzeit ist ebenfalls extrem langsam. Ein solches Programm zu kompilieren, dauert ebenfalls viel zu lange.
Daher gibt es jetzt die DATA-Funktionen (BEGINDATA und DATAFILE) auch als FreeBasic-Versionen. fbBEGINDATA und fbDATAFILE erzeugen fbProcs, die die Datenübergabe so schnell machen, dass man sie nicht mehr bemerkt, und der Programmstart wird dadurch natürlich auch nicht mehr belastet, weil die Daten ja in einer externen DLL liegen. Einmalig dauert die Kompilierung immer noch lange, aber danach kann man mit {$DontCompileFbProcs} die erneute Kompilierung verhindern und die einmal erzeugte DLL weiterverwenden.
Wenn Ihr Interesse an XProfan-Funktionen habt, die daraus Nutzen ziehen, nämlich Grafikdateien (BMP, PNG, JPG, TIF, ...) direkt aus dem Speicher zu laden und auch Sounds direkt au dem Speicher abzuspielen, kann ich hier dazu noch etwas posten. Diese Dateien kann man dann mit den oben beschriebenen Funktionen seinem Programm hardgecoded hinzufügen, ohne Extra-Dateien auf mit hinzufügen zu müssen.
Beste Grüße, Jens-Arne |
| | | XProfan X4XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 28.11.2022 ▲ |
| |
| | funkheld | Hallo Jens-Arne. Danke für dein Angebot.
Ich bin sehr interessiert an deinem Datenangebot was du oben gemacht hast.
Aber du brauchst es jetzt nicht extra für mich machen. Ich wünsche das es mehr Interessenten gibt die deine neue Richtung mit Profran auch mit machen.
Danke. |
| | | | |
| | Jens-Arne Reumschüssel | Kein Problem, los geht's:
relativ einfache PROC, die nur BMPs aus Rohdaten im Speicher erzeugen kann:
declare _hLogo%
PROC Init
declare b#
'{ 'Bild-Handles aus hardgecodeten Rohdaten generieren
DataFile b#,"Test.bmp"'muss natürlich existieren
_hLogo%=CatchBmp(b#)
dispose b#
'}
ENDPROC'Init
PROC CatchBmp'macht aus einem roh eingelesenen BMP-Bereich ein anzeigbares Bitmap mit einem Handle
Parameters MemPointer&'eine Bereichsvariable, in die das BMP binär eingelesen wurde
Declare hDC&,BITMAPFILEHEADER#,BMPInfo&,init&,hImage&
hDC&=@External("user32.dll","GetDC",@External("user32.dll","GetDesktopWindow"))
'Dim BITMAPFILEHEADER#,14 'ich glaube, das ist überflüssig (siehe unten bei Dispose BITMAPFILEHEADER#)
BITMAPFILEHEADER#=MemPointer&
BMPInfo&=MemPointer&+14
init&=MemPointer&+Long(BITMAPFILEHEADER#,10)
hImage&=External("gdi32.dll","CreateDIBitmap",hDC&,BMPInfo&,4,init&,BMPInfo&,0)
@External("user32.dll","ReleaseDC",@External("user32.dll","GetDesktopWindow"),hDC&)
'Dispose BITMAPFILEHEADER# 'ich glaube, das ist überflüssig und sogar schädlich (es würde MemPointer& freigegeben und nicht die ursprünglich allokierten 14 Bytes)
Return hImage&
ENDPROC'CatchBmp
cls
init
DrawPic _hLogo%,10,10;0
waitinput
deleteobject _hLogo%
end
Das ist ursprünglich von Sebastian König/Ts-Soft/Frank Abbing. Ich habe das offensichtliche Speicherleck in CatchBmp durch Auskommentieren behoben. |
| | | XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 29.11.2022 ▲ |
| |
| | Jens-Arne Reumschüssel | Und nun für alle möglichen Grafikformate (BMP, ICO, GIF, JPG, EXIF, PNG, TIF, WMF, EMF). Das ist von mir.
STRUCT S_GDIPlusStartupInput=GdiplusVersion&,DebugEventCallback&,SuppressBackgroundThread&,SuppressExternalCodecs&
declare _hPic%,_b#,_b2#,_GDIPlusToken&,_hGDIPlusDll&,_hIcon%,_hShlwapiDll&,_iStream&
PROC InitGDIPlus
declare gdpsi#,GDIPlusToken&
_hShlwapiDll&=@usedll("Shlwapi.dll")
_iStream&=0
_hGDIPlusDll&=@usedll("GDIPLUS.DLL")
dim gdpsi#,S_GDIPlusStartupInput
gdpsi#.GdiplusVersion&=1
gdpsi#.DebugEventCallback&=0
gdpsi#.SuppressBackgroundThread&=0
gdpsi#.SuppressExternalCodecs&=0
~GdiplusStartup(@addr(GDIPlusToken&),gdpsi#,0)
dispose gdpsi#
return GDIPlusToken&
ENDPROC'InitGDIPlus
PROC DeInitGDIPlus
parameters GDIPlusToken&
~GdiplusShutdown(GDIPlusToken&)
freedll _hGDIPlusDll&
if _iStream&
@external("Shlwapi.dll","IStream_Reset",_iStream&)
endif
freedll _hShlwapiDll&
ENDPROC'DeInitGDIPlus
PROC GDIPLoadImageFromFile'ist der Vollständigkeit halber dabei; wir wollen ja aber aus dem Speicher lesen
Parameters Image$
Declare result&,FileW#,Bitmap&
result&=0
dim FileW#,@len(Image$)+2
widestring FileW#,0=Image$
~GdipCreateBitmapFromFile(FileW#,ADDR(Bitmap&))
dispose FileW#
if Bitmap&
result&=Bitmap&
Endif
return result&
ENDPROC'GDIPLoadImageFromFile
PROC GDIPlusLoadImageFromMemory'Icons müssen ebenfalls als normale Grafiken (BMP, JPG etc.) übergeben werden, nicht als ICO-Dateien!
Parameters Image#,ReturnAsAicon%'ReturnAsAicon% kann auch weggelassen werden, dann wird ein normales Grafikhandle zurückgegeben
Declare result&,Bitmap&,hBitmap&,pc%,err%
pc%=%pcount
if pc%=1
ReturnAsAicon%=0
endif
result&=0
if _iStream&=0
_iStream&=@external("Shlwapi.dll","SHCreateMemStream",Image#,@sizeof(Image#))
else
@external("Shlwapi.dll","IStream_Reset",_iStream&)
@external("Shlwapi.dll","IStream_Write",_iStream&,Image#,@sizeof(Image#))
endif
err%=~GdipCreateBitmapFromStream(_iStream&,@addr(Bitmap&))
if err%<>0
@messagebox("GdipCreateBitmapFromStream-Error: "+@str$(err%),"",0)
endif
if ReturnAsAicon%=0
err%=~GdipCreateHBITMAPFromBitmap(Bitmap&,@addr(hBitMap&),0)
if err%<>0
@messagebox("GdipCreateHBITMAPFromBitmap-Error: "+@str$(err%),"",0)
endif
else
err%=~GdipCreateHICONFromBitmap(Bitmap&,@addr(hBitMap&))
if err%<>0
@messagebox("GdipCreateHBITMAPFromBitmap-Error: "+@str$(err%),"",0)
endif
endif
@external("GDIPLUS.DLL","GdipDisposeImage",Bitmap&)
if hBitmap&
result&=hBitmap&
Endif
return result&
ENDPROC
cls
'~CoInitialize(0) 'offenbar nicht nötig
_GDIPlusToken&=@InitGDIPlus()
datafile _b#,"test.jpg"
_hPic%=@GDIPlusLoadImageFromMemory(_b#)
drawpic _hPic%,0,0;0
~deleteobject(_hPic%)
_hIcon%=@GDIPlusLoadImageFromMemory(_b#,1)
drawicon _hIcon%,0,0
~deleteobject(_hIcon%)
dispose _b#
waitinput
DeInitGDIPlus(_GDIPlusToken&)
'~CoUninitialize() 'offenbar nicht nötig
end
|
| | | XProfan X4XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 29.11.2022 ▲ |
| |
| | Jens-Arne Reumschüssel | Und nun für Sounds (ist von mir nach einem Vorbild von Frank Abbing):
declare _memsound#
PROC PlayMemSound
parameters memsound#,synchronous%'synchronous% kann auch weggelassen werden, dann wird 0 als Default genommen (also asynchron abgespielt)
declare p%
p%:=%pcount
if p%=1
synchronous%:=0
endif
if synchronous%=0
@external("Winmm.dll","PlaySoundA",memsound#,0,~SND_MEMORY | ~SND_ASYNC)'siehe https://learn.microsoft.com/en-us/previous-versions/dd743680(v=vs.85)
else
@external("Winmm.dll","PlaySoundA",memsound#,0,~SND_MEMORY | ~SND_SYNC)
endif
ENDPROC'PlayMemSound
PROC StopSound
@external("Winmm.dll","PlaySoundA",0,0,~SND_ASYNC)'stop playing
ENDPROC'StopSound
cls
datafile _memsound#,"sound.wav"'muss natürlich existieren
playmemsound _memsound#
print "fertig."
waitinput
dispose _memsound#
end
|
| | | XProfan X4XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 29.11.2022 ▲ |
| |
| | funkheld | Hallo danke. Das ist Super. Eine tolle Sache. Danke.
Jetzt werde ich erstmal damit rumtüfteln und spielen. Der Code ist wunderbar zum Lernen. |
| | | | |
| | Jens-Arne Reumschüssel | neue Version (8.33) vorhanden: - {$Declare ...} macht »geerbte« Variablen bei JRPC3 bekannt, wenn man dieses gefährliche »Feature« von XProfan denn unbedingt nutzen möchte - {$Dim ...} macht Strukturen von Bereichsvariablen, die als Parameter in eine PROC gelangen, ohne dort gedimt zu werden, bei AutoComplete von XProfEd_JR bekannt
Bitte in beiden Fällen die Hilfe zu JRPC3 konsultieren.
Beste Grüße, Jens-Arne |
| | | XProfan X4XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM PM: jreumsc@web.de | 26.02.2023 ▲ |
| |
| | funkheld | Danke für deine neue Version. 8.34 |
| | | | |
|
AntwortenThemenoptionen | 63.220 Betrachtungen |
ThemeninformationenDieses Thema hat 8 Teilnehmer: |