Deutsch
SDK-Helfer/ Tools

JRPC neuer Präkompiler für XProfan X4 - JRPC3

 
- 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:
-die Datei, in der der Fehler auftrat, wird angezeigt (z.B. eine INC-Datei)
-es wird immer die Zeilennummer des Moduls ausgegeben, in dem der Fehler auftrat (also z.B. die Zeilennummer innerhalb einer INC-Datei), und nicht die reichlich nutzlose Zeilennummer der Ergebnisdatei
-bei allen Fehlern, insbesondere Sektionsfehlern (z.B. if, endif, endif), werden verständliche Meldungen ausgegeben, und zwar so nah wie möglich am Punkt im Quellcode, wo der Fehler zu verorten ist
-die Zeile, in der ein Fehler auftrat, kann direkt in XProfEd angezeigt werden, sofern der von mir aufgebohrte XProfEd verwendet wird (siehe unten)

*direkte Anzeige des Programmablaufes in XProfEd (sofern der unten erhältliche aufgebohrte XProfEd verwendet wird):
-{$XTRACE ON[,Verzögerung]} bewirkt, dass jede folgende Zeile direkt während des Programmablaufes in XProfEd angezeigt wird (der optionale Parameter <Verzögerung> stellt eine Pause zwischen den Zeilen in Millisekunden ein)
-{$XTRACE OFF} schaltet die Ablaufverfolgung wieder ab
-dies ist extrem nützlich, um herauszufinden, wo genau ein getestetes Programm abstürzt

*Neue Kompilerdirektive für alte Profan-Syntax für Operatoren (ab V1.64):
Für alte Codes, die z.B. @add(x%,y%) statt x%+y% verwenden, bitte nicht die Include-Datei „PROFALT.INC“ benutzen. Diese funktioniert mit JRPC3 nicht. Stattdessen ist die Compilerdirektive {$USEOLDPROF} zu verwenden. Diese schaltet die automatische Umwandlung der alten Operator-Funktionen in die aktuellen Operatoren ein.

*neue Kompilerdirektiven {$TRACEVAR ...} zur Echtzeitverfolgung von Variableninhalten, siehe Menü Hilfe --> Anleitung anzeigen (neuer XProfEd_JR unten für hervorgehobene Anzeige der Direktiven)

*neue Kompilerdirektive {$ENDNOERR} für das Wiedereinschalten der Fehlerkontrolle nach {$NOERR}

*neue Kompilerdirektiven für Zeitmessungen, siehe Menü Hilfe --> Anleitung anzeigen (neuer XProfEd_JR für hervorgehobene Anzeige der Direktiven)

*neue Kompilerdirektive {$NOCHECKDUPLICATEVARS}
es ist in XProfan möglich, Parameter- und Variablendeklarationen bedingt durch IF-Zeilen zu definieren – damit das funktioniert, muss die Prüfung auf doppelte Variablendeklarationen abgeschaltet werden, was diese Kompilerdirektive bewirkt; allerdings ist diese Prüfung dann für das gesamte Programm deaktiviert

*neue Compilerdirektive {$CONVERTFOR2WHILE}
bei Nutzung dieser Compilerdirektive werden alle FOR…ENDFOR-Schleifen zu WHILE…ENDWHILE-Schleifen konvertiert – beim Aufruf von Profan2Cpp aus JRPC3 heraus geschieht dies übrigens automatisch, da Profan2Cpp das XProfan-FOR nicht kennt (und auch das XPSE-FOR nicht)

*Kompilerdirektiven funktionieren endlich vernünftig
-Verschachtelung wird berücksichtigt (in XPSE und auch XProfan ist Verschachtelung zwar möglich, aber innerhalb von $IFDEF DASHIER wird $DEFINE DIESHIER auch dann definiert, wenn DASHIER nicht definiert ist - das ist in JRPC3 anders)
-Prozeduren, die aktuell durch eine Kompilerdirektive, deren Bedingung nicht erfüllt ist, von der Kompilierung ausgeschlossen sind, werden erkannt und es wird eine entsprechende verständliche Fehlermeldung ausgegeben. So weiß man, dass die Prozedur grundsätzlich existiert (man sich also nicht verschrieben hat), dass aber eine Kompilerdirektivendefinition geändert werden muss, um diese Prozedur zu benutzen.

