Windows 7 Theme wechseln

[EWeiss]

Zitat:

Das öffnet zwar den Dialog, schließt ihn aber nicht wieder.

Wenn ShExecInfo über ein SendKeys verfügt sollte das doch ganz einfach mit SendKeys(VK_ENTER) zu schließen sein.
Ohne das du auf den OK Button drücken mußt.

Alternativ kannst du ja uses ShellObj einbinden und
objShell.Sendkeys(VK_ENTER) verwenden.

nicht getestet! ;)

Zitat:

Ich weiß leider wirklich nicht, wie ich das Handle des Fensters bekommen soll.

Kein Problem! Allerdings wie du schon sagtest Sprachabhängig!

eng.
FindWindow('CabinetWClass', 'Personalization')
de.
FindWindow('CabinetWClass', 'Anpassung')


PS:
Wenn du den Dialog nicht sehen willst solltest du SW_HIDE anstelle SW_SHOWNORMAL verwenden oder?


gruss

[EWeiss]

Hier mal ein minimales Beispiel.

Was nicht geht!

Alle "SW_" Flags haben keinen Einfluss beim Start des Dialogs.
Es wird nicht auf die Anwendung gewartet unter verwendung von MsgWaitForMultipleObjects warum auch immer..
mit der abgeänderten Function von Luckie ExecAndWait

gruss

[Keks]

Zitat:

Zitat von Union (Beitrag 1129561)

Wie wäre es mit einem Versuch über die Registry und dann einer Broadcast-Message mit WM_STYLECHANGED?

Es gibt wohl keinen einzelnen Registry-Eintrag für das aktuelle Theme. Stattdessen müsste ich alle Teile aus der .theme-Datei einzeln anwenden oder in die Registry schreiben, was sowohl unsauber und aufwändig ist als auch viele Fehlerquellen mit sich bringt.

Zitat:

Zitat von EWeiss (Beitrag 1129562)

Wenn du den Dialog nicht sehen willst solltest du SW_HIDE anstelle SW_SHOWNORMAL verwenden oder?

Das hat imho keine Auswirkung auf das Starten des ControlPanels. Die Ursache für das Handle-Problem und die Ursache dafür, dass das Theme-ControlPanel keine .exe-Datei ist sondern eine .cpl-Datei. Diese wird durch einen Hilfsaufruf von (vermutlich) rundll32.exe aufgerufen. Davon kommt auch das Handle und diese exe erhält auch die SW_-Tags.

Soweit ich weiß, wäre das hier der vollständige Aufruf:

Code:

C:\Windows\system32\rundll32.exe C:\Windows\system32\shell32.dll,Control_RunDLL C:\Windows\system32\desk.cpl desk,@Themes /Action:OpenTheme /file:"C:\Windows\Resources\Themes\nature.theme"

Also entweder man kann irgendwie das (Child?-)Handle vom durch die exe aufgerufenen Fenster erhalten oder dann doch so wie Lucky als Alternative schrieb:

Zitat:

Zitat von Luckie (Beitrag 1129545)

Man könnte auch alle Fenster enummerieren und gucken zu welchen Prozess sie gehören und wenn man das richtige gefunden hat WM_CLOSE an das Fenster senden.

Allerdings frage ich mich, ob man das zuverlässig zuordnen könnte. Was soll denn da als Prozess drin stehen? Ist das dann wirklich eindeutig?

[Luckie]

Ein Fenster kann nur zu einem Prozess gehören.

[Keks]

Zitat:

Zitat von Luckie (Beitrag 1129609)

Ein Fenster kann nur zu einem Prozess gehören.

Meine Aussage war eher, dass zu einem Prozess mehrere Fenster gehören könnten. D.h. wenn der Prozess rundll32.exe ist, heißt das nicht, dass es sich beim Fenster um das Theme-Fenster handelt.

[EWeiss]

Zitat:

Das hat imho keine Auswirkung auf das Starten des ControlPanels. Die Ursache für das Handle-Problem und die Ursache dafür, dass das Theme-ControlPanel keine .exe-Datei ist sondern eine .cpl-Datei. Diese wird durch einen Hilfsaufruf von (vermutlich) rundll32.exe aufgerufen. Davon kommt auch das Handle und diese exe erhält auch die SW_-Tags.

Mein Sample mal geladen?

Ist doch uninteressant ob exe oder cpl
Auch ein Dialog-Fenster hat ein Handle sollte also auch auf die messagen SW_SHOW oder SW_HIDE reagieren.
Das Handle kommt nicht von der rundll32.exe sondern vom Dialog-Fenster.

Und zwar wie schon geschrieben mit

Delphi-Quellcode:

