| |
| |
|
Dieter
Zornow | Ich habe mich mal an einem Listview versucht, das Directories einliest, dabei werden die zum Eintrag
passenden Icons verwendet, eben wie bei Totalcommander oder Freecommander.
Das funktioniert auch sehr gut, aber auf meinem Hauptrechner und auf meinem Notebook stürzt das Programm
bei nur einem Verzeichnis "Adressen" ab. Unter Profan spätestens beim zweiten öffnen, mit Profan2CPP kompiliert
kann ich es bis zu 5x öffnen bevor es abstürtzt. Ich suche nun schön seit Tagen nach einem Fehler und kann nichts
finden, da es ja auf jedem Rechner nur diese eine Verzeichnis ist, alle anderen funktionieren einwandfrei.
Das Verzeichnis hat keinerlei Besonderheiten und ist auch nicht groß. Weder XPSE noch der in profan2cpp eingebaute
Inspector haben einen Fehler im Code gefunden. Könnte mal jemand testen, ob es auf seinem Rechner ebenfalls so
ein Phänomen gibt.
Lauffähiger Quelltext und Exe mit Profan2Cpp kompiliert liegen bei. Funktioniert wegen Subclassing Doppelklick und
Rechtsklick nur unter XProfan 11. Die Hauptbestandteile dürften aber auch in anderen Versionen laufen. |
 |
