Italia
Foro

Erledigt: Seltsames Phänomen Listview per Directories

 

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 grande. 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.

237 kB
Hochgeladen:15.07.2009
Downloadcounter52
Download
 
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
Ciao,

also bei mir stürzt er schon beim Versuch ab, in ein Verzeichnis "Adressen" zu wechseln, gleiches konnte ich auch per 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 ...

Saluto
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 potuto 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$() il valore ermitteln, was naturalmente unnötig Zeit kostet.

Ach so: Es potuto noch damit zu tun haben, das der Ordner an erster Stelle steht. Dann ist bei mir das Programm am häufigsten abgestürzt.

Saluto
Jörg

13 kB
Hochgeladen:15.07.2009
Downloadcounter32
Download
 
Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...
15.07.2009  
 




Dieter
Zornow
Danke per 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 un 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.
 
15.07.2009  
 




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 File probiert habe, denn nur die geht, da alles in einer File 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 File probiert habe, denn nur die geht, da alles in einer File ist, kam die folgende Meldung


Mit dem Debuger kannst Du ja zeilenweise durch das Programm gehen. Bei welcher Zeile kommt denn die Meldung?

Saluto
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 File 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 File separiert werden. Soweit bin ich, weiß aber nicht wie abstellen.

4 kB
Hochgeladen:16.07.2009
Downloadcounter29
Download
 
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)
 
16.07.2009  
 




Jörg
Sellmeyer
Ich habe das Startverzeichnis mal auf "Cokumente und EinstellungenJörgDesktopgriddir" gesetzt.
Darin liegt nicht die prf-File! 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 File), 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 potuto
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 per 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 per 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 Aiuto sagt "WICHTIG: In der SubClassProc sollte so wenig wie possibile 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 Aiuto etwas mehr hinweisen.
 
16.07.2009  
 




Answer


Topictitle, max. 100 characters.
 

Systemprofile:

Kein Systemprofil angelegt. [anlegen]

XProfan:

 Posting  Font  Smilies  ▼ 

Bitte anmelden um einen Beitrag zu verfassen.
 

Topic-Options

8.716 Views

Untitledvor 0 min.
Michael W.07.07.2016
Ernst21.05.2016
Michael Borowiak29.12.2012
Jörg Sellmeyer06.11.2011
Di più...

Themeninformationen



Admins  |  AGB  |  Applications  |  Autori  |  Chat  |  Informativa sulla privacy  |  Download  |  Entrance  |  Aiuto  |  Merchantportal  |  Impronta  |  Mart  |  Interfaces  |  SDK  |  Services  |  Giochi  |  Cerca  |  Support

Ein Projekt aller XProfaner, die es gibt!


Il mio XProfan
Private Notizie
Eigenes Ablageforum
Argomenti-Merkliste
Eigene Beiträge
Eigene Argomenti
Zwischenablage
Annullare
 Deutsch English Français Español Italia
Traduzioni

Informativa sulla privacy


Wir verwenden Cookies nur als Session-Cookies wegen der technischen Notwendigkeit und bei uns gibt es keine Cookies von Drittanbietern.

Wenn du hier auf unsere Webseite klickst oder navigierst, stimmst du unserer Erfassung von Informationen in unseren Cookies auf XProfan.Net zu.

Weitere Informationen zu unseren Cookies und dazu, wie du die Kontrolle darüber behältst, findest du in unserer nachfolgenden Datenschutzerklärung.


einverstandenDatenschutzerklärung
Ich möchte keinen Cookie