| |
|
|
- Seite 1 - |
|
| $errline wirft im PRC-Modus nicht die richtige Zeilennummer aus. Da manche Fehler nur im PRC-Modus passieren...
Schade!
XPSEs Debugmodus ist der Beste - der hilft mir fast immer! Leider verfälscht das Prinzip welches XPSE nutzt manches Ergebnis - so daß manchmal der Bug kaschiert wird - und es dann doch leider nichts nutzt.
Die PrfDebug.Exe - habs getestet - kann nix mit anfangen - wenn man wirklich einen Fehler sucht ist das Programm nutzlos.
Es passiert mir einfach immer wieder das sich irgendwo ein Bug einschleicht an den man einfach nicht herankommt. Ich glaube Roland mag dies nicht hören.
Mein Appell an Roland: Alle Debugmöglichkeiten die es zum XProfan dazu gibt sind schön - so schön das ich selbst diese nie nutze und lieber Messageboxen im Source verteile. Es fehlt einfach etwas ganz Entscheidenes! Wenn ein Programm abstürzt - und ich rede nicht im interpreter bei dem es meistens eh alles klappt - dann kommt man einfach oft nicht an die betreffende Zeile heran! Es ist als ob man eine Seife versucht mit nassen Händen zu greifen und diese immer wieder aus der Hand flutscht!
Ich habe so viele Jahre Erfahrung mit Profan² und XProfan - ich rede hier von der Praxis und nicht davon das es theoretisch doch mit Messageboxen möglich sein sollte einen Fehler zu finden - denn dem ist nicht so! Oft verfälscht die Messagebox alleine das Ergebnis - oder ein print - oder ein Addstring - oder ein REM!
Könntest Du nicht - und ich rutsche hier schon fast auf Knieen - ein Runtime herstellen was gaaaannnnz einfach jede Zeile bevor sie diese Ausführt aufschreibt? XPSE machts doch schon echt toll vor - nur leider tüttelt er im Source herum was das Ergebnie - wie bereits erwähnt - manchmal verfälscht sodaß es auch hiermit nicht möglich ist den Bug zu finden. (Das Thema das selbe ein REM oft einen Bug beseitigt)
Bitte bitte bitte fleh heul *nicht*weiter*komm* ich hatte das schon X mal und man wird völlig hysterisch dabei hab ich echt unheimlich viel Geduld beim Programmieren. |
|
|
| |
|
|
|
| |
|
- Seite 1 - |
|
RGH | Hast Du es schon mal mit der MAP-Datei versucht? Aus dieser solltest Du ermitteln können, in welcher Quelltextdatei der Fehler auftritt. Da das Compilat keine Infos darüber enthält, welcher Programmteil aus welcher Quellcodedatei kommt, gibt es für den Compiler die Möglichkeit, eine Mapdatei zu erstellen, die den Zeilennummern des Compilates die ursprünglichen Zeilennummern zuordnet.
Gruß Roland |
|
|
| Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 11.10.2006 ▲ |
|
|
|
|
| Es gibt nur eine Datei! |
|
|
| |
|
|
|
| Mein Fehler - es gibt natürlich nicht nur eine Datei - es sind ja Units im Spiel.
Habe nun das Mapfile genutzt - die betreffende Zeile (auch die umliegenden) haben nichts mit dem Absturz zu tun.
Ich vielleicht etwas zu viel verlangt - aber könnte nicht mal vielleicht jemand anderes schauen warum das o.G. Programm abstürzt? |
|
|
| |
|
|
|
| Ich könnte heulen auch der ProfanInspektor von Sebastian stürzt bei dem Code ab. |
|
|
| |
|
|
|
Jörg Sellmeyer | Ich werds heute Abend mal testen. |
|
|
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 12.10.2006 ▲ |
|
|
|
|
| So, also der Fehler tritt erst seit dem neusten RC (8) auf.
Ich finde den Fehler nicht - wann auch immer ich die Absturzposition mit MessageBoxen einkreise kann ich den Fehler verzögern. Wenn ich hinter jede Zeile eine Messagebox setze gibt es keinen Absturz. Ab hier sind mir die Hände gebunden.
Könntest Du nicht vielleicht mal schauen Roland? Es kann ja sein das ich irgendwo einen Parameter vergessen habe - aber warum meckert dann weder XProfan noch der Kompiler? Und warum bekomme ich den Fehler einfach nicht zu fassen? |
|
|
| |
|
|
|
Jörg Sellmeyer | Hallo iF, Ich hab mir den Code mal in Notepad angesehen. Die Zeilenumbrüche scheinen etwas seltsam zu sein. Vielleicht liegts ja daran (s. Screenshot)
Gruß Jörg
Ich habs gerade getestet aber daran liegts nicht
Wieso hast Du denn $A als Zeilenumbruch statt $D?
Gruß Jörg |
|
|
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 13.10.2006 ▲ |
|
|
|
|
| In Windows sind Zeilenumbrüche CR LF, also #13 #10 ,CarriageReturn jedoch ist nicht wirklich wichtig, #10 war schon immer den Entscheidungsträger über die neue Zeile. Ich habs wohl als Unixfile gespeichert.
Daran liegt es aber nicht. |
|
|
| |
|
|
|
| Alle Probleme sind wie gegepustet - Roland hats geschafft.
Man bin ich erleichtert! |
|
|
| |
|
|
| |
|
- Seite 2 - |
|
|
Michael Wodrich | Also ich wäre erst erleichtert wenn auch die 8 dulcoifs raus sind. Wenn man Tabletten einwerfen muß dann ist noch NICHT alles in Ordnung.
noch etwas zu Okrea KompilierenMarkierenSeparieren Schöne Grüße Michael Wodrich |
|
|
| Programmieren, das spannendste Detektivspiel der Welt. | 15.10.2006 ▲ |
|
|
|
|
| Zu AppdataDir - das ist furchtbar schlüssig! Schau Dir die komplette Prozedur an! KompilierenMarkierenSeparieren Wenn SHGetSpecialFolderPathA fehlschlägt wird c:\appdata erstellt, und appdatadir auf c:\appdata\Okrea\.
Wenn c:\appdata\Okrea\ nicht existiert kann c:\appdata\Okrea\ angelegt werden, da ja c:\appdata\ exisitert.
Ich denke in weniger Arbeitsschritten ist das Selbe nicht machbar.
Zum PokeDoubleWord: Den habe ich aus der XProfanhilfe entnommen. |
|
|
| |
|
|
|
Michael Wodrich | [quote:dbda2a6022]Zum PokeDoubleWord: Den habe ich aus der XProfanhilfe entnommen.[/quote:dbda2a6022] Wenn der dort auch so falsch steht, muß er korrigiert werden.
Wo denn genau??? - Globalsuche findet es nicht. Oder meinst Du die ODoku?
Schöne Grüße Michael Wodrich
PS: bei der korrekten Form muß das Ausrufezeichen (2 Stellen) gegen das Kaufmanns-Und getauscht werden. (Nicht Float, sondern Long)
PPS: und bei näherer Betrachtung würde ich einfach MM(Adr&,Addr(V&),4) einsetzen und zwar ohne Unterprogrammaufruf. |
|
|
| Programmieren, das spannendste Detektivspiel der Welt. | 15.10.2006 ▲ |
|
|
|