FileCommander

progandy

Zitat von Raupi

Einfach beim FileOpenDialog den Parenthandle weglassen. Aus irgendwelchen Gründen wird beim abbrechen
oder schlißen des Dialoges der 1. Drivebutton ausgelöst, dadurch wird die Funktion _ReadDriveLeft ausgelöst.
Das ist ein scheiß Fehler und war verflucht schwer zu finden.

Den Fehler hatte ich auch schon einmal. Es sollte reichen, die GUI zu deaktivieren und danach wieder aktivieren

[autoit]

GUISetState(@SW_DISABLE, $hGui)
$sPath = FileOpenDialog($sTitle & ' - Hex-Editor auswählen', $sDefaultDir, 'Programm (*.exe)', 3, '', $hGui)
GUISetState(@SW_ENABLE, $hGui)

[/autoit]

**Raupi**

Ist trotzdem ein Scheißfehler

**Oscar**

Tweaky: Den Refreshfehler kann ich bestätigen (unter WinXP). Unter Win7 tritt er aber nicht auf. Das dürfte ein Windows-Bug sein?!

@All: Den FileOpen-Bug kann ich hier nicht nachvollziehen (weder unter Win7 (64 Bit), noch unter WinXP (32 Bit)). Der tritt bei mir nicht auf.
Ich möchte allerdings nicht das Window-Handle weglassen, weil der Dialog dann kein Child-Fenster mehr ist. Somit würde ich die Methode von Progandy (deaktivieren der GUI) favorisieren, wenn damit der Fehler bei euch behoben ist. Kann das mal jemand ausprobieren und bestätigen?

progandy

Der Fehler tritt bei mir genau dann auf, wenn der erste Luafwerksbutton der linken Listview aktiviert ist. Ist gerade das 2. LW aktiv, dann passoert nichts. Entweder ist das ein Windows- oder AutoItbug (Win7 Prof x64 sowohl mit 32 als auch 64bit Exe)
Durch das deaktivieren der GUI wird der Bug umgangen, da dann ja keine Kommandos an das Fenster gesendet werden.

**UEZ**

Tja, mit der Abwärtskompatibilität ist das so eine Sache. Wie weit nach unten sollte man sein Code versuchen kompatibel zu halten?

Ich persönlich bin der Meinung, dass man langsam, aber sicher, sich von BS kleiner Vista verabschieden sollte! Ansonsten hier eine Ausnahme, dort eine Ausnahme.

Ich muss z.B. feststellen, dass mein Windows Screenshooter unter WinXP gar nicht richtig läuft (hatte ich per Zufall entdeckt)!

Gruß,
UEZ

**Oscar**

@progandy: Ah! Jetzt kann ich den Fehler auch nachvollziehen.
Ja, beim ersten Laufwerksbuchstaben tritt das tatsächlich auf. Nur ist bei mir der erste Laufwerksbuchstabe "A:" = Diskette. Deshalb hatte ich immer mit den anderen getestet. Ok, also: @SW_DISABLE. Wäre das geklärt. Danke!

UEZ: WinXP würde ich schon noch unterstützen wollen. Es gibt doch einige, die noch XP einsetzen. Es ist allerdings nicht ganz leicht, weil sich manche Funktionen stark unterscheiden. Da gebe ich Dir recht.

**BugFix**

Zitat von UEZ

Ich persönlich bin der Meinung, dass man langsam, aber sicher, sich von BS kleiner Vista verabschieden sollte! Ansonsten hier eine Ausnahme, dort eine Ausnahme.

Ist aber nicht sehr logisch, da der Support für Vista noch vor dem für XP ausläuft. ( Wie das halt mit tot geborenen Kindern so ist. )

**Oscar**