*die meisten WIN32-API-Funktionen sind bereits vordefiniert mitgeliefert
-eine Einbindung z.B. von windows.ph ist nicht nötig, die API kann wie normale Headerdefinitionen verwendet werden
-bei Verwendung von WIN32-API-Funktionen im Rahmen eines Aufrufes von @external(...) wird geprüft, ob die korrekte Anzahl an Parametern übergeben wird – dies ist hilfreich, weil anderenfalls oft ein Programmabsturz ohne Fehlermeldung erfolgt, was die Fehlersuche sehr erschwert (diese Funktion kann durch die neue Compilerdirektive {$NOAPIPARAMETERCHECK} ausgeschaltet werden)

*API-Aufrufe über @external(...) werden automatisch in @call(...)-Aufrufe umgesetzt – diese sind schneller, da die DLL-Funktionseinsprungadressen nicht bei jedem Aufruf neu ermittelt werden müssen.
-Dieses Feature lässt sich mit der neuen Compilerdirektive {$NOEXTERNAL2CALLCONVERSION} abschalten.
-In Prozeduren, die als Prozesse aufgerufen werden, wird diese Umsetzung automatisch deaktiviert, weil die im Hauptprogramm ermittelten Funktions-Einsprungadressen darin nicht bekannt sind.
-Standardmäßig werden kurze, kryptische Variablennamen für die Call-Einsprungadressen verwendet, weil XProfan diese sehr viel schneller abarbeitet als lange, sprechende Variablennamen. Da dann der umgesetzte Sourcecode aber nicht mehr aus sich heraus verständlich ist, wird ganz am Anfang des Programmes eine Legende der kurzen Variablennamen in Form von Kommentarzeilen angelegt, der zu entnehmen ist, zu welcher Einsprungsadressen-Variable welche DLL mit welcher Funktion gehört. Diese Liste ist nicht sortiert. Bitte die Suchfunktion von XProfEd benutzen, um die Variable von Interesse zu finden.
-Mit {$CALLUSELONGVARNAMES} kann auf die Verwendung von langen, sprechenden Einsprungadressen-Variablen umgeschaltet werden, um das umgesetzte Programm noch leichter debuggen zu können. Wenn alles läuft, sollte diese Compilerdirektive wieder entfernt werden, um den Code zu beschleunigen.
-Man kann eigene DLL-Funktionsdefinitionen in eine Datei schreiben, für die JRPC3 dann ebenfalls die Parameterzahl überprüft und @external(…)- zu @call(…)-Aufrufe konvertiert. Hierzu ist eine Textdatei mit beliebigem Dateinamen und der Endung „.dlldat“ zu erstellen. In jeder Zeile steht die Definition für eine Funktion, die von einer DLL exportiert wird. Zunächst ist der Name der DLL in Großbuchstaben anzugeben (z.B. »MEINEDLL.DLL«). Es folgt, getrennt durch ein »|», der Name der exportierten Funktion, wobei Groß- und Kleinschreibung zu unterscheiden ist (z.B. »MeineExportierteDllFunktion«). Dann ist noch, wieder durch »|» getrennt, die Anzahl Funktionsparameter anzugeben (z.B. »1«). Beispielzeile:
MEINEDLL.DLL|MeineExportierteDllFunktion|1
Diese Datei mit benutzerdefinierten Daten kann entweder ins XProfan-Stammverzeichnis geschrieben werden, dann werden die dort abgelegten Definitionen bei jedem Start von JRPC3 geladen. Oder sie können in einem Verzeichnis abgelegt werden, in dem ein bestimmtes Programmierprojekt, namentlich die .prf-Datei, liegt. Dann werden die Definitionen nur geladen, wenn genau dieses bestimmte Programm umgesetzt werden soll.
Zeilen, die mit »'« beginnen, werden – wie in Profan – als Kommentarzeilen ignoriert.

