| |
| |
|
 | Vorwort
XPSE bietet besonders durch das Einbetten von neuen Kompilerschaltern in den Quelltext, die Möglichkeit, unabhängig von der IDE die Behandlungsroutinen für jeden Quelltext individuell festzulegen. Dies klingt sehr theoretisch - bewährt sich jedoch vollautomatisch bei der täglichen Programmierung.
Man kann somit innerhalb des Quelltextes festlegen, wie der Quelltext behandelt werden, bzw. was alles beim/nach dem Kompilieren geschehen soll.
Einfache Beispiele hierfür sind:
· nach dem Erstellen der Exe soll diese an eine andere Stelle kopiert werden (Batchsupport)
· dieser Source ist immer mit Prf2Cpp zu kompilieren
· dieses Programm soll ein bestimmtes ICON oder eine bestimmte Ressourceinformation tragen
Werden die Compilerschalter im Quelltext angegeben, somit sind diese zusätzlich zur Syntax von XProfan (ein Dollarzeichen "$") durch geschweifte Klammern einzurahmen. Ein XPSE- Kompilerschalter sieht demzufolge z.B. so aus: {$debug} oder {$c} oder {$cleq}
Die Kompilerschalter können beliebig im Quelltext verteilt werden, Normalerweise setzt man Kompilerschalter jedoch an den Anfang eines Quelltextes. Kompilerschalter können mit einem REM-Befehl deaktiviert werden. Die Angabe von Kompilerschaltern ist nicht case-Sensitive.
Je nach Typ des Schalters addieren sich entweder die auszuführenden Optionen, oder sie werden durch die letzte gültige Angabe überschrieben. (Ich glaube diesen Satz versteht man erst wenn man sich die Schalter angesehen hat)
Die Kompilerschalter im Einzelnen
Shorties
| Shorties sind Kompilerschalter welche aus nur einem Buchstaben bestehen und die Besonderheit haben, auch miteinander innerhalb einer Kompilerschalteranweisungszeile verknüpft zu werden. Es ist also nicht nötig z.B. in der ersten Zeile {$C} und in der zweiten Zeile {$L} zu schreiben, sondern Shorties können derart verknüpft werden: {$CLEQ}. Bei Shorties spielt auch die Reihenfolge der Angaben keine Rolle da XPSE selbst bestimmt welche Reihenfolge die schlüssigste ist. Es macht also keinen Unterschied ob {$CLEQ} oder {$QLCE} geschrieben wird. Der Übersicht halber ist jedoch empfohlen die Schalter auch in der logischen Abfolge anzugeben. Ein Linken macht z.B. erst nach dem Compilieren Sinn, und das Starten der Exe erfolgt beispielsweise auch nicht vor dem Linken.
{$C}
<i>Compile</i> | Der Quelltext ist zu kompilieren. Hierbei sind auch andere Compilerschalter - welche sich auf den Vorgang des Kompilierens beschränken - zu beachten.
| {$E}
<i>Exe</i> | Nach dem Linken die erzeugte Exe starten.
| {$I}
<i>Interprete</i> | Quelltext im Interpretermodus starten.
| {$L}
<i>Link</i> | Nach dem Kompilieren linken.
| {$Q}
<i>Quietmode</i> | Wenn kein Error beim Operieren auftrat schließt sich XPSE vollautomatisch nach verrichteter Arbeit.
| {$R}
<i>Run</i> | Nach dem Kompilieren wird die kompilierte PRC gestartet.
| {$S}
<i>ShowSource</i> | Erzeugten reinen XProfan-Quelltext anzeigen.
|
| Die anderen Kompilerschalter
(Non-Shorties) | Diese Kompilerschalter müssen jeweils in einer eigenen Zeile stehen. Es können auch nicht mehrere Compilerschalter mit Befehlstrennungszeichen innerhalb einer einzelnen Zeile angegeben werden. Einige Kompilerschalter erwarten einen Parameter. Die Angabe eines nötigen Parameters ist mit A gekennzeichnet.
>batch  {$BATCH A} | Führt A nach dem Abarbeiten der Compilerschalter aus. A kann auf eine Batchdatei oder auf ein Programm zeigen, oder direkt ein Batchbefehl sein. Es kann nur ein Batchbefehl angegeben werden, was z.B. bei $INCLUDEPATH anders ist. TIP: Beim Angeben von Pfaden oder Dateinamen welche ein Freizeichen beinhalten sollten Anführungszeichen verwendet werden um die Pfad+Dateiangaben einzuschließen. Das ist keine XPSE-Maßgabe sondern CMD erfordert dies.
'Beispiel:
{$cleq}
{$batch copy "C:xprofan1.exe" "C:1.exe"}
| | >compiler {$COMPILER A} | Legt Datei A als Compiler zum Kompilieren des Quelltextes fest. A kann direkt auf eine profcomp.exe zeigen, oder auf ein Verzeichnis. Wenn Beispielsweise in einem Unterverzeichnis namens P8 der zu verwendende Kompiler liegt, reicht folgende Angabe: {$COMPILER P8}. Selbstverständlich kann auch der gesammte Pfad angegeben werden. Durch diesen Kompilerschalter ist es möglich innerhalb des Quelltextes den damit zu verknüpfenden Compiler anzugeben - was wiederum besonders im Umgang mit speziell-angefertigten-Runtimes im Bezug auf Ressourcen nützlich ist, denn nicht jede Runtime kann jedes Kompilat interpretieren. Wird dieser Kompilerschalter neben dem Kompilerschalter {$CPP} angegeben - so wird {$CPP} ausgeführt - und nicht der unter A angegebene Kompiler. {$CPP} ist also stärker.
| | >cpp {$CPP} | Übergibt den Quelltext statt an den XProfan-Kompiler an Prf2Cpp . Die Übergabe erfolgt natürlich nur wenn im Quelltext auch angewiesen ist das der Quelltext zu Kompilieren {$C} ist.
| | >debug {$DEBUG} | Dieser Schalter bewirkt das XPSE den Source derart umschreibt, das sich das Programm während der Ausführung Zeile für Zeile selbst aufschreibt. Die Ausgabe landet in der gleichnamigen Datei mit der Endung .debug.
Hierbei ist zu beachten, das die .debug-Datei im Verzeichnis der PRF-Datei angelegt wird - und nicht im eventuell abweichendem Ausführungsverzeichnis. Dies ist ein Sicherheitsaspekt welcher verhindern soll das bei versehendlicher Weitergabe einer Debugversion der Quelltext in das Ausführungsverzeichnis geschrieben wird - und somit der Quelltext in Abarbeitungsreihenfolge durch jeden einsehbar wäre.
Derartiges Debuggen ist besonders daher interessant - da XPSE damit auch Verschachtelungen des Quelltextes sichtbar macht - und man bei einem möglichen Programmabsturz genau sieht welche Zeile in welcher Prozedur für den Absturz verantwortlich war. Es gilt: Erst wird die Zeile nach .debug geschrieben, und dann ausgeführt.
Optional kann auch {$DEBUG ONLYPROCS} verwendet werden. Die Ausgabe wird darauf eingeschränkt nur Prozeduraufrufe und das Verlassen von Prozeduren zu protokollieren.
| | {$DEBUG KERNELOUT} | Dieser Schalter bewirkt das XPSE den Source derart umschreibt, das sich das Programm während der Ausführung Zeile für Zeile selbst aufschreibt. Die Ausgabe landet jedoch nicht in einer Datei sondern kann mit einem Debugviewer angezeigt werden. Hier empfehle ich DebugView von Sysinternals: https://www.sysinternals.com/Utilities/DebugView.html In allen anderen Aspekten gleicht dieser Schalter dem {$DEBUG} - Schalter. Optional kann auch {$DEBUG KERNELOUT ONLYPROCS} verwendet werden. Die Ausgabe wird darauf eingeschränkt nur Prozeduraufrufe und das Verlassen von Prozeduren zu protokollieren.
| | >includepath {$INCLUDEPATH A} | Fügt A auf den Stapel der zu durchsuchenden Pfade für Includedateien hinzu. Es können bis zu 5 zusätzliche Pfade angegeben werden. Die im ProfanEditor angegebenen Includepfade werden automatisch über {$INCLUDEPATH} eingebunden.
| | >log {$LOG} | Operationen wie z.B. Linken oder Kompilieren, die diesen Quelltext betreffen, werden in die xpse.log geschrieben.
| | >mapfile {$MAPFILE} | Dieser Schalter übergibt den Kommandozeilenparameter "-M" an den XProfanCompiler weiter. Nähere Erläuterungen was "-M" bedeutet ist der XProfanhilfe (ab Version 9) => "Mapdatei" zu entnehmen. Im MapFile steht welche Zeilennummer welcher Datei (auch Includes und Units) angehört.
| | >noerr {$NOERR} | Dieser Schalter bewirkt das Warnings und Errors gänzlich übersehen werden, sodaß ein Weiterarbeiten mit XPSE auch dann gewährleistet ist wenn XPSE etwas nicht versteht was aber syntaktisch korrekt ist. (Mögliche Neuerungen in der XProfansprache selbst etc...)
| | >nodef {$NODEF} | Betrifft nur Units, es wird kein .def-File und kein .hlp.html-File angelegt. Sollte eine der Dateien vorhanden sein wird sie gelöscht.
| | >nosectioncheck {$NOSECTIONCHECK} | Dieser Schalter schaltet die Sektionskontrolle ab. Hiermit ist gemeint das Fehler wie:
geduldet werden. Von der Nutzung des Schalters rate ich ab. Es kann jedoch die Situation auftreten das man z.B. innerhalb einer älteren Includedatei z.B. Prozeduren innerhalb von IF-Blöcken deklariert hat. Um einen Abbruch aller Vorgänge in diesem Fall entgegenzuwirken ist dieser Kompilerschalter anzuwenden.
| | >runtime {$RUNTIME A} | Legt Datei A als Runtime zum Linken und/oder zum Ausführen fest. A kann direkt auf eine prfrun32.exe zeigen, oder auf ein Verzeichnis. Wenn Beispielsweise in einem Unterverzeichnis namens P8 die zu verwendende Runtime liegt, reicht folgende Angabe: {$RUNTIME P8}. Selbstverständlich kann auch der gesammte Pfad angegeben werden. Durch diesen Kompilerschalter ist es möglich innerhalb des Quelltextes die damit zu verknüpfende Runtime anzugeben - was besonders im Umgang mit speziell- angefertigten-Runtimes im Bezug auf Ressourcen nützlich ist.
| | >prebatch {$PREBATCH A} | Führt A vor dem Abarbeiten der Compilerschalter aus. A kann auf eine Batchdatei oder auf ein Programm zeigen, oder direkt ein Batchbefehl sein. Es kann nur ein Batchbefehl angegeben werden, was z.B. bei $INCLUDEPATH anders ist. TIP: Beim Angeben von Pfaden oder Dateinamen welche ein Freizeichen beinhalten sollten Anführungszeichen verwendet werden um die Pfad+Dateiangaben einzuschließen. Das ist keine XPSE-Maßgabe sondern CMD erfordert dies.
'Beispiel:
{$cleq}
{$prebatch copy "C:xprofan1.exe" "C:1.exe"}
| >preferednamespace {$PREFEREDNAMESPACE A}
<iMg src='images/pxt.gif' width=189 height=1/> | Veraltet. Siehe <a href='#unit'>{$unit}. Legt den bevorzugten Namensraum dieser Unit auf A fest. A wird dann in der Automatisch erzeugten Hilfe (.hlp.htm-Datei) zum eigendlichen Identifier angezeigt. Dieser Kompilerschalter hat jedoch noch einen anderen wichtigen Zweck bei der Herstellung von Units! XPSE wandelt API's aus Headern in direkte Call 's um. Damit die Funktionsadressen nicht mit denen aus anderen Units, oder mit denen aus dem Hauptprogramm kollidieren wird den Variablen welche sich diese Funktionsadressen das Prefix A vorangestellt. In Units ist dieser Schalter somit Pflicht. Aber keine Sorge, XPSE meckert wenn ihm was nicht passt. :)
Siehe auch export , noexport und unitsupport .
| | >pushkeyword {$PUSHKEYWORD A} | A kann ein einzelnes Keyword, oder eine Aufzählung von Keywords sein welche mit Komma voneinander getrennt werden. Dieser Kompilerschalter ist ein Veralterungsschutz des XPSE. Mit dem Schalter kann man XPSE erklären das die angegebenen KeyWords zum Sprachschatz gehören. Der Schalter könnte z.B. in einer INC vorkommen welche eingebunden wird, oder auch als Beilage zu einer Unit dienen um die darin enthaltenen Befehle aufzuzeigen.
| | >res {$RES A} | A kann ein einzelnes Keyword, oder eine Aufzählung von Keywords sein welche mit Komma voneinander getrennt werden. Dieser Kompilerschalter legt fest das bestimmte Ressourcen der Exe mit XPRR (XProfan Ressource Rebuilder von Frank Abbing https://frabbing.de ) verändert werden sollen. Das können z.B. das Exeicon, die Versionsinformation, das Fenstericon oder andere Ressourcen sein.
NOMANIFEST
NOVERSIONINFO
ICON ""
WINDOWICON ""
EXEICON ""
COMPANYNAME ""
FILEDESCIPTION ""
FILEVERSION "1.0.0.0"
INTERNALNAME ""
LEGALCOPYRIGHT ""
LEGALTRADEMARK ""
ORIGINALFILENAME ""
PRODUCTNAME ""
PRODUCTVERSION "1.0.0.0"
Syntax 1:
{$res productname "meinProduktname"}
{$res icon "test.ico"}
Syntax 2:
{$res productname "meinProduktname", icon "test.ico", productversion "1.0.0.0", ...}
Frank Abbing:
Ich möchte nochmal deutlicher erklären, wie XPRR mittels XPSE benutzt werden kann:<bR/><bR/><tAbLe style="border:dotted;color:#6666FF" cellspacing=5 cellpadding=5><tR><td><font size=2><b>Icon Resource:</b><bR/><bR/><u>Fenstericon und Exeicon ändern:</u><bR/>{$res icon "dateiname.ico" [icongröße] [mindest-icon-bittiefe]}<bR/><bR/><u>Nur Fenstericon ändern:</u><bR/>{$res windowicon "dateiname.ico" [icongröße] [mindest-icon-bittiefe]}<bR/><bR/><u>Nur Exeicon ändern:</u><bR/>{$res exeicon "dateiname.ico" [icongröße] [mindest-icon-bittiefe]}<bR/><bR/>Die Icongrösse darf weggelassen werden, in dem Fall wählt XPRR aus einer Mehrfach-Icon-Datei das letzte Icon aus. Gültige Grössen sind z.B.: 16, 24, 32, 48, 64, 128, ...<bR/>Die Mindest-Icon-Bittiefe darf weggelassen werden, in dem Fall wählt XPRR aus einer Mehrfach-Icon-Datei das letzte Icon aus. Gültige Bittiefen sind:<bR/>1=2 Farbe, 4=16 Farben, 8=256 Farben, 24=True Color (24 Bits), 32=True Color+Alpha (32 Bits)</font></tR></tD></tAbLe><bR/><tAbLe style="border:dotted;color:#6666FF" cellspacing=5 cellpadding=5><tR><td><font size=2><b>Manifest Resource 24:</b><bR/><bR/><u>Manifest-resource entfernen:</u><bR/>{$res nomanifest}</font></tR></tD></tAbLe><bR/><tAbLe style="border:dotted;color:#6666FF" cellspacing=5 cellpadding=5><tR><td><font size=2><b>Version-Info Resource:</b><bR/><bR/><u>Version-Resource entfernen:</u><bR/>{$res noversioninfo}<bR/><bR/><u>Einzelne Rubriken der Version-Resource erstellen:</u><bR/>{$res companyname "Firmenname"}<bR/>{$res filedescription "Dateibeschreibung"}<bR/>{$res fileversion "Dateiversion"}<bR/>{$res internalname "Dateiname"}<bR/>{$res legalcopyright "Copyright-Beschreibung"}<bR/>{$res legaltrademark "Trademark-Beschreibung"}<bR/>{$res originalfilename "Originaler Dateiname"}<bR/>{$res productname "Name der Anwendung"}<bR/>{$res productversion "Anwendungsversion"}<bR/><bR/>Jede Rubrik darf maximal 256 Zeichen lang sein.<bR/>FILEVERSION und PRODUKTVERSION müssen immer vierstellig Werte sein, getrennt durch einen Punkt.Eine ganz ordinäre Version 1 müsste dann so aussehen: 1.0.0.0, was unter Windows Major.Minor.Build.QFE bedeutet.</font></tR></tD></tAbLe><bR/>Für alle XProfan-Exedateien, die mit XPRR bearbeitet werden sollen gilt:<bR/><bR/><b>Im gleichen Ordner wie die Profan-Exedatei muss sich auch die PRC-Datei dieser Exe befinden!!! XPRR muss diese beiden Dateien nach getaner Arbeit manuell neu verlinken.</b><bR/><bR/>XPSE ist in der Lage, mehrere XPRR-Anweisungen in einer Zeile abzuarbeiten, getrennt durch Kommata.<bR/>XPRR sollte sich im gleichen Ordner befinden wie XPSE.<bR/><bR/>
| | >unit {$UNIT A} | Legt den bevorzugten Namensraum dieser Unit auf A fest und teilt dem XProfanKompiler über $L automatisch mit das es sich um eine Unit handelt. $L entfällt also. A wird in der Automatisch erzeugten Hilfe (.hlp.htm-Datei) zum eigendlichen Identifier angezeigt. Dieser Kompilerschalter hat jedoch noch einen anderen wichtigen Zweck bei der Herstellung von Units! XPSE wandelt API's aus Headern in direkte Call 's um. Damit die Funktionsadressen nicht mit denen aus anderen Units, oder mit denen aus dem Hauptprogramm kollidieren wird den Variablen welche sich diese Funktionsadressen das Prefix A vorangestellt. In Units ist dieser Schalter somit Pflicht. Aber keine Sorge, XPSE meckert wenn ihm was nicht passt. :)
Siehe auch export , noexport und unitsupport .
|
| | Kompilerschalter als Kommandozeilenparameter | Kompilerschalter als Kommandozeilenparameter werden ignoriert. Aus kompatiblitätsgründen zu verschiedenen IDE's ist die Angabe von Kompilerschaltern per Kommandozeilenparameter zwar möglich, so das XPSE diese erkennt und damit trotzdem den "richtigen" Dateinamen ermitteln kann, aber die übergebenen Schalter werden Aufgrund der möglichen Konflikte mit Kompilerschaltern im Quelltext übergangen. Folgende Kommandozeilenparameter welche aus den verschiedenen IDE's bekannt sind werden erkannt und terminiert: -E -B -L -S -R -M -V -LINK
Es gibt jedoch speziell für XPSE Kommandozeilenparameter welche nicht ignoriert werden. Hierzu mehr im Abschnitt "Kommandozeilenparameter".
|
|
|
| |
| |
| |
|
(936)
Deutsch
English
Français
Español
Italia