Zwei Windows Explorer starten und nebeneinander bildschirmfüllend positionieren

[FarAndBeyond]

Hab' jetzt 3 Versionen:

TwoWinEx [FirstVersion]:
Funktioniert gut, kann aber in seltenen Fällen sein, dass ein Fenster im Hintergrund bleibt, obwohl das eigentlich bei "ShellExecute" und "Show" gar nicht sein dürfte.

TwoWinEx [MinAllWnds]:
100% stabil bei mir... sollte "Show" tatsächlich mal ein Fenster nicht nach vorne bringen spielt das keine Rolle, es werden ja vorher alle Fenster minimiert.

TwoWinEx [Restore]:
100% stabil bei mir... konnte ich aber noch nicht so lange ausprobieren.
Läuft mit "ShowWindow [SW_Minimize und SW_Restore]", alles andere funktionierte einmal mehr nicht.

"SetForegroundWindow" funktioniert für ein Fenster sehr gut, aber für zwei leider überhaupt nicht (Eins bleibt immer hinten).
"SetWindowPos" in Verbindung mit "HWND_NOTOPMOST" funktioniert ebenfalls überhaupt nicht. Wenn ich z.B. einige Editoren und einige Taschenrechner im Vordergrund habe und es sind schon 2 WinEx-Fenster geöffnet, dann bewegen sich die WinEx-Fenster kein Stück nach vorne... sehr komisch...

Das hier funzt bei mir sehr gut:

Delphi-Quellcode:

Procedure Bring2ToFront;
  Var
   WorkArea  : TRect;
   Wnd1, Wnd2: THandle;
 Begin
  Try
   SystemParametersInfo(SPI_GETWORKAREA, 0, @WorkArea,0) ;
    Wnd1:= StrToInt(slFoundWnd[0]);
    Wnd2:= StrToInt(slFoundWnd[1]);

    If IsIconic(Wnd1)
    Then
     Begin
      ShowWindow(Wnd1, SW_RESTORE);

      MoveWindow(Wnd1,
                 WorkArea.Left,
                 WorkArea.Top,
                 ((WorkArea.Right-WorkArea.Left) Div 2),
                 (WorkArea.Bottom-WorkArea.Top),
                 True);
     End
    Else
     Begin
      ShowWindow(Wnd1, SW_MINIMIZE);
      ShowWindow(Wnd1, SW_RESTORE);

      MoveWindow(Wnd1,
                 WorkArea.Left,
                 WorkArea.Top,
                 ((WorkArea.Right-WorkArea.Left) Div 2),
                 (WorkArea.Bottom-WorkArea.Top),
                 True);
     End;


    If IsIconic(Wnd2)
    Then
     Begin
      ShowWindow(Wnd2, SW_RESTORE);

      MoveWindow(Wnd2,
                 ((WorkArea.Right-WorkArea.Left) Div 2),
                 WorkArea.Top,
                 ((WorkArea.Right-WorkArea.Left) Div 2),
                 (WorkArea.Bottom-WorkArea.Top),
                 True);
     End
    Else
     Begin
      ShowWindow(Wnd2, SW_MINIMIZE);
      ShowWindow(Wnd2, SW_RESTORE);

      MoveWindow(Wnd2,
                ((WorkArea.Right-WorkArea.Left) Div 2),
                WorkArea.Top,
                ((WorkArea.Right-WorkArea.Left) Div 2),
                (WorkArea.Bottom-WorkArea.Top),
                True);
     End;
  Except
   On E: Exception
   Do ErrorLog('Bring2ToFront'+#13#10+E.ClassName+#13#10+E.Message);
  End;
 End;

Was der Restore-Version noch fehlt wäre eine Pfad-Anpassung. Das ist erstmal in Einzelschritten betrachtet sehr leicht:

1. Fenster nach vorne holen (passiert ja schon...)
2. VK_F4 und VK_ESC senden
z.B. so:

Delphi-Quellcode:

Procedure SendF4_ESC;
  Var
   KeyInputs: Array Of TInput;

  Procedure KeybdInput(VKey: BYTE; Flags: DWORD);
   Begin
    SetLength(KeyInputs, Length(KeyInputs)+1);
    KeyInputs[High(KeyInputs)].Itype:= INPUT_KEYBOARD;
     With KeyInputs[High(KeyInputs)].Ki
     Do
      Begin
       wVk    := VKey;
       wScan  := MapVirtualKey(wVk, 0);
       dwFlags:= Flags;
      End;
   End;

 Begin
  Try
   KeybdInput(VK_F4, 0);
   KeybdInput(VK_F4, KEYEVENTF_KEYUP);

   KeybdInput(VK_ESCAPE, 0);
   KeybdInput(VK_ESCAPE, KEYEVENTF_KEYUP);

   SendInput(Length(KeyInputs), KeyInputs[0], SizeOf(KeyInputs[0]));
  Except
   On E: Exception
   Do ErrorLog('SendF4_ESC'+#13#10+E.ClassName+#13#10+E.Message);
  End;
 End;

3. Edit-Feld des Windows-Explorer-Fensters suchen bzw. finden:
z.B. so:

Delphi-Quellcode:

Function ChildWndCallback(Wnd: HWND; lParam: LongInt): BOOL; StdCall;
  Var
   ClassName: Array[0..255] Of Char;
 Begin
  Try
   If GetClassName(Wnd, ClassName, 255) <> 0
   Then
    Begin
     If Pos('Edit', String(ClassName)) <> 0
     Then
      Begin
       slChildWnd.Add(IntToStr(Wnd));
       Result:= False;
      End;
     Result:= True;
    End
  Except
   On E: Exception
   Do ErrorLog('ChildWndCallback'+#13#10+E.ClassName+#13#10+E.Message);
  End;
 End;

4. Pfad senden: SendMessage(hChildWnd, WM_SETTEXT, 0, Integer(PChar('C:\')));

5. VK_RETURN senden

Allerdings wenn man alles zusammen schnell hintereinander haben möchte, dann braucht man wohl ein spezielles Timing. Also ein Delay oder Sleep oder Timer .... Ich hab' s ohne Sleep noch nie hinbekommen und außerdem ist das Ganze ein ziemlicher Overhead wenn ich das vergleiche mit den schon funktionierenden Versionen.

Hätte nie gedacht, das einen sowas Kleines 'ne ganze Weile beschäftigen kann...
Vielleicht hab' ich das auch einfach verkehrt gemacht und deshalb nicht hinbekommen... Ich mußte bis jetzt noch nie an anderen Programmen herumfummeln...

[DualCoreCpu]

Ich verwende zwar den Total-Commander, aber den Windows Explorer wie den Total-Commander verwenden zu können und das noch dazu vollautomatisch, ohne erst mühsam die beiden Exploer aufzurufen und auf dem Bildschirm nebeneinander zu positionieren, ist eine interessante Idee.

[jaenicke]

Zitat von DualCoreCpu:

ohne erst mühsam die beiden Exploer aufzurufen und auf dem Bildschirm nebeneinander zu positionieren, ist eine interessante Idee.

Naja, Win + E, Win + Links, Win + E, Win + Rechts finde ich jetzt nicht sonderlich mühsam.

Ich finde auch nach wie vor, dass die Simulation dieser Tastendrücke die sinnvollste Variante ist, weil man dabei eben den Windows Explorer auch aus dieser Maximierung in seine normale Größe ziehen kann. Das würde mir ansonsten massiv fehlen.

[FarAndBeyond]

Was ich auch sehr praktisch finde ist die Möglichkeit sich jederzeit ein drittes Fenster per CTRL+N zu holen und dieses dann entweder über das linke oder das rechte schon vorhandene Fenster zu legen. Damit kann man dann schnell mal aus einem anderen Verzeichnis Dateien kopieren ohne die beiden Hauptfenster zu verändern. Ich benutze den WinEx grundsätzlich ohne Baumstruktur, was man unter XP leider noch nicht konnte...

Zitat:

Naja, Win + E, Win + Links, Win + E, Win + Rechts finde ich jetzt nicht sonderlich mühsam.

Das sind 4 Tastenkombinationen nur um mal eben den WinEx zu starten... und was wenn man ihn schließt oder ein Fenster schließt und dann doch nocheinmal was kopieren möchte? Das wäre mir zu umständlich... (Außerdem rechne das mal hoch auf den Tag oder die Woche !!!) Zumal das schnelle Starten gerade eine der besonderen Stärken des WinEx ist. (Möglicherweise auch nur weil normalerweise jeder die Explorer.exe als Shell laufen hat.) Wer den SpeedCommander oder den TotalCommander nutzt wird wahrscheinlich nicht sofort nach jedem kleinen Kopiervorgang das Programm wieder schließen... (nicht das der Start ewig dauern würde, aber der Unterschied ist deutlich..)

Der bisher schnellste war sonst immer der DoubleCommander und der ist auch noch gratis... (Ob das immer noch so ist kann ich aber nicht sagen..)

Zitat:

..weil man dabei eben den Windows Explorer auch aus dieser Maximierung in seine normale Größe ziehen kann.

Ist das dein Ernst ? Welche Maximierung denn ?
Die beiden Fenster sind ja gar nicht ws_maximized... Das würde ja bedeuten du nutzt den Explorer gerne in einem noch kleineren Fenster... Na möglicherweise hast du einen sehr viel größeren Monitor, dann macht das ja vielleicht sogar Sinn...

[jaenicke]

Zitat von FarAndBeyond:

Wer den SpeedCommander oder den TotalCommander nutzt wird wahrscheinlich nicht sofort nach jedem kleinen Kopiervorgang das Programm wieder schließen... (nicht das der Start ewig dauern würde, aber der Unterschied ist deutlich..)

Deine Lösung dauert bei mir länger als den SpeedCommander zu starten.
Der startet bei mir in knapp 1,5 Sekunden (auf einem ca. 4 Jahre alten Rechner mit einem AMD Phenom II x4 955). Deine Lösung braucht etwa 2 Sekunden.

Nur dass ich im SpeedCommander dabei auch die ganzen angepinnten Seiten usw. geladen habe. Ohne das würde er sicherlich noch schneller starten...

Zitat von FarAndBeyond:

Ist das dein Ernst ? Welche Maximierung denn ?
Die beiden Fenster sind ja gar nicht ws_maximized... Das würde ja bedeuten du nutzt den Explorer gerne in einem noch kleineren Fenster... Na möglicherweise hast du einen sehr viel größeren Monitor, dann macht das ja vielleicht sogar Sinn...

Auf den beiden Fensterhälften verhält sich die Anwendung wie maximiert (sprich diese Fenstergröße wird eben nicht beibehalten usw.). Wenn ich den dann raus ziehe, nimmt er seine alte Größe wieder ein. Ich arbeite normalerweise nicht im Vollbild, auch nicht mit dem SpeedCommander.

[Zacherl]

Hier nochmal der Hinweis, dass Windows APIs keine Exceptions werfen. Die try..except Blöcke kannst du dir allesamt sparen. Sie werden nie greifen können. Stattdessen musst du den Rückgabewert jeder einzelnen API prüfen.

[FarAndBeyond]

Zitat:

Deine Lösung braucht etwa 2 Sekunden.

Verstehe, das ist sehr langsam, unter den Bedingungen würde ich den Explorer auch nicht nutzen wollen. Zumal der SpeedCommander einige Vorteile hat, aber auch einen besonders großen Nachteil: Keine Bildanzeige und gleichzeitige Dateianzeige mit Details. Ich kann darauf unmöglich verzichten.

Bei mir ist der Doppel-Explorer sofort beim Klick auf den Button arbeitfähig, da vergeht überhaupt keine erkennbare Zeit...

Zitat:

...(sprich diese Fenstergröße wird eben nicht beibehalten usw.)

W7 behält die Fensterposition nur wenn man das Fenster mit der Maus in der Größe verändert und selbst darauf kann man sich nicht verlassen. Wenn ich die Windows-Taste und die Pfeil-links_rechts-Taste verwende merkt sind Windows gar nichts. Vielleicht ist das tatsächlich 'ne Art Maximierung für Windows und deswegen merkt sich W7 die Grösse nicht...

Zitat:

...Stattdessen musst du den Rückgabewert jeder einzelnen API prüfen.

Ja, sagtest du schon.. aber unter D7 geht das bei EnumWindows nicht ohne "Incompatible Types"-Fehler, bei anderen API's dagegen schon (z.B. "GetClassName"). Ist aber auch für dieses TinyTool nicht logisch. Wenn ich auf etwas prüfe, dann macht das ja wohl nur Sinn, wenn ich bei Negativ-Prüfung etwas anderes machen möchte oder anzubieten habe. In diesem Fall hab' ich nichts anzubieten und müßte das Programm schließen. Aber auch das ist quatsch, da sich das Programm ja binnen Sekundenbruchteilen selber schließt...
Deswegen sehe ich den Nutzen hier nicht... den ZusatzCode kann ich mir sparen...

Wobei ich ja gut finde, dass die API keine Exception wirft, aber ich kann nicht beurteilen ob das absolut in jedem Fall so ist und ich kann ebenfalls keine Performance-Nachteile erkennen, die durch TryExceptEnd entstehen. Geht mit und ohne brutal schnell... wo ist also der Nachteil? Sollte etwas außerhalb der API's schief gehen, dann hab' ich's abgefangen...