*Einrückungsanalyse
-Die Analyse von Verschachtelungsfehlern (z.B. fehlendes ENDIF) ist besonders schwierig, weil bei längeren Verschachtelungskaskaden prinzipiell nicht festgestellt werden kann, zu welchem bspw. IF das ENDIF fehlt. Erst am Ende einer Prozedur bzw. des Hauptprogramms steht fest, dass ein ENDIF zu wenig vorhanden ist. Wenn es sich um einen langen und komplizierten Codeblock handelt, ist es manchmal extrem mühsam, diese Verschachtelungsfehler zu finden, wenn man z.B. nach Copy/Paste-Aktionen solche Fehler produziert hat. Bei diesem Problem hilft die Einrückungsanalyse. Diese wird bei derartigen Fehlern als zusätzliche Option angeboten und kann dann mit „ü“ gestartet werden.
-Diese Analyse macht sich zunutze, dass die allermeisten Autoren ihren Code innerhalb eines IF/ENDIF-, FOR/ENDFOR-, WHILE/ENDWHILE-, REPEAT/UNTIL-Blockes einrücken. Wenn ein Verschachtelungsfehler auftritt, ist damit daher in aller Regel ein Bruch der Einrückungen verbunden, der sich feststellen lässt. Auf diese Weise lässt sich sehr viel genauer eingrenzen, wo genau das Problem liegt.
-Die Standard-Einrücktiefe des Autors wird nur anhand des Moduls ermittelt, in dem der Verschachtelungsfehler auftritt, damit ggf. genutzte Fremdmodule anderer Autoren, die evtl. andere Einrücktiefen verwenden, keine Verfälschungen erzeugen.
-Es wird nur der Codeblock analysiert, in dem der Verschachtelungsfehler auftritt (also die entsprechende Prozedur oder das Hauptprogramm).
-gefundene Einrückungsbrüche können direkt in XProfEd angezeigt werden (aufgebohrter XProfEd nötig).

*ENUMERATE-Funktionalität in Headerdateien (ab V3.17)
-In einer .ph-Datei kann mit ENUM [Startwert [Step]] eine fortlaufend weitergezählte Reihe von Ersetzungsdefinitionen erstellt werden. Die nachfolgenden Ersetzungsdefinitionen werden direkt mit »;« abgeschlossen, ohne Gleichheitszeichen und Wertangabe. Es kann jedoch optional »<Ersetzungsdefinition>=<NeuerWert>;« angegeben werden, dann wird die Aufzählung von diesem neuen Wert aus fortgesetzt. Der Step-Wert lässt sich allerdings nicht mehr verändern. Soll dies geschehen, muss ein neuer ENUM-Block verwendet werden.
-ENUMEND schließt den ENUM-Block ab.
-Diese Funktionalität von JRPC3 ist beispielsweise nützlich, wenn man fortlaufende UserMessage-Definitionen erstellen möchte, etwa im Messageraum ab $8000, der für Applikationen reserviert ist und nicht mit den windowseigenen Messages kollidiert. Wenn man später mittendrin eine neue Definition einfügen möchte, ist dies kein Problem. Bisher hätte man dann alle nachfolgenden Definitionen per Hand um eins erhöhen müssen. Es sind diverse weitere Konstellationen denkbar, in denen diese automatischen Aufzählungen sehr nützlich sind.
-Beispiele:
ENUM
Rot; '~Rot wird im Programm durch 1 ersetzt
Gruen; '~Gruen wird im Programm durch 2 ersetzt
Blau; '~Blau wird im Programm durch 3 ersetzt
ENUMEND
ENUM 100 2 'nicht mit Komma, sondern mit Leerzeichen abtrennen!
Rot; 'erhält den Wert 100
Gruen; 'erhält den Wert 102
Blau=500; 'erhält den Wert 500
Gelb; 'erhält den Wert 502
ENUMEND

*ENUMERATE-Funktionalität im Hauptprogramm (ab V3.18)
-ENUM ist auch im Hauptprogramm für Konstantendefinitionen möglich.
-Beispiele:
ENUM
%Rot 'erhält den Wert 1
%Gruen 'erhält den Wert 2
%Blau 'erhält den Wert 3
ENUMEND
ENUM 100 2 'nicht mit Komma, sondern mit Leerzeichen abtrennen!
&Rot 'erhält den Wert 100
&Gruen 'erhält den Wert 102
&Blau=500 'erhält den Wert 500
&Gelb 'erhält den Wert 502
ENUMEND