| |
| Er ist ein Mann wie ein Baum. Sie nennen ihn Bonsai., Win 7 32 bit und Win 7 64 bit, mit XProfan X2 | 15.07.2009 ▲ |
|
| |
|
|
RGH | Hallo,
also bei mir stürzt er schon beim Versuch ab, in ein Verzeichnis "Adressen" zu wechseln, gleiches konnte ich auch für die Verzeichnisnamen "RGH-Entw" und "SVP" feststellen. Ich würde mal in Getfolder.inc suchen und vielleicht mal ein paar Debug-Messageboxen einbauen, um herauszufinden wo genau die Schutzverletzung erfolgt. Und wenn dort dann Bereiche und API-Aufrufe involviert sind, sollte die Lösung nicht mehr weit weg liegen. Da das Problem reproduzierbar ist, sollte es nur eine Frage der Zeit sein ...
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 | 15.07.2009 ▲ |
|
| |
|
|
Jörg
Sellmeyer | Hallo Dieter,
Ich vermute mal, der Fehler liegt in der Prozedur getFolder - und zwar in der If-Konstruktion vor der While-Schleife. Bau da mal ein WindowTitle Dir$ ein und Du siehst bis wohin das Programm kommt.
Es muß weiter mit der Prozedur ApiFindFile zu tun haben.
Folgende Fehlermeldung habe ich erhalten:
Das könnte auch bedeuten, daß evtl. eine While-Schleife nicht korrekt verlassen wird.
Außerdem solltest Du die If-Abfrage auf CaseOf umstellen. Das ist, glaube ich, etwas schneller.
Und unbedingt den "substr$(put$,1,"|")" in einer Variable abspeichern, bevor Du die Vergleiche anstellst. So mußt Du 4-5mal mit SubStr$() den Wert ermitteln, was natürlich unnötig Zeit kostet.
Ach so: Es könnte noch damit zu tun haben, das der Ordner an erster Stelle steht. Dann ist bei mir das Programm am häufigsten abgestürzt.
Gruß
Jörg |
|
| |
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ...  | 15.07.2009 ▲ |
|
| |
|
|
Dieter
Zornow | Danke für die Hilfestellung, bis jetzt bin ich noch nicht weitergekommen. attrib$ ist ja eindeutig declariert. Das hätte auch schon XPSE oder der Inspector bemängelt. Auch die Position des Verzeichnisses ist nicht von Belang, bei mir ist es an 3. Stelle. Auf den Namen Adressen wird aber scheinbar nur im Hauptverzeichnis reagiert. Das verzeichnis in ein anders kopiert geht einwandfrei.
@Jörg: ich denke die Fehlermeldung ist eine Falschmeldung von Profan. Vielleicht wird bei dir festgestellt, dass etwas nicht stimmt aber es ist nicht klar was es ist, dann wird irgendwas gemeldet. Habe ich selbst schon oft erlebt
Zur Zeit versuche ich mit dem Errorsystem von Profan etwas zu finden. Den externen Debugger kann man in meiner Version scheinbar vergessen. Er ist im Profanverzeichnis und findet nicht die dazugehörende Include, weil er scheinbar nicht ins Verzeichnis des Quellcodes wechselt oder dort danach sucht. Damit scheidet der mal aus. Es scheint so, dass etwas verbotener Weise in eine Adresse geschrieben wird. Das allein hilft aber auch nicht weiter. |
|
| |
| Er ist ein Mann wie ein Baum. Sie nennen ihn Bonsai., Win 7 32 bit und Win 7 64 bit, mit XProfan X2 | 15.07.2009 ▲ |
|
| |
|
|
 | | Nur überflogen aber ich glaube ein Fehler ist, dass Du nach filefindhndl&=FindFirstFile(file#,info#) nicht prüfst, ob fileFindHndl& gültig befüllt ist. |
|
| |
| |
| |
|
|
Dieter
Zornow | Ich habe es aufgegeben, ich habe den Fehler zwar eingegrenzt und einiges verändert, es hilft aber alles nichts. Die Findfile-Routine kann ich, wie ich denke, ausschließen, da das ganze ohne die Apifindfile proc nur mit liste und addstring den gleichen Fehler hervorruft. Ist ja auch zu ungewöhnlich wenn ein Verzeichnis namensabhägig ist ob es funktioniert oder nicht. Bei allen Namen werden die gleichen Routinen aufgerufen, warum funktionieren einige Namen nicht. Ich werde das Ding wohl verschrotten müssen.
Nachdem ich mit dem externen Debugger die *.enh Datei probiert habe, denn nur die geht, da alles in einer Datei ist, kam die folgende Meldung
-----------------------------------------------------------------------------------
Es fand ein Debug-Ausnahmeereignis mit dem Code EXCEPTION_ACCESS_VIOLATION statt.
Das Debug-Ausnahmeereignis hat das Signal EXCEPTION_CONTINUABLE.
Das Debug-Ausnahmeereignis fand an der Adresse $401BA3 statt.
Es wird versucht in die Speicheradresse $1 unerlaubt zu schreiben.
-----------------------------------------------------------------------------------
Hier meine Eingrenzung mit den Änderungen
KompilierenMarkierenSeparieren
if filefindhndl& > 0
whilenot GetLastError()= 18
Put$ = ApiFindFile("",filefindhndl&)
comp$ = substr$(put$,1,"|")
Messagebox(put$,comp$,0) danach
case comp$ = "":break
if (comp$ <> "[.]") and (comp$ <> "[..]")
temp$ = doubletrim(comp$,"[","]")
if isdir(temp$)
size$ = "|<DIR>|"
datum$ = substr$(put$,5,"|")+" "
uhr$ = substr$(put$,6,"|")+"|"
attr$ = Right$(substr$(put$,13,"|"),4)
put$ = comp$+size$+datum$+uhr$+attr$
addstring(folder&,put$)
else
size$ = "|"+substr$(put$,3,"|")+"|"
datum$ = substr$(put$,5,"|")+" "
uhr$ = substr$(put$,6,"|")+"|"
attr$ = substr$(put$,13,"|")
put$ = comp$+size$+datum$+uhr$+attr$
addstring(file&,put$)
endif
Messagebox(put$,"",Dir$) davor
endif
endwhile
endif
FindClose(filefindhndl&)
|
|
| |
| Er ist ein Mann wie ein Baum. Sie nennen ihn Bonsai., Win 7 32 bit und Win 7 64 bit, mit XProfan X2 | 16.07.2009 ▲ |
|
| |
|
|
RGH | Dieter Zornow, Beitrag=53269, Zeitpunkt=16.07.2009
Nachdem ich mit dem externen Debugger die *.enh Datei probiert habe, denn nur die geht, da alles in einer Datei ist, kam die folgende Meldung
Mit dem Debuger kannst Du ja zeilenweise durch das Programm gehen. Bei welcher Zeile kommt denn die Meldung?
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 | 16.07.2009 ▲ |
|
| |
|
|
Dieter
Zornow | ich habe nicht zeilenweise probiert, ich habe mir eine Protokolldatei schreiben lassen. Ich habe nun noch eine simple
Version getestet ohne irgendwas zu filtern die mit Liste und addfiles arbeitet (Im Anhang). Es wird auch nur die erste Spalte befüllt.
Der gleiche Effekt, obwohl ich im wesentlichen Bereich auf alle Apiaufrufe verzichte und Verzeichnisse und Dateien mit Abfrage von "[" unterscheide. Allein der Name reicht aus um zu crashen, mit allen anderen Namen geht auch diese simple Version. Klar ist, dass der Absturz in der Schleife passiert, in der Verzeichnisse und Dateien separiert werden. Soweit bin ich, weiß aber nicht wie abstellen. |
|
| |
| Er ist ein Mann wie ein Baum. Sie nennen ihn Bonsai., Win 7 32 bit und Win 7 64 bit, mit XProfan X2 | 16.07.2009 ▲ |
|
| |
|
|
| Also das Programm in der AddFiles.Zip bekomm ich nicht zum abstürzen. (bin aber grad auch "nur" an einem XPHomeSP3-Rechner)
Nachtrag: Ok, stürzt auch - nur weniger zuverlässig. 
(mal heute Abend zuhause nochmals anschauen) |
|
| |
| |
| |
|
|
Jörg
Sellmeyer | Ich habe das Startverzeichnis mal auf "C okumente und EinstellungenJörgDesktopgriddir" gesetzt.
Darin liegt nicht die prf-Datei! Wenn ich das Programm starte (ohne irgendwelche Änderungen) und danach gleich wieder beende, kommt ein Absturz.
Wenn ich das Programm aber in "Cokumente und EinstellungenJörgDesktopgriddir1" starte (hier liegt die Datei), passiert nichts Auffälliges.
Kann es am Callback liegen oder ist es die AddBackSlash-Prozedur? 
Bei mir fällt zwar auch auf, daß Verzeichnisse mit "A" häufiger crashen, aber ich hab noch nicht getestet, wie es bei anderen Verzeichnisnamen ist, die am Anfang stehen. Also ein Verz. "Beton" ohne ein Verzeichnis "Alu"  |
|
| |
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 16.07.2009 ▲ |
|
| |
|
|
Dieter
Zornow | Wird immer seltsamer das Ganze.
@IF: Also bei mir stürzt es zuverlässig ab, wenn ich versuche Adressen zu öffnen.
@Jörg: Ein callback ist ja nicht drin. Ich öffnen immer in C:\ und es passiert nichts. Es wird ja auch in das Verzeichnis gewechselt das aufgerufen wird. Hast du auch gewartet bis das Einlesen komplett fertig war, denn dann könnte
es abstürzen. Bei mir hängt es auch nicht am ersten Buchstaben. Abiword kann ich viele Male öffnen ohne, dass etwas passiert.
Es scheint wenn im Hauptverzeichnis dieser Name geöffnet wird passiert es, das gleiche Verzeichnis in einem anderen als Unterverzeichnis funktioniert. Wenn ich das Verzeichnis in BAdressen umbenenne gehts auch einwandfrei.
Ich probiere nun schon 4 Tage und habe schon fast alles abgeändert, aber es ändert sich nichts am Verhalten. |
|
| |
| Er ist ein Mann wie ein Baum. Sie nennen ihn Bonsai., Win 7 32 bit und Win 7 64 bit, mit XProfan X2 | 16.07.2009 ▲ |
|
| |
|
|
| Als ich eben Deinen Code für mich ein bisl sortiert habe ist mir aufgefallen, dass Du Createest innerhalb der SubClassProc u.v.m..
Die SubClassProc würde ich immer nur als Indikator für die Events nutzen, die Abarbeitung jedoch sollte wohl besser nicht mit ins waitInput. Einfach aus der SubClassProc eine userMessage senden um ausserhalb des WaitInput abzuarbeiten. Dabei geht noch nicht einmal etwas verloren.
So gesehen, obiger Code kann garnicht funktionieren, weil er sich nicht in den gesamtheitlichen Ablaufplan einpasst.
Die Hilfe sagt "WICHTIG: In der SubClassProc sollte so wenig wie möglich geschehen. In vielen Fällen wird man mit SetMenuItem einen Befehlscode setzen. Sobald dieser gesetzt ist, wird das WaitInput verlassen und der Befehlscode kann mit MenuItem() oder %MenuItem abgefragt werden.".
Vlt. sollte man in der Hilfe etwas mehr hinweisen. |
|
| |
| |
| |
|
(919)
Deutsch
English
Français
Español
Italia