Dateiordner öffnen vergleichsweise langsam

L

likefc

Herzlich willkommen!
Windows10 20H2, x64; FreeCommander X§ public portable 2020/ build 840

Bin auf der Suche nach einem Ersatz-Dateimanager für xyplorer auf FC XE gestossen und sehr beeindruckt von seiner Funktionsfülle und den uerschöpflichen Möglichkeiten der Anpassung. Das ist einfach klasse.
Ein einziger Punkt jedoch stört mich sehr (er wird nur dann stören, wenn man nicht zuweilen, sondern oft und heftig in Verzeichnisbäumen navigiert):

Linkes Panel Verzeichnisbaum, rechtes Panel 1..n Ordertabs:

Beim Klick auf eine Treenode im Verzeichnisbaum öffnet der zugehörige Dateiordner äusserst behäbig. Deutlichst behäbiger als bei fast allen mir sonst bekannten Managern, egal ob man den Windows Explorer, IDosWin Pro, xyplorer, Explorer++ oder ähnliche andere versucht. Alle reagieren auf den Klick auf einen Verzeichnisknoten merklich schneller, auch wenn es sich nur um vergleichsweise wenig Dateiobjekte handelt.

Ich fage mich, woran dies liegen könnte. Die grundsätzliche Implementierungstechnik (bsw. Iteration über Shell-Objekte vs. Dateisystemobjekte o.Ä.) sollte dies eigentlich nicht begründen können.
Hat hier jemand eine Idee? Wird hier vielleicht im Hintergrund ggf. doppelte Arbeit verrichtet , oder gibt es für den Treenode single-click einen Timer. welcher möglicherweise auf einen Doppelklick wartet? Oder mögliche andere Gründe?

Die Settings sind die Initialsettings; AV ist ausgeshaltet; Netzwerklaufwerke sind nicht im Spiel: Verzeichnisgrössen werden nicht angezeigt; die Icons werden ermittelt wie registriert.
 
Hat hier jemand eine Idee? Wird hier vielleicht im Hintergrund ggf. doppelte Arbeit verrichtet , oder gibt es für den Treenode single-click einen Timer. welcher möglicherweise auf einen Doppelklick wartet? Oder mögliche andere Gründe?
Zum Vergrößern anklicken....
Ja, ich habe eine Idee.
Es ist wirklich ein Timer im Spiel. Der ist wichtig, wenn man mit der Tastatur (Pfeil-Nach-Unten, Pfeil-nach-Oben) navigiert.
Beim Klick aber verursacht kleine Verzögerung (250 ms).
Für die nächste Version wird beim Klick der Timer nicht mehr gestartet.
Danke für den Hinweis.
 
Super! Dies klingt für mich äusserst plausibel ... die 250ms passen von der Zeit her ziemlichi genau zu der Verzögerung nach node click, die bei mir immer das störende Gefühl zurücklässt, als sei hier völlig unnötig eine angezogene Handbremse im Spiel.
Bestätigende Gegenprobe ist: sind die 250ms erst mal vertrödelt, dann geschieht der Rest des Einlesens auch grosser Verzeichnisse (bsw testhalber windows\systen32) ja ziemlich schnell, so wie ich es von der zugrundeliegenden Programmiersprache auch kenne.
Bin sehr gespannt -- vielmals danke für die Aufmerksamkeit!
 
Hallo Marek,
nur am Rande eine kurze Überlegung,
Ich vermute, dass der Timer für Tastatur Pfeil-nach-oben etc. nötig ist, um überflüssige IOs zu vermeiden (damit "Zwischenstationen" bei der Navigation nicht als zu öffnende Verzeichnisse behandelt werden). Wenn für die Zielknoten aber das KeyUp-event (statt OnKeyDown) auswertet wird, dann sollte zumindest dafür ein Timer eigentlich gar nicht nötig sein. Bei OnKeyDown aber schon, denn das wird für jeden einzelnen Zwischenknoten ausgelöst. - Sollte bereits OnKeyUp ausgewertet werden, simply forget.
Und was mir dabei noch aufgefallen war: wenn ein tree node selektiert wird, wird dann das ganze tree control neu gezeichnet, warum? (es flackert)
Viele Grüsse!
likefc
 
Hallo Marek,
sorry, dass cih das Thema nochmal aufgreife: ist die Änderung (Timer beim treenode click auschalten (ggf. als tweak im inifile)) berücksichtigt?
(Ich sehe es nicht in der Änderungsliste für die 841 donor. Sollte ich es ggf. als Feature request für die public offiziell im EN-forum abstellen?)
-
Und nochmal kurz zum Flicker: LockWindowUpdate (aus/an) vor/nach den Verzeichnisaktionen bewirkt Einiges. Ist es bereits im Einsatz.
Entschuldige für meine Nachfrage
und Grüsse,
likefc
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben