| |
| |
|
Jörg
Sellmeyer | Was bedeutet:
<~1329> undeklariert
<~1335> undeklariert.
Die prf-File hat bei weitem nicht so viele Zeilen und auch die enh-File hat ca. 10 Zeilen weniger.
Der Profaninspector meckert gar nichts an, und wenn ich die enh-File nochmal durch XPSE jage, gibts keine Warnung mehr.
Außerdem - Mal so aus Neugierde: Du schreibst alle Keywörter GROSS in die enh-File. 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?
Saluto
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-File hat bei weitem nicht so viele Zeilen und auch die enh-File hat ca. 10 Zeilen weniger.
Der Profaninspector meckert gar nichts an, und wenn ich die enh-File 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-File. 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 per 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 DLL. Alle APIs werden ja in Calls umgewandelt. Um jedoch die Funktionsadressen korrekt beziehen zu können müssten bestimmte DLL 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 DLL 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 DLL vorher laden - die FnAdressen beziehen, und bei jedem Programmende die geladenen DLL wieder freigeben. Das Ganze wird bei Verwendung von Unità 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 DLL (wenn denn solche benutzt werden) bestennfalls a) geladen und b) wieder freigegeben werden. |
|
| |
| |
| |
|
|
Jörg
Sellmeyer | Ok, danke per 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 Foro 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 Foro 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.
Saluto
Jörg |
|
| |
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 26.10.2007 ▲ |
|
| |
|
|
| Jau - also ein dickes Plus per 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 ▲ |
|
| |
|
(4.896)
Deutsch
English
Français
Español
Italia