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

[Zacherl]

Zitat von FarAndBeyond:

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

Klar, wenn du eh keine Sinnvolle Aktion im Fehlerfall ausführen kannst, dann brauchst du natürlich nicht jeden API Call prüfen.

Warum weglassen? Ist für ein kleines Projekt vielleicht halb so wild, aber je größer es wird, desto mehr sollte man Wurschtel-Code und unnötige Blöcke vermeiden. Vor allem kann ja zwischen den API Aufrufen wirklich nichts fehlschlagen. Ich glaube du hast so bisschen die Vorstellung, dass einfach mal "zufällig" durch den Maschinencode irgendwo Exceptions fliegen können. Das ist aber nicht der Fall.

[FarAndBeyond]

Zitat:

Ich glaube du hast so bisschen die Vorstellung, dass einfach mal "zufällig" durch den Maschinencode irgendwo Exceptions fliegen können. Das ist aber nicht der Fall.

Na das klingt doch gut... Ich denke mein Programm sitzt auf 'nem OS mit möglicherweise mehr als 50 Mio Zeilen Code und es laufen Prozesse, Dienste, Treiber und andere Programme und ich kann nicht so recht einschätzen was da wann und wo mit welcher Programm-Konstellation so alles passieren kann...
Wobei dann wahrscheinlich in so einem Fall mein TryExceptEnd auch nichts nutzt...

Sicher eine einfache Exception ist kein Problem, ein Teil des Programms funktioniert nicht mehr oder etwas kann nicht ausgeführt werden, aber das Programm läuft weiter... aber woher weiß ich das so genau. Deswegen gehe ich meistens vom WorstCase-Fall aus und schaue mal ob ich noch was anzubieten habe. TryExceptEnd ist quasi ein Ausschlußprinzip: Ich hab' dann alles gemacht was ich tun kann...

Ich hab' letztens bei einem Fremdprogramm etwas speichern wollen und es ging nicht. Da gibt das Programm 'ne Meldung aus in der steht "I/O ERROR 103".
Also auf sowas steh' ich einfach nicht! Das ich nicht speichern konnte hab' ich ja gemerkt, denn ich war ja dabei als nichts abgespeichert wurde... wozu also die Meldung und "103" ist natürlich enorm hilfreich... da weiß ich doch gleich was Sache ist...

Deswegen nehme ich lieber einen ErrorLog und schreibe dort alles rein... solange das sinnvoll ist, je größer das Programm, desto mehr Meldungsfenster braucht man natürlich... ganz besonders bei mehreren Auswahlmöglichkeiten.

[jaenicke]

Da macht es aber mehr Sinn die Exceptions zentral abzufangen, mit Application.OnException z.B.:
http://docwiki.embarcadero.com/CodeE...ption_(Delphi)

try..except benutzen wir nur, wenn wir an der Stelle diese Exception auch behandeln können und wollen. Andernfalls landet es im zentralen Exceptionhandler, der loggt, ggf. die Anwendung beendet usw.