| |
|
|
Jörg Sellmeyer | Was bedeutet: <~1329> undeklariert <~1335> undeklariert. Die prf-Datei hat bei weitem nicht so viele Zeilen und auch die enh-Datei hat ca. 10 Zeilen weniger. Der Profaninspector meckert gar nichts an, und wenn ich die enh-Datei nochmal durch XPSE jage, gibts keine Warnung mehr.
Außerdem - Mal so aus Neugierde: Du schreibst alle Keywörter GROSS in die enh-Datei. Nur proc und endproc sind kleingeschrieben. Hat das einen bestimmten Grund? Und: Warum fügst Du die Prozedur __xpse__endofprogram__ mit dem Befehl end (lustigerweise auch kleingeschrieben) ein?
Gruß Jörg |
|
|
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 25.10.2007 ▲ |
|
|
|
|
|
Was bedeutet: <~1329> undeklariert <~1335> undeklariert. Die prf-Datei hat bei weitem nicht so viele Zeilen und auch die enh-Datei hat ca. 10 Zeilen weniger. Der Profaninspector meckert gar nichts an, und wenn ich die enh-Datei nochmal durch XPSE jage, gibts keine Warnung mehr.
~1329, hm sieht mir nach einer Konstante aus! Er meint also die Konstante bzw. das Schlüsselwort 1329 sei nicht existent. Kann es sein das Du die Konstanten mit ~ anführst? (was in xpse nicht nötig ist - aber auch nicht grad zu Fehlern führen sollte)
Außerdem - Mal so aus Neugierde: Du schreibst alle Keywörter GROSS in die enh-Datei. Nur proc und endproc sind kleingeschrieben. Hat das einen bestimmten Grund?
Ja das ist sehrwohl damit begründbar da XPSE ja ein MultiPass-PräKompiler ist. Ich verhindere durch die andere Schreibweise das der vorletze Pass erneut diese kleingeschriebenen Identifier als solche erkennt. Wenn Du so willst kannst Du sagen ich schmuggle diese IDs an den letzen beiden Pässen vorbei. Das wiederum tue ich da ich dadurch ein Fünkchen mehr Performance erhaschen konnte.
Warum fügst Du die Prozedur __xpse__endofprogram__ mit dem Befehl end (lustigerweise auch kleingeschrieben) ein?
END ist für XPSE lediglich eine Konstante mit dem Wert __xpse__endofprogram__. Alle ENDs werden also nach __xpse__endofprogram__ umgeschrieben - egal wo das END im Source steht.
Dadurch hat XPSE die Chance selbst initiierte Arbeiten auch beim Programmende wieder zu beenden. Hierzu gehört unter Anderem das Freigeben von DLLs. Alle APIs werden ja in Calls umgewandelt. Um jedoch die Funktionsadressen korrekt beziehen zu können müssten bestimmte DLLs geladen sein. Z.B. WinSock oder GDIPlus. Da XPSE ja am Start schon die Fn-Adressen bezieht, also noch bevor man die Chance hat eine DLL zu laden, muss XPSE das Laden übernehmen. Am Programmende - so verlangt es der gute Stil - müssen diese DLLs aber auch wieder freigegeben werden. Wenn XPSE etwas veranstaltet dann muss er auch dafür Sorge tragen dass das Veranstaltete korrekt wieder beendet wird. Das wiederum kann XPSE in seiner eigens-definierten __xpse__endofprogram__ erledigen. Diese Funktion wird mit den unterschiedlichsten Aufgaben bestückt - je nachdem was der Programmierer alles in seinem Programm anstellt. Da XPSE auch die Konstanten und einfachen Aufrufe von folgenden normalerweise-nicht-vom-system-geladenen-DLLS anbietet: WSOCK32, GDIPLUS, RASAPI32, DSOUND, WINMM, ATL wird XPSE also - bei Verwendung von Funktionen aus diesen Bibliotheken, die DLLs vorher laden - die FnAdressen beziehen, und bei jedem Programmende die geladenen DLLs wieder freigeben. Das Ganze wird bei Verwendung von Units wiederum noch deutlich komplizierter - hier muss von XPSE auch beachtet werden was er in die .DEF der Unit schrieb und das wiederum gleicht XPSE mit den Unitaufrufenden Quelltext ab - um zu entscheiden - wann genau die DLLs (wenn denn solche benutzt werden) bestennfalls a) geladen und b) wieder freigegeben werden. |
|
|
| |
|
|
|
Jörg Sellmeyer | Ok, danke für die Info.
Das ~1329 ist definitiv eine Zeilennr. Die Zahl verändert sich, wenn ich Zeilen lösche/hinzufüge. Es sieht auch so aus, als ob das Forum was verschluckt hat. Ich ersetze hier mal die spitzen Klammern durch Unterstriche:
_~1329_ _Proc_ undeklariert _~1335_ _Funktionen_ undeklariert.
Und noch ein Screenshot.
Wenn Du Dir das erste Posting mal im Editiermodus ansiehst, wirst Du festellen, daß dort mehr steht, als man hinterher sieht. Wahrscheinlich sind das irgendwelche html-Schlüsselwörter. |
|
|
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 25.10.2007 ▲ |
|
|
|
|
| Hab oben Deinem Beitrag mal ein [X] HTML-Deaktivieren spendiert, wenn Du < oder > benutzt dann mit umschließendem Freizeichen - damits net knallt.
Ich schau mir mal Deinen Screenshot an... Naja, Du kannst übrigens auch W drücken, dann bekommst den WarnText um die Ohren im Editor.
Zu den Fehlern kann ich ohne Source wenig sagen. |
|
|
| |
|
|
|
Jörg Sellmeyer | Naja, durch W wird mir die Meldung auch nicht besser erklärt
Wenns Dir recht ist, schicke ich Dir den Code mal zu. |
|
|
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 25.10.2007 ▲ |
|
|
|
|
| Durch W kann man die Meldungen aber einfacher z.B. hier ins Forum kopieren. Den Code sehe ich mir gerne an. Bitte senden an david punkt strutz at googlemail punkt com. |
|
|
| |
|
|
|
Jörg Sellmeyer | Ha! Ich habs rausgefunden: KompilierenMarkierenSeparieren XPSE meckert das hier (zu Recht, wie ich finde) an. Profan läßt das so durchgehen. Ich weiß nicht, obs ein Bug oder ein Feature ist. Der Witz ist der, da? ich im Programm ausgerechnet die Schlüsselwörter Proc, While, If und das Wort Funktionen so in Anführungszeichen gestzt hatte. Dadurch hat XPSE dann _PROC_ als undeklariert angesehen.
Gruß Jörg |
|
|
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 26.10.2007 ▲ |
|
|
|
|
| Jau - also ein dickes Plus für XPSE weiler meckerte weil was nicht stimmte? |
|
|
| |
|
|
|
Jörg Sellmeyer | Genau! Vielleicht kannst Du dafür ja noch eione Überprüfung einbauen: Abführungszeichen in Strings suchen, warnen und gleich in q umwandeln. |
|
|
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 26.10.2007 ▲ |
|
|
|
|
Michael Wodrich | Da hätten ja auch einfach nur Kommata fehlen können (war meine erste Vermutung).
Lieber keine Umwandlungsautomatik einbauen: Fehler melden -- gut.
Fehler mit kompletter Fehlerzeile melden -- besser.
Schöne Grüße Michael Wodrich |
|
|
| Programmieren, das spannendste Detektivspiel der Welt. | 26.10.2007 ▲ |
|
|
|
|
Jörg Sellmeyer | Michael Wodrich
Fehler mit kompletter Fehlerzeile melden -- besser.
Das wünsch ich mir auch. |
|
|
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 26.10.2007 ▲ |
|
|
|