*ein mit JRPC3 gestartetes Programm (interpretiert, .prc gestartet, .exe gestartet) kann mit einem Tastendruck aus JRPC3 heraus gekillt werden (Taste »K«, Großschreibung) - dies ist sehr hilfreich, wenn ein getestetes Programm mal wieder hängenbleibt und normalerweise nur mittels des Taskmanagers beendet werden kann

*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 mit hoher Prozessorpriorität aufgerufen werden („!“ statt „c“ als Befehl benutzen), hierdurch ist er etwa 1/3 schneller – allerdings erfolgt eine UAC-Abfrage des Administratorpassworts, weil Windows diese hohe Prozessorpriorität sonst nicht zulässt; dieses Feature lohnt sich also nur bei wirklich großem Quellcode

*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)

*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

*Achtung: Variablen, die in einer Prozedur nicht deklariert sind, sondern "aus der aufrufenden Prozedur übernommen werden", sind 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.

*Prozeduren, die in dem aktuellen Programm zwar enthalten sind, aber nicht verwendet werden, werden standardmäßig aus der umgesetzten Datei entfernt, um die Dateigröße des Kompilats möglichst klein zu halten (kann mit {$NOPROCEXCLUDE} abgeschaltet werden)

*nPROCs aus XPSE:
-nPROCs werden automatisch mit XPE zu einer DLL umgesetzt und die Aufrufe der nPROCs im Programm entsprechend angepasst, sofern XPSE vorhanden ist
-das ist nützlich z.B. bei großen und komplizierten Programm, bei denen XPSE aus irgendwelchen Gründen nicht in der Lage ist, darin enthaltene nPROCs umzusetzen
-die Umsetzung wird automatisch ausgeschaltet, wenn globale Variablen aus dem Hauptprogramm mit »global« in eine nPROC übernommen werden; in diesem Fall ist XPSE manuell mit »x« aufzurufen
-generell gilt: wenn irgendetwas aus dem Hauptprogramm vorhanden sein muss, z.B. eine Funktionsadresse, die in einer nPROC mit procaddr() übernommen wird, darf die automatische Umsetzung nicht aktiv sein – sie kann mit {$NONPROCPROCESSING} ausgeschaltet werden

*fast alles aus XPSE funktioniert auch in JRPC3 ({$NOERR}, {$(PRE)BATCH}, {$PUSHKEYWORD}, Interpreter, Runtime und Compiler festlegen, Shorties, ...)

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})

*als Hommage an XPSE lautet die Endung der Ausgabedatei ".enh3"

----- /Features

JRPC3 kann unten heruntergeladen werden (setup_jrpc3.exe).
Als Installationsverzeichnis bitte das XProfan-Stammverzeichnis angeben, also dasjenige, in dem die Dateien PROFAN.EXE etc. liegen. Alternativ kann die ZIP-Datei heruntergeladen und deren Inhalt manuell ins XProfan-Stammverzeichnis kopiert werden.

Benutzung: 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.

Wenn man die oben genannten erweiteren Features nutzen möchte, 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 auch funktioniert, die jeder so ihre Eigenheiten haben. Ich weiß nicht einmal, ob es überhaupt (noch) Bedarf für diesen Präkompiler gibt. Falls jemand daran Interesse hat, wollte ich ihn hier trotzdem nicht vorenthalten.

Fehlermeldungen und Verbesserungsvorschläge gerne an jreumsc@web.de.

Beste Grüße, Jens-Arne

1.883 kB
Bezeichnung:JRPC3
Version:3.18
Kurzbeschreibung: JRPC3-Installer
Hochgeladen:15.02.2021
Ladeanzahl56
Herunterladen
1.700 kB
Bezeichnung:XProfEd_JR
Version:5.2
Kurzbeschreibung: aufgebohrter XProfEd, um die Programmzeile von Fehlern, die JRPC3 findet, anzeigen zu können
Hochgeladen:15.02.2021
Ladeanzahl46
Herunterladen
2.982 kB
Bezeichnung:JRPC3
Version:3.18
Kurzbeschreibung: ZIP-Datei statt Installer
Hochgeladen:02.04.2021
Ladeanzahl30
Herunterladen
 
XProfan X4 * Prf2Cpp * XPSE * JRPC * Win10 64bit * PC i7-7700K@4,2GHz, 16 GB Hauptspeicher
PM: jreumsc@web.de
16.02.2021  
 



 
- Seite 3 -



