| |
| |
|
 | Vorwort
XPSE bietet besonders durch das Einbetten von neuen Kompilerschaltern in den Quelltext, die Möglichkeit, unabhängig von der IDE die Behandlungsroutinen per jeden Quelltext individuell festzulegen. Dies klingt sehr theoretisch - bewährt sich jedoch vollautomatisch bei der täglichen Programmazione.
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 Panoramica 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 Mostra.
|
| 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 File 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 possibile 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} corsa - 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 naturalmente 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 per Zeile selbst aufschreibt. Die Ausgabe landet in der gleichnamigen File mit der Endung .debug.
Hierbei ist zu beachten, das die .debug-File im Verzeichnis der PRF-File 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 per den Absturz verantwortlich war. Es gilt: Erst wird die Zeile nach .debug geschrieben, und dann corsa.
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 per Zeile selbst aufschreibt. Die Ausgabe landet jedoch nicht in einer File 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 per Includedateien hinzu. Es können bis zu 5 zusätzliche Pfade angegeben werden. Die im ProfanEditor angegebenen Includepfade werden automatisch circa {$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 File (auch Include und Unità) 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 Unità, es wird kein .def-File und kein .hlp.html-File angelegt. Sollte eine der File 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 File 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 possibile 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 Aiuto (.hlp.htm-File) zum eigendlichen Identifier angezeigt. Dieser Kompilerschalter hat jedoch noch einen anderen wichtigen Zweck bei der Herstellung von Unità! XPSE wandelt API's aus Headern in direkte Call 's um. Damit die Funktionsadressen nicht mit denen aus anderen Unità, oder mit denen aus dem Hauptprogramm kollidieren wird den Variablen welche sich diese Funktionsadressen das Prefix A vorangestellt. In Unità 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 potuto 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-File 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-File 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-File dieser Exe befinden!!! XPRR muss diese beiden File 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 circa $L automatisch mit das es sich um eine Unit handelt. $L entfällt also. A wird in der Automatisch erzeugten Aiuto (.hlp.htm-File) zum eigendlichen Identifier angezeigt. Dieser Kompilerschalter hat jedoch noch einen anderen wichtigen Zweck bei der Herstellung von Unità! XPSE wandelt API's aus Headern in direkte Call 's um. Damit die Funktionsadressen nicht mit denen aus anderen Unità, oder mit denen aus dem Hauptprogramm kollidieren wird den Variablen welche sich diese Funktionsadressen das Prefix A vorangestellt. In Unità 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 possibile, 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 per XPSE Kommandozeilenparameter welche nicht ignoriert werden. Hierzu mehr im Abschnitt "Kommandozeilenparameter".
|
|
|
| |
| |
| |
|
(827)
Deutsch
English
Français
Español
Italia