 | Xpse
Kategorie: Sheets, Sonstige
XPSE → Fehler ausmerzen, Quelltext optimieren, Programme beschleunigen und stabiler machen, sauberer programmieren, Entwicklungszeit sparen.
Mit dem XProfan-Syntax-Enhancer statten Sie Ihr XProfan mit zusätzlichen Befehlen, und einer erweiterten Syntax aus.
XPSE unterstützt die neuste XProfan-Version und orientiert sich am neuesten Release. XPSE wird immer kostenlos sein.
Fragen, Anmerkungen und Bugs bitte im Supportforum http://xprofan.com/thread.mx?f=32  posten
oder, wenns anonym sein soll, in der Bugnity unter "XProfanverwandtes Programm" http://xprofan.com/bugreport.html .
|
| |
XPSE wird durch Einwirkung der XProfan-Community ständig verbessert und ist dazu da, die Wünsche der Profan-Community im Bezug auf die XProfan- Programmierung umzusetzen. XPSE ist ein Hilfsmittel welches dem XProfan-Programmierer auf einfache Art und Weise - neben den anderen Features - auch mehr Syntax-Komfort bietet.
Alleine die Erschaffung einer solchen Programmgrundlage kann schon nachhaltig und positiv in die Weiterentwicklung von XProfan einfließen, und das tut sie auch, denn es wurden bereits eine Menge Features - auch wenn nicht 1:1 - übernommen oder haben als Gedankengrundlage gedient.
Der Autor des XPSE (David Strutz) übernimmt keine Haftung bei/für Schäden an Hard/-oder Software, welche durch Nutzung des XPSE entstehen könnten. Es ist jedoch bisher kein kein Schadensfall bekannt. :D Der XPSE ist freeware und kann/darf insofern dieser unverändert ist, beliebig weitergegeben werden. Disassembling und Debugging ist erlaubt. Der Quelltext verbleibt beim Autor und steht nicht zur freien Verfügung. Die Aufnahme in Heft / Shareware-CD's, oder Download-Zentren, oder auf CD's gleich welcher Art ist erwünscht und auch ohne Nachfrage bei Angabe der URL: http://xprofan.com gestattet.
[Textblock - xpse.intro]
|
| | | Installation und Handhabung | [top] |
|
| |
XPSE muss und braucht nicht installiert zu werden!
Um die Vorzüge des XPSE nutzen zu können muss lediglich in der jeweiligen IDE eine lieblings-Tastenkombination festgelegt werden welche den XPSE startet - mit als Parameter übergebenem Quelltextdateinamen. Genaus so - wie auch ProfComp.Exe oder die Profan.Exe genutzt wird, nur halt XPSE.EXE.
Wenn die IDE keine Möglichkeit bietet - eine extra Tastenkombination festzulegen - dann einfach in den Einstellungen der IDE, statt Profan.Exe, die XPSE.EXE angeben. Das wars schon!
XPSE-Nutzer müssen nicht ProfComp.Exe (den Kompiler von XProfan) oder die Profan.Exe (den Interpreter von XProfan) aus der IDE aufrufen! Es muss einfach nur der XPSE festgelegt werden welcher mit der Quelltextdatei aufgerufen wird - statt Profan.Exe oder ProfComp.Exe.
|
| | | Warum XPSE statt ProfanComp? | [top] |
|
| |
Nicht "statt", nur die Reihenfolge wird geändert. Zuerst schaut sich XPSE den Quelltext an - und erzeugt eine neue gleichnamige Datei mit der Endung ".enh" - und diese .ENH wird an den XProfankompiler weitergegeben. Die .ENH enthält den veränderten, optimierten und von XPSE bearbeiteten Quelltext. Die orginal .PRF-Datei bleibt unverändert.
XPSE ist schneller als Profan.Exe und schneller als der XProfanKompiler was das Aufspühren von Fehlern im Quelltext betrifft, und XPSE ist strenger was zu fehlerfreierer Software führt.
Angenommen sie schreiben einen größeren Quelltext dessen Kompilierung 15 Sekunden dauert, und Sie sind es gewohnt den XProfanKompiler über mögliche Fehler berichten zu lassen. Nun drücken sie z.B. F9 für das Kompilieren und der XProfanKompiler kompiliert 15 Sekunden. Dieser Vorgang wird warscheinlich sehr oft wiederholt - z.B. jedes Mal wenn eine Änderung im Quelltext stattfand. Jedes Mal 15 Sekunden. Auf dauer ist dies uneffizient - auch wenn es für den XProfanAnfänger noch unverständlich klingen mag. XPSE hingegen bekommt als Erster den Quelltext und prüft oft mehr als 10 Mal schneller den Quelltext auf Fehler. Es wird Zeit gespart da im Fehlerfall nicht kompiliert wird.
Der Source wird auch gleichzeitig zu einer Art Make.Bat! XPSE prüft den Quelltext auf XPSE-Kompilerschalter. Diese Schalter bieten eine Menge Möglichkeiten welche über die normalen XProfanmöglichkeiten des XProfanKompilers hinaus gehen. Es kann einfach im Quelltext selbst festgelegt werden wie mit den Source zu verfahren ist! Z.B. ob er zu kompilieren ist, ob zu linken ist, ob eine Batchdatei ausgeführt werden soll (z.B. um die Exe nach dem Linken an eine andere Stelle zu kopieren) etc.etc. Wenn z.B. im Source an einer beliebigen Stelle (vorzugsweise am Start) {$cleq} steht, dann wird das Programm sofort nachdem XPSE fertig ist kompiliert, gelinkt und die fertige Exe wird ausgeführt. Das "q" steht für "quiet" - sodass sich XPSE nach all dem automatisch beendet.
Ohne Angabe von XPSE-KompilerSchaltern bietet XPSE die Möglichkeit - nach verrichteter Arbeit - durch Drücken von einzelnen "SchnellTasten" mit dem Source weiter-zu-verfahren. Z.B. durch Drücken von C wird der Source kompiliert, L gelingt, E die Exe wird ausgeführt.
XPSE verändert den Quelltext der .ENH-Datei, nicht aber den Originaltext. Der Quelltext wird auf Geschwindigkeit optimiert. Es gibt viele Beispiele an denen zu sehen ist das XPSE-VorOptimierte Programme deutlich schneller ablaufen.
Die .ENH-Datei ist z.B. frei von Remarks, überflüssigen Freizeilen/Zeichen und frei von virtuellen Umbrüchen. Das sorgt wiederum für ein schnelles Kompilieren durch den XProfanKompiler - was sich besonders bei größeren Programmen bemerkbar macht.
XPSE kann ein LogFile führen {$log} - daraus zu entnehmen sind die Aktivitäten welche XPSE durchführte. Es dient einfach nur zur Information für den Programmierer - er kann z.B. sehen wieviel Zeit er an einem Programm verbringt. :D
Syntaktische Vorteile - wie z.B. das Weglassen der Standardheaderdateien - da XPSE diese intus hat. Es kann einfach jede API, Konstante oder Struktur verwendet werden ohne diese zu deklarieren! Durch das Weglassen der Headerdefinitionen ist der XProfanKompiler deutlich schneller! Aber auch wenn HeaderFiles angegeben werden - so lern XPSE diese und wandelt die Aufrufe entsprechend um - sodaß dem XProfanKompiler auch die angegebenen HeaderFiles nicht "zugesandt" werden. Es können also natürlich trotzdem Headerfiles angegeben werden, nur diese folgenden Headerfiles brauchen nicht angegeben zu werden (wenn nicht angegeben, dann ist sogar XPSE noch schneller beim Umwandeln der Apis:)
Folgende HeaderFiles hat XPSE intus: windows.ph, messages.ph, commctrl.ph, structs.ph, Avi.ph, gdi.ph, OpenGL.ph, richedit.ph, shellapi.ph
XPSE wandelt die ApiAufrufe aus den Headerdefinitionen in die schnelleren Calls um! Dadurch wird das Programm nicht nur schneller - sondern auch sicherer da ein Austausch von Prozeduradressen wärend der Laufzeit des Programmes sogut wie unmöglich gemacht wird. Wer gerne mal die Zeitunterschiede selber messen möchte: http://xprofan.com/forum.php?t=3765
[Textblock - xpse.installation]
|
| |
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}
Compile |
→ | Der Quelltext ist zu kompilieren. Hierbei sind auch andere Compilerschalter - welche sich auf den Vorgang des Kompilierens beschränken - zu beachten. | {$E}
Exe |
→ | Nach dem Linken die erzeugte Exe starten. | {$I}
Interprete |
→ | Quelltext im Interpretermodus starten. | {$L}
Link |
→ | Nach dem Kompilieren linken. | {$Q}
Quietmode |
→ | Wenn kein Error beim Operieren auftrat schließt sich XPSE vollautomatisch nach verrichteter Arbeit. | {$R}
Run |
→ | Nach dem Kompilieren wird die kompilierte PRC gestartet. | {$S}
ShowSource |
→ | 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 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:\xprofan\1.exe" "C:\1.exe"}
|
| | {$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} |
→ | Ü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} |
→ | 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: http://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 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} |
→ | Operationen wie z.B. Linken oder Kompilieren, die diesen Quelltext betreffen, werden in die xpse.log geschrieben.
| | {$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} |
→ | 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} |
→ | 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} |
→ | 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 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 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:\xprofan\1.exe" "C:\1.exe"}
|
| {$PREFEREDNAMESPACE A}
|
→ | Veraltet. Siehe {$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 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 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 http://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:
Icon Resource:
Fenstericon und Exeicon ändern:
{$res icon "dateiname.ico" [icongröße] [mindest-icon-bittiefe]}
Nur Fenstericon ändern:
{$res windowicon "dateiname.ico" [icongröße] [mindest-icon-bittiefe]}
Nur Exeicon ändern:
{$res exeicon "dateiname.ico" [icongröße] [mindest-icon-bittiefe]}
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, ...
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:
1=2 Farbe, 4=16 Farben, 8=256 Farben, 24=True Color (24 Bits), 32=True Color+Alpha (32 Bits) |
Manifest Resource 24:
Manifest-resource entfernen:
{$res nomanifest} |
Version-Info Resource:
Version-Resource entfernen:
{$res noversioninfo}
Einzelne Rubriken der Version-Resource erstellen:
{$res companyname "Firmenname"}
{$res filedescription "Dateibeschreibung"}
{$res fileversion "Dateiversion"}
{$res internalname "Dateiname"}
{$res legalcopyright "Copyright-Beschreibung"}
{$res legaltrademark "Trademark-Beschreibung"}
{$res originalfilename "Originaler Dateiname"}
{$res productname "Name der Anwendung"}
{$res productversion "Anwendungsversion"}
Jede Rubrik darf maximal 256 Zeichen lang sein.
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. |
Für alle XProfan-Exedateien, die mit XPRR bearbeitet werden sollen gilt:
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.
XPSE ist in der Lage, mehrere XPRR-Anweisungen in einer Zeile abzuarbeiten, getrennt durch Kommata.
XPRR sollte sich im gleichen Ordner befinden wie XPSE.
| | {$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".
|
[Textblock - xpse.kompilerschalter]
|
| | | Syntaktische Erweiterungen | [top] |
|
| |
Vorwort
"Syntaktische Erweiterungen" hört sich zwar kompliziert an, bedeutet aber lediglich das ein und das Selbe anders geschrieben werden kann. Die durch XPSE gebotenen syntaktischen Erweiterungen werden vom XPSE in "normalen" aber optimierten XProfan-Quelltext konvertiert.
Ein einfaches Beispiel für eine syntaktische Erweiterung:
| x&+
'oder
x&++
'oder
x&-
'oder
x&--
|
wird zu
konvertiert.
Ein anderes Beispiel für eine syntaktische Erweiterung anhand einer For- Schleife, weil besonders an diesem Beispiel zu erkennen ist - das syntaktische Erweiterungen die Übersicht deutlich verbessern können und/oder das Schreiben erleichtern:
wird zu
konvertiert.
Anhand diesem Beispiel wird die syntaktische Erweiterung des XPSE anhand des Konvertierens einer Funktion dargestellt:
wird zu
| DECLARE H&
USEDLL("ATL.DLL")
EXTERNAL("ATL.DLL","AtlAxWinInit")
PROC _XPSE_CREATEHTMLBOX
PARAMETERS HDL&,TXT$,XP&,YP&,XW&,YW&
RETURN CONTROL("AtlAxWin",TXT$,1345323008,XP&,YP&,XW&,YW&,HDL&,0,%HINSTANCE,$200)
ENDPROC
CLS
H&=(_XPSE_CREATEHTMLBOX((%HWND), "mshtml:<html><head></head><body><h1>Info</h1>Testinfo</body></html>", (0),(0),(320),(240)))
WAITINPUT
DESTROYWINDOW(H&)
END
|
konvertiert.
Syntaktische Erweiterungen
| Befehlstrennung |
→ | Kurzfassung: XPSE unterstützt ; und : um Befehle voneinander zu trennen.
Die Langfassung:Viele Hochsprachenkompiler bieten heutzutage das Feature des zeilenunabhängigen Parsens des Quelltextes. Streng genommen ist es den meisten Kompilern sogar egal ob der gesammte Quelltext in einer einzelnen Zeile, oder über mehere Zeilen verteilt ist. Damit dies ohne Umwege möglich ist gibt es "Befehlstrennungszeichen". In den meisten Hochsprachen ist dies Heutzutage das Semikolon. Mit dem Semikolon werden Befehle voneinander abgetrennt,- der Kompiler muss dann nicht mehr Zeilengebunden parsen. Dies kann ganz allgemein bei der Programmierung, bei der Eingabe und im Bezug auf die Übersicht von Quelltexten, viele Vorteile mitsich bringen.
Es ist nur leider so, daß die zeilenorientierten Parser das Abtrennen von Befehlen mit einem Befehlstrennungszeichen zumeist nicht unterstützen, und im Umkehrschluß - die Parser welche ausschließlich Befehle mit Befehlstrennungszeichen erwarten, keine Zeilenorientation mitsich bringen. Die Schwierigkeit ist es nun, da XProfan-Programmierer es gewohnt sind auf einen zeilenorientierten Parser zu vertrauen, beides nebenher zu ermöglichen. Dem XSPE gelang dies. XPSE bietet seit XProfan8 die Möglichkeit Befehle mit dem gewohnten Befehlstrennungszeichen "Semikolon" zu trennen - wann immer man möchte - aber mit dem Vorteil es nicht zu "müssen". RGH implementierte dann dieses Feature in die darauf folgende XProfan- Version 9. Seither bietet XProfan ebenfalls die Möglichkeit mit einem Befehlstrennungszeichen Befehle voneinander zu trennen. Jedoch nicht per Semikolon, sondern per Doppelpunkt.
Nun stand der XPSE natürlich auf dem Prüfstand. Er musste nun nicht nur dafür sorgen Zeilenorientiert oder Semikolongetrennt zu parsen, sondern es kam auch noch ein zweites Befehlstrennungszeichen dazu - welches korrekt verarbeitet werden musste. Die Schwierigkeit ist, da XProfan ja auch innerhalb der eigenen Syntax an manchen Stellen Semikolons und Doppelpunkte erwartet, trotzdem genau unterscheiden zu können wann ein neuer Befehl beginnt. Dem XPSE gelang auch dies. Mit dem XPSE kann sogar innerhalb einer einzigen Zeile wild zwischen den Befehlstrennungzeichen gewechselt werden. Sogar Anweisungen wie Case (welche einen Doppelpunkt erwartet) oder SetWindowpos (welche ein Semikolon erwartet) [und alle anderen Befehle welche ein oder mehrere Semikolons erwarten) werden beim wilden Mischen von Befehlstrennungszeichen immer richtig erkannt. Es ist mir kein Erkennungsfehler bekannt und die Anwendung dieses Features eine permanente Freude.
| | Export |
→ | Prozeduren / Funktionen in Units werden vom XPSE automatisch in eine .def Datei geschrieben - sei denn - es wird das Schlüsselwort noexport an den Prozedurnamen "mit Freizeichen getrennt" angehangen. Zur Unterstützung von Unit-Programmierern gibt es das Schlüsselwort "export". Obwohl XPSE jede "nicht-mit-noexport-gekennzeichnete" Prozedur/Funktion in die .def-Datei schreibt - bietet XPSE mit dem Schlüsselwort "export" die Möglichkeit, der eine Art Hilfetext für die jeweilige mit "export" gekennzeichnete Prozedur anzufügen. Dieser Hilfetext wird in die .hlp.htm- Datei geschrieben.
Dies ist sehr hilfreich wenn man sich ein nachträgliches Schreiben einer Hilfedatei ersparen möchte. Siehe hierzu auch den Kompilerschalter {$preferednamespace }.
| | NoExport |
→ | Wenn eine UnitProzedur oder UnitFunktion nicht automatisch vom XPSE in die .def Datei geschrieben werden soll - dann ist einfach das Schlüsselwort "noexport" - mit Freizeichen getrennt - hinter den Namen der Prozedur/Funktion zu schreiben.
Die Funktion ist damit als "nicht-öffentlich" gekennzeichnet und sollte dann auch nur innerhalb der Unit verwendet werden.
| | For-Schleifen |
→ | XPSE unterstützt For-Schleifen nach Pascal-Syntax.
Um Abwärts zu zählen, ist wie auch zu erwarten das "downto" statt "to" zu verwenden.
Auch der optionale "Step"-Parameter wird unterstützt um die Schrittweite selbst zu bestimmen.
oder Abwärts:
| | InlineAssembler |
→ | Wo "vorkompiliert" wird, können auch leicht Plugins für den Vorkompiler hergestellt werden. Diese Chance ergriff Frank Abbing (http://frabbing.de ) und stellte das Erste XPSE-PlugIn XPIA her, und später den XPRR .XPIA steht für XProfanInlineAssembler.
XPIA macht es möglich das innerhalb des XProfanprogrammes Prozeduren/Funktionen in [High-Level]-Assembler geschrieben werden können. Innerhalb des XProfanprogrammes kann auf das Ergebnis der Assemblerfunktionen ohne Probleme zugegriffen werden. Das Prinzip funktioniert so: XPSE bearbeitet den Quelltext wie gewohnt - achtet jedoch auf Assemblerpassagen welche mit ASMSTART eingeleitet, und mit ASMEND beendet werden. Es gibt auch ASMINCLUDE . Es können beliebig viele Assemblerpassagen im XProfanquelltext vorkommen. Vor dem Kompilieren - und bei Vorhandensein von Assemblerpassagen im Quelltext - wird XPIA mit dem zu bearbeitenden Quelltext gestartet. XPIA eruiert und trennt die einzelnen Assemblerpassagen und erzeugt ASM-Projekte die wiederum durch XPIA an einen Assemblerkompiler derart weitergegeben werden, daß der Assemblerkompiler eine entsprechende DLL mit dem native-kompilierten Assemblercode erstellt. Anschließend schreibt XPIA den XProfanquelltext derart um das an Stelle der Assemblerpassagen die DLL-Aufrufe stattfinden. Die erzeugte DLL wird anschließend von XPIA in einen XProfan-Quelltext konvertiert - welcher die DLL wärend der Laufzeit entpackt - so daß diese nicht mitgeliefert werden muß! Es bleibt also dabei das lediglich die Programm-Exe mitgeliefert werden muß. Das Assembler wird komplett in die EXE verpackt. Die in den Quelltext konvertierten DLL sind auch noch derart klein - das diese den Quelltext nicht aufblähen. I.d.R ist die DLL grade mal 8192 Byte groß! Das Inlineassember für XProfan war damit geboren. :)
| | INC und DEC |
→ | Variablenwert erhöhen und verringern. Einfache Syntax zur Variablenin- und dekremierung - auch wieder angelehnt an die C++ / PHP Syntax. Mittels dem Suffix ++ kann eine Variable um 1 erhöht werden, mit dem Suffix -- verringert.
Diese Variante wird z.B. in i%=i%+1 umgewandelt, es gibt jedoch lt. der Profanhilfe auch schnellere Funktionen, um eine Variable zu erhöhen oder zu verringern. Gemeint ist damit "INC" und "DEC". Dafür bietet XPSE eine noch komfortablere Variante:
Statt "DoppelPlus" bzw "Doppelminus" einfach ein einfaches "Plus" oder "Minus", und schon wird der Code nicht in i%=i%+1, sondern in inc i% konvertiert. Es gibt wohl nichts Einfacheres als i%+ zu schreiben, um i% um 1 zu erhöhen!
Experimentell/Fun: Bei Longs kann auch ohne Angabe des Variablensuffixes derart gearbeitet werden. Wird kein Variablensuffix angegeben, so nimmt XPSE an es ist ein Long. Wer also z.B. ein Long namens cnt& Inkremieren möchte braucht nur cnt+ oder cnt++ schreiben. Wobei auch hier gilt: cnt+ ist schneller als cnt++
| | Remarks/Rems |
→ | Besonders für Programmierer, welche nicht ausschließlich in XProfan programmieren, sind diese zwei zusätzlichen Remark-Varianten ein Willkommensgeschenk. Diese beiden Remvarianten sind unter Anderem aus C++ und PHP bekannt. Es kann // oder /* text */ genutzt werden.
Das Auskommentieren eines ganzen Blockes mittels /* text */ ist also mit XPSE möglich und auch die IDE XProfEd unterstützt dies. Somit können ganze Textpassagen einfach und schnell ausgeklammert werden.
| 'Beispiel:
....Zeile1
/*....Zeile2
....Zeile3
....Zeile4 */
....Zeile5
|
es kann auch innerhalb einer Zeile geRemarkt werden.
print "Hallo Welt",/*hier ein rem*/&gettickcount
| 'auskommentieren mittels //
print "Hallo Welt"//hier der Kommentar, welcher beim Zeilenende endet
|
| | Repeat/Until |
→ | XPSE ermöglichte fußgesteuerte Repeat-Until Schleifen. Bis XProfan8 waren solche Schleifen nur mit XPSE möglich. In XProfan9 hat Roland das Repeat- Until fest integriert. In den seither nachfolgenden Versionen des XPSE wird das Repeat-Until also nicht mehr durch XPSE umgesetzt werden, da dies nun nicht mehr nötig ist und Rolands Variante durch den Festeinbau zügiger ist.
| | Swap |
→ | Swap tauscht den Inhalt zweier Variablen gleichen Typs.
Gibt folgendes aus:
20
10
| | Zuweisungs/Vergleichsoperatoren |
→ | C++ / Delphi & PHP'er sind es z.B. gewohnt im Gegensatz zu Basicprogrammierern für das "Zuweisen von Variablen" und das "Vergleichen von Variablen" eine unterschiedliche Syntax zu verwenden. Dies ist schlichtweg übersichtlicher und hilft bei der genaueren Interpretierung durch den Menschen. In Basic - so auch in XProfan - ist das Gleichheitszeichen ein Zuweisungs- und Vergleichoperator. Beim Lesen von XProfan-Code durch einen nicht- XProfan-Programmierer können hier empfindliche Mißverständnisse entstehen.
Es kann natürlich auch weiterhin "Zugewiesen" und "Verglichen" werden wie gewohnt. XPSE schränkt nicht ein - sondern soll "Erweitern". XPSE bietet für XProfaner nun zumindest die augenscheinliche Möglichkeit zwischen Zuweisungs- und Vergleichsoperator zu unterscheiden.
| Operation |
→ | XProfan |
→ | C++/PHP |
→ | Delphi |
→ | XProfan mit XPSE | | Wertzuweisung |
→ | = |
→ | = |
→ | := |
→ | alle diese Varianten | | Vergleich |
→ | = |
→ | == |
→ | = |
→ | alle diese Varianten |
| 'Beispiel:
if (a%==b%)
a%:=b%*4
endif
|
| | Funktionen |
→ | Die "alten" Createfunktionen bleiben erhalten! Die "alten" Createfunktionen bleiben dank automatischer Umwandlung in die "neue" Createsyntax erhalten und werden sogar erweitert.
Folgende Funktionsnamen können einfach weiterverwendet werden:· CREATETEXT
· CREATEDIALOG
· CREATECHOICEBOX
· CREATELISTBOX
· CREATESORTEDLISTBOX
· CREATETABCONTROL
· CREATEWINDOW
· CREATEGROUPBOX
· CREATEEDIT
· CREATEMULTIEDIT
· CREATEBUTTON
· CREATEDEFBUTTON
· CREATEDATEEDIT
· CREATETIMEEDIT
· CREATESPINEDIT
· CREATEPICBUTTON
· CREATEICONBUTTON
· CREATEHTMLBOX
· CREATETOOLWINDOW
· CREATELEFTBUTTON
· CREATECENTERTEXT
· CREATERIGHTTEXT
· CREATESUNKENTEXT
· CREATESUNKENCENTERTEXT
· CREATESUNKENRIGHTTEXT
· CREATESTATIC
· CREATEBLACKFRAME
· CREATEBLACKRECT
· CREATEHTMLBOX
Das Control HTMLBOX ist ein Control aus der ATL.DLL. Es wird hierbei der IE als Anzeigemodul genutzt. CreateHtmlBox kann genau wie z.B. Createtext ohne Umwege erstellt werden. Der als 2. Parameter übergebene Text kann entweder eine "URL" sein, oder ein direkter html beginnend mit "mshtml:". Diese Funktion ist z.B. interessant für einfache About-Boxen oder Hilfedateien. Ich konnte in meinen Versuchen mindestens 32K Html direkt per MSHTML: übergeben - und der Inhalt wurde immer korrekt angezeigt. Wenn eine lokale HTML-Datei angezeigt werden soll, dann ist das "file:///c:/ordner/htmldatei.html"-Format zu nutzen. Das Control ist auch hervorragend zu nutzen um z.B. Bilddateien anzuzeigen - da der IE nahezu jedes Format darstellen kann.
|
|
Für die Parameter ist auch einfach die "alte" Form zu nutzen, denn XPSE setzt diese vollständig um:
| | OOP |
→ | Auch für den OOP-Begeisterten XProfaner bietet XPSE hier und da ein paar experimentelle Features. Zum einen den Operator :: und zum Anderen das Schlüsselwort this->. Aber auch die Möglichkeit des Weglassens des Suffixes für die Bereichsvariable welche die Klasse aufnimmt ist sehr interessant!
Um es kurz zu fassen hier zum Einen das "normale", und zum Anderen eine Möglichkeit die mit XPSE genutzt werden kann.
Innherhalb von Klassen kann also auf Methoden der gleichen Klasse mit this-> zugegriffen werden (erspart das wiederholte Tippen der Klassenbezeichnung) und ausserhalb von Klassen kann auf Methoden mittels :: zugegriffen werden. Bei der Verwendung von new und :: und dispose kann auf die Angabe des Rautezeichens für die Bereichsvariable verzichtet werden. (ausgenommen Arrays von Bereichsvariablen) Im Allgemeinen Umgang mit XProfanOOP hat sich dies als sehr praktisch erwiesen!
| | Include |
→ | Inkludiert Quelltextdateien, Headerdateien oder Units. Je nach Endung der Datei wird sie entsprechend eingebunden.
Wird "#include" statt "include" geschrieben passt XPSE darauf auf das die Include auch nur ein Mal eingebunden wird - egal wie oft der Aufruf vorkommt. Ähnlich wie PHP's "include_once".
Um eine Include-Datei einzubinden wird in XProfan der Compilerschalter "$I" benutzt. XPSE'ler können aber auch Include oder #include schreiben - das Verhalten bleibt gleich. Besonders bei Includes erhöht XPSE den Komfort. Es ist nun z.B. möglich, einfach die Dateiendung wegzulassen - es wird automatisch nach inc und prf gesucht. Ebenso, wenn XPSE die Include nicht im eigenen Verzeichnis findet, wird diese Reihenfolge genutzt, um den Ort der Include festzustellen:
· /.inc
· /include
· /includes
· /include/.inc
· /includes/.inc
· /.prf
· /include/.prf
· /includes/.prf
Man braucht also nur noch '#include myinc' schreiben, selbst wenn sich die Inc oder Prf nicht im selben Verzeichnis, sondern in einem der genannten Unterordner befindet.
Es werden auch die im ProfanEditor angegebenen Includepfade berücksichtig. Siehe auch Compilerschalter:{$Includepath ...}
|
→ | Inkludiert die Quelltextdatei "meine.inc". |
|
→ | Inkludiert das HeaderFile "windows.ph". |
|
→ | Inkludiert die Unit "lists.pcu" mit dem Namensraumsymbol "lst.". |
| | Const |
→ | Const ist ein sehr mächtiges Werkzeug des XPSE. Mit Const werden Konstanten oder ganze Syntaxblöcke definiert. Die Verwendung dieser Konstanten statt der Def -Konstanten empfehle ich da diese nicht zur Laufzeit, sondern beim Kompilieren umgesetzt werden - was einen Geschwindigkeitsvorteil bedeutet, und da diese Konstanten kein lästiges PreFix tragen müssen.
|
[Textblock - xpse.syntax]
|
| |
| XPSECOMPILETIMESTAMPSTRING |
→ | Stringkonstante, beinhaltet Datum und Uhrzeit der Programmkompilierung im Format "yyyymmddHHMMSS". | | XPSESOURCECODEFILENAMESTRING |
→ | Stringkonstante, beinhaltet Dateiname des kompilierten Programmes einschliesslich Pfad. | | XPSEVERSIONSTRING |
→ | Stringkonstante, beinhaltet den Versionsstring von XPSE - z.B. "0.1.7g". | | XPSENUMSOURCECODELINESLONG |
→ | Longkonstante, beinhaltet die Anzahl der relevanten geladenen Quelltextzeilen.
|
Zum einfach selber testen:
[Textblock - xpse.konstanten]
|
| | | Errors und Warnungen | [top] |
|
| |
Vorwort
Hier sind die Error und Warnings des XPSE genauer beschrieben. Der Unterschied zwischen Warnings und Errors ist einfach, denn im Gegensatz zu Errors kann trotz Warnings weitergearbeitet werden. Was ein "Error" und ein "Warning" ist kann zwischen den XPSE-Versionen differieren. Deshalb werde ich hier in der Hilfe auch nicht zwischen "Error" und "Warning" unterscheiden.
HINWEIS: Ab XPSE V0.1.7f werden die Fehlermeldungen und Warnings in deutscher Sprache ausgegeben. Dementsprechend erspare ich es mir hier jede Meldung aufzuzeigen da diese sich oft selbst erklären.
Folgende Fehlermeldungen waren vor XPSE V0.1.7f aktuell:
| blockstatement behind "case" not allowed |
→ | Hinter einer Case-Anweisung wird eine Kontrollstruktur verwendet welche einen Block eröffnet, z.B. proc oder if . Mit XPSE erlaubt, ohne XPSE jedoch nicht möglich, ist jedoch:
| | cant convert inline assembler without XPIA |
→ | Im Quelltext wurden Assemblerpassagen deklariert aber die XPIA.EXE konnte nicht gefunden werden.
| | cant ''swap'' different variable types |
→ | Es wird versucht den Inhalt von zwei Variablen unterschiedlichen Typs mit swap auszutauschen.
| | "do begin" expected |
→ | Unvollständige Syntax bei Anwendung einer For -Schleife.
| | duplicate identifier ... |
→ | Ein Identifier wird doppelt verwendet. Entweder wird eine Variable doppelt deklariert - oder ein Prozedurname/Funktionsname wird doppelt verwendet - oder ein Prozedurname/Funktionsname wird bereits von einer Variable verwendet.
| | duplicate variableidentifier ... |
→ | Ein Variableidentifier wird doppelt verwendet. Die Meldung ähnelt der "duplicate identifier" Meldung mit dem Unterschied das es sich eindeutig um eine Variable handelt.
| | ... include not found |
→ | Eine Includedatei konnte trotz Suche nicht aufgefunden werden.
| | ... is not a procedure but function |
→ | Eine Funktion wird als Prozedur verwendet. Es ist unklar was mit dem Rückgabewert geschieht. Rückgabewerte sollten Grundsätzlich ausgewertet werden. Es wird nicht generell angemeckert wenn eine Funktion als Prozedur verwendet wird, aber meistens wenn es sich um eine Funktion handelt welche XPSE durch Umsetzung der Syntax selbst erzeugt.
| | keyword-collision |
→ | Es wird versucht ein Identifier zu nutzen welcher bereits im Wortschatz von XProfan enthalten ist. Diese Meldung wird nur unter sehr seltenen Umständen angezeigt - da die Meldung "Duplicate-Identifier" oft schneller ist. Es gibt jedoch Situationen wo die Meldung "Duplicate-Identifier" intern unterdrückt wird - dann jedoch erscheint bei einer Keyword-Kollision diese Meldung.
| | missing ... |
→ | XPSE vermisst eine Angabe oder ein Zeichen. Welche Angabe bzw. welches Zeichen XPSE vermisst stellt er anstatt "..." der drei Punkte dar. Oft wird eine Klammerunschlüssigkeit mit: "missing (" oder "missing )" angezeigt.
| | missing ''end'' argument |
→ | XPSE vermisst das "end" für einen mit "begin" eröffneten Bereich bei For -Schleifen.
| | missing "endif" |
→ | Ein "If" ohne dazugehöriges "Endif" wurde gefunden.
| | missing "endproc" |
→ | Ein "Proc" ohne dazugehöriges "Endproc" wurde gefunden.
| | missing "if" |
→ | Ein "Endif" ohne dazugehöriges "If" wurde gefunden.
| | missing "proc" |
→ | Ein "Endproc" ohne dazugehöriges "Proc" wurde gefunden.
| | namespacesign but no namespace ... |
→ | In einer Include wurde ein Namensraumsymbol gefunden, inkludiert wird jedoch ohne Angabe eines Namensraumsymboles. XPSE sieht es als Fehler an wenn eine Include (nicht Unit!) inkludiert wird in der Prozeduren/Funktionen/Variablen mit Namensraum deklariert werden - jedoch beim Inkludieren kein Namensraum festgelegt wurde. Wenn in einer Include also z.B. folgende Prozedur:
|
|
|