Michael
W.
Dein System bemängelt die Angabe von 8^8.

Ich habe nicht geprüft, warum genau - denn es gibt einen einfachen Trick dies zu umgehen.

Aus "8^8" mache "8 ^ 8" und es läuft.

Es gibt einige Operatoren, die ohne Leerzeichen geschrieben werden dürfen. Auch den Sonderfall (-x) solltest du noch einmal prüfen.

P.Specht's Quellcodes in der XProfan-Foren-Community strotzen nur so vor möglichen Fehlerquellen, da er die Codes alle eng zusammen schreibt.

Da kommt schon mal die Einrückung durcheinander und noch so einiges.

Schön wäre die Möglichkeit, wenn JRPC den Code auch mal an sich selbst vorbei unbearbeitet an den Interpreter reichen kann - damit man sieht ob das so ablauffähig ist. (Es ist so umständlich, den JRPC aus- und wieder einzubauen.)
 
Alle Sprachen
System: Windows 8/10, XProfan X4
Programmieren, das spannendste Detektivspiel der Welt.
29.04.2021  
 




Jens-Arne
Reumschüssel
Hallo Michael,

zunächst einmal vorweg: Den Originalcode an den Interpreter (oder auch den Compiler, an XPSE oder an Profan2Cpp) zu übergeben, ist ganz einfach: vor "i" einmal "o" drücken.

"8^8" sollte jetzt ok sein. Ich hoffe, ich habe mir da an keiner anderen Stelle ein Problem eingehandelt, aber eigentlich sollte es in Ordnung sein.

i=(-x) funktioniert bei mir problemlos. In welcher Konstellation geht es bei Dir nicht?

Und ja, Peter Spechts Code ist sehr speziell. Aber er ist zulässig, und daran konnte ich wunderbar testen, was das Ausreizen der Möglichkeiten angeht (lange Verkettungen mit ":", viel GOTO usw. usf.).

Beste Grüße, Jens-Arne
 
XProfan X4
XProfan X4 * Prf2Cpp * XPSE * JRPC * Win10 64bit * PC i7-7700K@4,2GHz, 16 GB Hauptspeicher
PM: jreumsc@web.de
29.04.2021  
 




Jens-Arne
Reumschüssel
neue Versionen:

V2.08: beim Aufruf mit Originalcode ("o") werden nun alle Compilerdirektiven entfernt, die das jeweils genutzte Programm (XProfan, XPSE, Profan2Cpp) nicht versteht

V2.09: {$ENDNOERR} schaltet die Fehlerkontrolle nach {$NOERR} wieder ein

V3.00:
*nPROCs aus XPSE:
-nPROCs werden automatisch mit XPE zu einer DLL umgesetzt und die Aufrufe der nPROCs im Programm entsprechend angepasst, sofern XPSE vorhanden ist
-das ist nützlich z.B. bei großen und komplizierten Programm, bei denen XPSE aus irgendwelchen Gründen nicht in der Lage ist, darin enthaltene nPROCs umzusetzen
-die Umsetzung wird automatisch ausgeschaltet, wenn globale Variablen aus dem Hauptprogramm mit »global« in eine nPROC übernommen werden; in diesem Fall ist XPSE manuell mit »x« aufzurufen
-generell gilt: wenn irgendetwas aus dem Hauptprogramm vorhanden sein muss, z.B. eine Funktionsadresse, die in einer nPROC mit procaddr() übernommen wird, darf die automatische Umsetzung nicht aktiv sein – sie kann mit {$NONPROCPROCESSING} ausgeschaltet werden
 
XProfan X4 * Prf2Cpp * XPSE * JRPC * Win10 64bit * PC i7-7700K@4,2GHz, 16 GB Hauptspeicher
PM: jreumsc@web.de
01.05.2021  
 




Jens-Arne
Reumschüssel
V3.05 behebt einen Fehler bei den API-Header-Vordefinitionen:
Bei ~GetForegroundWindow() war ein Komma zu viel vorhanden; diese Funktion hat keine Parameter. Dies war auf einen entsprechenden Fehler in XProfans windows.ph-Datei zurückzuführen. Es ist im Moment nicht bekannt, ob weitere derartige Fehler bei Funktionen mit 0 Parametern vorhanden sind.