FindWindow('CabinetWClass', 'Anpassung')

gruss

[Keks]

Zitat:

Zitat von EWeiss (Beitrag 1129614)

Mein Sample mal geladen?

Ähm, nein ... Du hattest doch selbst geschrieben, dass es nicht geht!?

Zitat:

Zitat von EWeiss (Beitrag 1129614)

Das Handle kommt nicht von der rundll32.exe sondern vom Dialog-Fenster.

Was macht Dich da so sicher? Wenn das so wäre, müsste ja mein Code funktionieren:
http://www.delphipraxis.net/1129551-post9.html

Zitat:

Zitat von EWeiss (Beitrag 1129614)

Und zwar wie schon geschrieben mit

Delphi-Quellcode:

FindWindow('CabinetWClass', 'Anpassung')

Dann noch ein drittes Mal: Für FindWindow muss ich den Fenstertitel kennen. Das ist aber sprachabhängig und ich kann nicht die Sprache des Betriebssystems vom Benutzer voraussetzen oder bestimmen.

[EWeiss]

Zitat:

Was macht Dich da so sicher? Wenn das so wäre, müsste ja mein Code funktionieren:

Tut er auch!
Vorraus gesetzt du verwendest das richtige Handle was du "zum dritten mal" über FindWindow in Erfahrung bringen mußt
und das geht nun mal nur über den Window Titel

Und warum soll das nicht gehen über die Sprachen?
Es wird doch eine Api geben mit der man die Lokale Sprache identifizieren kann.

Meim Sample funktioniert und der Dialog wird auch ordnungsgemäß geschlossen.

PS:
Mit "Was nicht geht!"
Meinte ich die funktionen die ich nachher aufgelistet habe
SW_ Flags und das warten auf den Dialog (Deshalb auskommentiert und Sleep(2000) eingefügt)

Zitat:

dass das Theme-ControlPanel keine .exe-Datei ist sondern eine .cpl-Datei.

Nur so nebenbei keine .cpl Datei sondern eine DLL die NUR zu .cpl umbenannt wurde zur besseren identifizierung siehe (Systemsteuerung)
Alternativ könntest du den Namen auch über TCPLInfo in erfahrung bringen.



gruss

[Keks]

Zitat:

Zitat von EWeiss (Beitrag 1129618)

Meim Sample funktioniert und der Dialog wird auch ordnungsgemäß geschlossen.

Du verwendest ja auch FindWindow. Ich kann dies aber nicht verwenden, da ich sonst für jede Windowssprache vorab herausfinden müsste, wie die lokale Bezeichnung des Fensters lautet.

Ich habe mal einen neuen Ansatz gestartet:

Delphi-Quellcode:

function EnumWindowsProc(wHandle: HWND; m: TMemo): Bool; stdcall; export;
var
  Title, ClassName: array[0..255] of char;
  tid, pid: DWORD;
begin
  Result := True;
  GetWindowText(wHandle, Title, 255);
  GetClassName(wHandle, ClassName, 255);
  tid := GetWindowThreadProcessId(wHandle, @pid);
  if IsWindowVisible(wHandle) then
     m.Lines.Add(string(Title) + ' | ' + string(ClassName) + ' | '+ IntToStr(tid)+'/'+IntToStr(pid));
end;

procedure TSystemForm.Button5Click(Sender: TObject);
var
  pi: TProcessInformation;
  si: TStartupInfo;
  aFile : String;
begin
  aFile := 'notepad.exe';
  //aFile := 'C:\Windows\system32\rundll32.exe C:\Windows\system32\shell32.dll,Control_RunDLL C:\Windows\system32\desk.cpl';
  FillMemory( @si, sizeof( si ), 0 );
  si.cb := sizeof( si );
  si.dwFlags := STARTF_USESHOWWINDOW;
  si.wShowWindow := SW_SHOWNORMAL;
  CreateProcess(
    Nil,
    PChar( aFile + '' ),
    Nil, Nil, False,
    NORMAL_PRIORITY_CLASS, Nil, Nil,
    si, pi
  );
  Memo1.Lines.Add('processinfo.dwProcessId: '+IntToStr(pi.dwProcessId));
  sleep(5000);
  EnumWindows(@EnumWindowsProc, Integer(Memo1));
end;

Das ist schön, denn damit erhalte ich eine Test-Ausgabe wie:
processinfo.dwProcessId: 7896
Unbenannt - Editor | Notepad | 10084/7896

Womit ich das Fenster dem aufrufenden Prozess zuordnen kann.
Das funktioniert dann zwar mit einem ausführbaren Programm wie notepad.exe, aber nicht beim Ausführen einer .cpl per rundll.32.exe.