So, es gibt mal wieder eine neue Version (Post #1).

Das erstellen der Dateilisten konnte ich etwas beschleunigen. Gitternetzlinien und Tastaturbedienung sind nun möglich. Und die, von euch gemeldeten, Fehler habe ich beseitigt.

Micha_he

Ist es gewollt, das die Laufwerks-Buttons in der kleinsten Fenstergröße, etwas zu klein für Bild und Text sind ?

Siehe: Der Inhalt kann nicht angezeigt werden, da er nicht mehr verfügbar ist.

Edit: wie blubbstar schrieb: unter Windows7 64bit

blubbstar

Ich vermute mal er hat XP und du 7. Da wird ja alles immer ein wenig größer dargestellt

name22

Unter Windows Vista Home Premium 32 Bit sind die Buttons der Laufwerke auch zu klein...

**Oscar**

Darauf ein klares: Jein!

Genaugenommen liegt es daran, dass ich XP (Notebook) und Win7 (Desktop) besitze. Unter XP werden die Icons nicht dargestellt, was es ermöglicht, das Fenster kleiner zu ziehen als unter Win7, wo zusätzlich die Icons angezeigt werden.
Das führt dann dazu, dass unter Win7 die Buttons zu klein sind (in der kleinsten Fenstergröße). Muss ich wohl mal eine OS-abhängige Mindestgröße einbauen...

blubbstar

Ahja, du hast Recht!

**Tweaky**

Danke für die neue Version.

Ich hab eine Bug entdeckt
Folgendes passiert, wenn sich in einem Ordner versteckte Dateien befinden:
1. Die 1. versteckte Datei wird trotzdem angezeigt (bei dem Attribut ist H jedoch gesetzt, also korrekt)
2. Alle nicht versteckten Dateien die sich nach der 1. versteckten Datei befinden werden trotzdem nicht angezeigt

**Oscar**

Tweaky: Stimmt! Blöder Fehler! Ist beim optimieren passiert. Habe die eine Zeile nicht mit nach oben verschoben. Ist behoben! Danke!

In der neuen Version (Post#1) habe ich ausserdem noch das Vorschaufenster etwas "verfeinert" (Größe und Position sind jetzt an die FileCommander-Größe angepasst und man kann das Bild mit den Pfeiltasten drehen).

**Oscar**

Jetzt gibt es einen Geschwindigkeitsrausch.

Die Funktion "_GUICtrlListView_AddArrayEx" ist sowas von schnell gegenüber dem einzelnen erstellen mit "GUICtrlCreateListViewItem", dass ich das kaum für möglich gehalten hatte.
Eigentlich wollte ich eine Art Buffer für die Dateilisten einbauen und brauchte dafür eine Funktion, die auch den Image-Index mit übernimmt. So habe ich dann die Original-Funktion modifiziert und rausgekommen ist das.
Jetzt weiss ich gar nicht, ob ich den Buffer noch zusätzlich einbauen soll. Das testen, ob das aktuelle Verzeichnis im Buffer vorhanden ist, könnte da ja schon fast länger dauern.

Naja, schaut es euch an. Neue Version in Post#1.

**Oscar**

Es gibt wieder eine neue Version (siehe Post#1).

Ich habe eine umfangreiche Suchfunktion eingebaut (mit StringInStr- und StringRegExp-Suche). Außerdem kann man Verknüpfungen erstellen und einige kleinere Fehler sind nun behoben.

**Oscar**

Ich habe die Suchfunktion noch weiter ausgebaut (siehe Screenshot) und einen kleinen Fehler behoben (Danke, Kleiner).

Neue Version in Post#1.

**Oscar**

Ich habe eine Art Toolbar hinzugefügt (siehe Screenshot). Es ist eigentlich eine Reihe von Buttons (weil die Toolbar-UDF zu viele Probleme macht).
Man kann Exe-Dateien per Drag&Drop in die Leiste reinziehen und es wird automatisch ein Button erstellt. Per Kontextmenü kann man die Buttons auch wieder löschen.

Sortieren und umbenennen geht noch nicht (muss mir erstmal ein Konzept dafür überlegen). Das heißt, wer das will, kann die Einträge in der Inidatei entsprechend anordnen. Die werden von links nach rechts in der Sektion "[DropToolbarPath]" abgelegt. Dabei ist der Teil vor dem "=" der ToolTip-Name und hinter dem "=" steht der volle Pfad zur Exedatei.

Man kann nun auch die im Explorer ausgeblendeten Laufwerke hier im FileCommander ausblenden lassen (Einstellungsmenü). Ausserdem habe ich noch eine Möglichkeit zum Konfigurieren dieser Ausblendfunktion eingebaut. Danke für den Tipp, BuFF!

Und wenn kein externer HexEditor eingetragen ist, wird ein einfacher, kleiner HexViewer (im Tools-Verzeichnis) verwendet. Danke für die Funktion, Kleiner!

Neue Version in Post#1.

**Tweaky**

Beim hochziehen der ersten exe in die Toolbar kommt ein Fehler

[autoit]

==> "ReDim" used without an array variable.:
ReDim $ahDropToolbarButton[$i]
ReDim ^ ERROR

[/autoit]