Weiß von Euch übrigens zufällig jemand, wie man die korrekte Parameterzahl für die Windows-API-Funktionen in den diversen dazugehörenden DLLs herausbekommt? Also z.B. für die Funktionen in User32.dll. INC_Gen.exe produziert da haufenweise Fehler, also z.B. 0 Parameter, wo eigentlich 6 erwartet werden etc. Außerdem extrahiert INC_Gen.exe oft nicht alle Funktionen aus den DLLs.

Offenbar muss man die DLLs disassemblieren, um die Parameteranzahl der Funktionen zu bestimmen. Dass das gerne mal schiefgeht, kann ich mir vorstellen. Gibt es ein Programm, dass diese Werte zuverlässig in eine Datei ausgibt, die man danach automatisiert auswerten kann?

Dann könnte man in JRPC3 @external(...)-Aufrufe bei den gängigsten API-Funktionen auf eine korrekte Parameterzahl prüfen. Wenn die nicht stimmt, stürzt das Programm nämlich gerne ohne Fehlermeldung ab, und man hat seine liebe Not herauszufinden, warum das so ist.

Beste Grüße, Jens-Arne
 
XProfan X4
XProfan X4 * Prf2Cpp * XPSE * JRPC * Win10 64bit * PC i7-7700K@4,2GHz, 16 GB Hauptspeicher
PM: jreumsc@web.de
19.06.2021  
 




p.specht
Jetzt trage ich sicher Eulen nach Athen und werde gleich ganz doof dastehen:
Sind die Parameter nicht auf MSDN in den api-Beschreibungen zu finden? [...]  [...] 
 
XProfan 11
Computer: Gerät, daß es in Mikrosekunden erlaubt, 50.000 Fehler zu machen, zB 'daß' statt 'das'...
19.06.2021  
 



 
- Seite 4 -



Jens-Arne
Reumschüssel
p.specht (19.06.2021)
Jetzt trage ich sicher Eulen nach Athen und werde gleich ganz doof dastehen:
Sind die Parameter nicht auf MSDN in den api-Beschreibungen zu finden?


Natürlich sind sie das. Aber hättest Du Lust, für tausende von API-Funktionen von dort händisch die jeweilige Parameteranzahl zusammenzusammeln, um dann in JRPC3 darauf prüfen zu können?
 
XProfan X4
XProfan X4 * Prf2Cpp * XPSE * JRPC * Win10 64bit * PC i7-7700K@4,2GHz, 16 GB Hauptspeicher
PM: jreumsc@web.de
19.06.2021  
 




p.specht
*genier*
 
XProfan 11
Computer: Gerät, daß es in Mikrosekunden erlaubt, 50.000 Fehler zu machen, zB 'daß' statt 'das'...
19.06.2021  
 




Jens-Arne
Reumschüssel
Alles gut!
 
XProfan X4
XProfan X4 * Prf2Cpp * XPSE * JRPC * Win10 64bit * PC i7-7700K@4,2GHz, 16 GB Hauptspeicher
PM: jreumsc@web.de
19.06.2021  
 




Jens-Arne
Reumschüssel
Programmversion 3.06:

Der Check auf die korrekte Anzahl Parameter bei API-Aufrufen über @external(...) ist nun eingebaut. Ich habe eine entsprechende Quelle gefunden. Dabei konnten die vordefinierten API-Befehle und -Konstanten auch gleich um einige zehntausend erweitert werden (vorher: 10.811, jetzt: 61.467).

EDIT: Musste V3.06c nachschieben, weil es API-Konstanten gibt, die gleichnamig mit API-Funktionen sind (z.B. ~MultiByteToWideChar). Da mussten die wenigen Konstanten, bei denen das so ist, leider rausfliegen, weil es sonst zu Doppeldeutigkeiten kommt, die nicht gesund sind (123 Stück, um genau zu sein).
 
XProfan X4 * Prf2Cpp * XPSE * JRPC * Win10 64bit * PC i7-7700K@4,2GHz, 16 GB Hauptspeicher
PM: jreumsc@web.de
20.06.2021  
 




Jens-Arne
Reumschüssel
V3.09:

API-Aufrufe über @external(...) werden jetzt automatisch in @call(...)-Aufrufe konvertiert. Diese arbeiten schneller, weil dabei die Einsprungadresse der Funktion in der DLL nicht jedes Mal festgestellt werden muss.

Dieses Feature lässt sich mit der Compilerdirektive {$NOEXTERNAL2CALLCONVERSION} abschalten. Dies ist immer dann nötig, wenn Prozeduren als Prozesse aufgerufen und darin @external(...)-API-Aufrufe verwendet werden, weil die im Hauptprogramm definierten @call(...)-Adressen sonst im Speichernirvana des neuen Prozesses enden würden.
 
XProfan X4
XProfan X4 * Prf2Cpp * XPSE * JRPC * Win10 64bit * PC i7-7700K@4,2GHz, 16 GB Hauptspeicher
PM: jreumsc@web.de
22.06.2021  
 




Jens-Arne
Reumschüssel
V3.16:

Bugfixes

-In Prozeduren, die als Prozesse aufgerufen werden, wird die external-zu-call-Umsetzung nun automatisch deaktiviert, weil die im Hauptprogramm ermittelten Funktions-Einsprungadressen darin nicht bekannt sind ({$NOEXTERNAL2CALLCONVERSION} ist hierfür nicht mehr nötig).
-Standardmäßig werden nun kurze und kryptische Variablennamen für die Call-Einsprungadressen verwendet, weil XProfan diese sehr viel schneller abarbeitet als lange, sprechende Variablennamen. Da dann der umgesetzte Sourcecode aber nicht mehr aus sich heraus verständlich ist, wird ganz am Anfang des Programmes eine Legende der kurzen Variablennamen in Form von Kommentarzeilen angelegt, der zu entnehmen ist, zu welcher Einsprungsadressen-Variable welche DLL mit welcher Funktion gehört (*nicht* sortiert, bitte die Suchfunktion von XProfEd nutzen, um die interessierende Variable zu finden).
-Mit {$CALLUSELONGVARNAMES} kann auf die Verwendung von langen, sprechenden Einsprungadressen-Variablen umgeschaltet werden, um das umgesetzte Programm noch leichter debuggen zu können. Wenn alles läuft, sollte diese Compilerdirektive wieder entfernt werden, um den Code zu beschleunigen.
-Man kann eigene DLL-Funktionsdefinitionen in eine Datei schreiben, für die JRPC3 dann ebenfalls die Parameterzahl überprüft und @external(…)- zu @call(…)-Aufrufe konvertiert. Hierzu ist eine Textdatei mit beliebigem Dateinamen und der Endung „.dlldat“ zu erstellen. In jeder Zeile steht die Definition für eine Funktion, die von einer DLL exportiert wird. Zunächst ist der Name der DLL in Großbuchstaben anzugeben (z.B. »MEINEDLL.DLL«). Es folgt, getrennt durch ein »|», der Name der exportierten Funktion, wobei Groß- und Kleinschreibung zu unterscheiden ist (z.B. »MeineExportierteDllFunktion«). Dann ist noch, wieder durch »|» getrennt, die Anzahl Funktionsparameter anzugeben (z.B. »1«). Beispielzeile:
MEINEDLL.DLL|MeineExportierteDllFunktion|1
Diese Datei mit benutzerdefinierten Daten kann entweder ins XProfan-Stammverzeichnis geschrieben werden, dann werden die dort abgelegten Definitionen bei jedem Start von JRPC3 geladen. Oder sie können in einem Verzeichnis abgelegt werden, in dem ein bestimmtes Programmierprojekt, namentlich die .prf-Datei, liegt. Dann werden die Definitionen nur geladen, wenn genau dieses bestimmte Programm umgesetzt werden soll.
Zeilen, die mit »‘« beginnen, werden – wie in Profan – als Kommentarzeilen ignoriert.
 
XProfan X4 * Prf2Cpp * XPSE * JRPC * Win10 64bit * PC i7-7700K@4,2GHz, 16 GB Hauptspeicher
PM: jreumsc@web.de
vor 10 Tagen  
 




Jens-Arne
Reumschüssel
V3.18: Enumerate-Funktionalität

*ENUMERATE-Funktionalität in Headerdateien (ab V3.17)
-In einer .ph-Datei kann mit ENUM [Startwert [Step]] eine fortlaufend weitergezählte Reihe von Ersetzungsdefinitionen erstellt werden. Die nachfolgenden Ersetzungsdefinitionen werden direkt mit »;« abgeschlossen, ohne Gleichheitszeichen und Wertangabe. Es kann jedoch optional »<Ersetzungsdefinition>=<NeuerWert>;« angegeben werden, dann wird die Aufzählung von diesem neuen Wert aus fortgesetzt. Der Step-Wert lässt sich allerdings nicht mehr verändern. Soll dies geschehen, muss ein neuer ENUM-Block verwendet werden.
-ENUMEND schließt den ENUM-Block ab.
-Diese Funktionalität von JRPC3 ist beispielsweise nützlich, wenn man fortlaufende UserMessage-Definitionen erstellen möchte, etwa im Messageraum ab $8000, der für Applikationen reserviert ist und nicht mit den windowseigenen Messages kollidiert. Wenn man später mittendrin eine neue Definition einfügen möchte, ist dies kein Problem. Bisher hätte man dann alle nachfolgenden Definitionen per Hand um eins erhöhen müssen. Es sind diverse weitere Konstellationen denkbar, in denen diese automatischen Aufzählungen sehr nützlich sind.
-Beispiele:

ENUM
Rot; '~Rot wird im Programm durch 1 ersetzt
Gruen; '~Gruen wird im Programm durch 2 ersetzt
Blau; '~Blau wird im Programm durch 3 ersetzt
ENUMEND

ENUM 100 2 'nicht mit Komma, sondern mit Leerzeichen abtrennen!
Rot; 'erhält den Wert 100
Gruen; 'erhält den Wert 102
Blau=500; 'erhält den Wert 500
Gelb; 'erhält den Wert 502
ENUMEND

-----

*ENUMERATE-Funktionalität im Hauptprogramm (ab V3.18)
-ENUM ist auch im Hauptprogramm für Konstantendefinitionen möglich.
-Beispiele:

ENUM
%Rot 'erhält den Wert 1
%Gruen 'erhält den Wert 2
%Blau 'erhält den Wert 3
ENUMEND

ENUM 100 2 'nicht mit Komma, sondern mit Leerzeichen abtrennen!
&Rot 'erhält den Wert 100
&Gruen 'erhält den Wert 102
&Blau=500 'erhält den Wert 500
&Gelb 'erhält den Wert 502
ENUMEND

Beste Grüße, Jens-Arne
 
XProfan X4 * Prf2Cpp * XPSE * JRPC * Win10 64bit * PC i7-7700K@4,2GHz, 16 GB Hauptspeicher
PM: jreumsc@web.de
Gestern (22:16)  
 




Antworten


Thementitel, max. 100 Zeichen.
 

Systemprofile:

Kein Systemprofil angelegt. [anlegen]

XProfan:

 Beitrag  Schrift  Smilies  ▼ 

Bitte anmelden um einen Beitrag zu verfassen.
 

Themenoptionen

1.883 Betrachtungen

Unbenanntvor 0 min.
Jürgen Strahlvor 2 min.
Jens-Arne ReumschüsselHeute (02:17)
RGHHeute (00:45)
RudiB.Gestern (22:59)
Mehr...

Themeninformationen



Admins  |  AGB  |  Anwendungen  |  Autoren  |  Chat  |  Datenschutz  |  Download  |  Eingangshalle  |  Hilfe  |  Händlerportal  |  Impressum  |  Mart  |  Schnittstellen  |  SDK  |  Services  |  Spiele  |  Suche  |  Support

Ein Projekt aller XProfaner, die es gibt!


Mein XProfan
Private Nachrichten
Eigenes Ablageforum
Themen-Merkliste
Eigene Beiträge
Eigene Themen
Zwischenablage
Abmelden
 Deutsch English Français Español Italia
Übersetzungen

Datenschutz


Wir verwenden Cookies nur als Session-Cookies wegen der technischen Notwendigkeit und bei uns gibt es keine Cookies von Drittanbietern.

Wenn du hier auf unsere Webseite klickst oder navigierst, stimmst du unserer Erfassung von Informationen in unseren Cookies auf XProfan.Net zu.

Weitere Informationen zu unseren Cookies und dazu, wie du die Kontrolle darüber behältst, findest du in unserer nachfolgenden Datenschutzerklärung.


einverstandenDatenschutzerklärung
Ich möchte keinen Cookie