Windows 7 Theme wechseln

[Keks]

Ich würde gerne aus meinem Delphi-Programm das aktuell verwendete Windows Design Theme ändern können.
Also beispielsweise auf C:\Windows\Resources\Themes\architecture.theme umschalten.
Unter XP gab's ja noch spezielle ThemeManager-Schnittstellen dafür, unter Win7/Vista finde ich jedoch leider nichts dazu.

Die einfachste Methode ist wohl, die Theme-Datei direkt auszuführen:

Delphi-Quellcode:

ShellExecute(0, 'open', PChar('C:\Windows\Resources\Themes\architecture.theme'), nil, nil, SW_SHOWNORMAL);

.

Dann wird das Design auch tatsächlich sofort übernommen. Allerdings öffnet sich dabei leider auch die Theme-Verwaltung von Windows, die noch manuell geschlossen werden muss.

Gibt es eine bessere Möglichkeit, um Themes unter Windows 7 direkt aktivieren zu können?
Oder lässt sich das Öffnen der Themes-Verwaltung unterbinden?
Oder notfalls irgendwie gezielt, schnell automatisch schließen?

[Daniel]

Ich denke, dass Dir die System-Funkton "SetSystemVisualStyle" weiterhelfen wird. Auf den ersten Blick scheint die aber ... "unterdurchschnittlich" ... dokumentiert zu sein.

Google liefert Dir aber eine Handvoll Treffer, u.a. auch dieses Forum.

[Keks]

Hm, ich habe mich jetzt eine Weile über die empfohlene Funktion SetSystemVisualStyle eingelesen. In allen Beispielen wurde diese aber verwendet, um eine .msstyles Datei zu aktivieren, nicht eine .theme Datei. Diese .msstyles-Dateien wurden aber soweit ich weiß nur XP verwendet. Zumindest finde ich in meinem Win7 keine .msstyles-Dateien (doch genauer gesagt exakt eine "aero.msstyles", aber da sehe ich erstmal keinen Bezug zu den vielen vorhandenen .theme Dateien.)

Habe jetzt trotzdem mal versucht, was die Funktion unter Win7 mit einer .theme Datei bewirkt:

Delphi-Quellcode:

function SetSystemVisualStyle(pszFilename, pszColor, pszSize: PChar;
    dwReserved: Integer): Integer; stdcall; external 'uxtheme.dll' index 65;
res := SetSystemVisualStyle('C:\Windows\Resources\Themes\nature.theme', 'NormalColor', 'NormalSize', 1);

Als Rückgabewert erhalte ich -1878589247, was mir leider nichts sagt. Bewirken tut die Funktion augenscheinlich auch nichts.

[Keks]

Zitat:

Zitat von Keks (Beitrag 1129357)

Als Rückgabewert erhalte ich -1878589247, was mir leider nichts sagt. Bewirken tut die Funktion augenscheinlich auch nichts.

Keiner sonst eine Idee?

Wenn es tatsächlich keine direkte Lösung geben sollte, würde mich mich mittlerweile auch mit einem manuellen Schließen des Theme-Fensters begnügen. Leider bekomme ich das auch nicht so recht hin...
Das Problem ist, dass beim Aufrufen eines cpl-Fensters in nachfolgender Form kein passendes Handle zurückgeliefert wird.
Hier mal aufs Nötigste heruntergebrochen:

Delphi-Quellcode:

h := ShellExecute(0, 'open', PChar('C:\Windows\system32\desk.cpl'), nil, nil, SW_SHOWNORMAL);
sleep(5000);
PostMessage(h, WM_CLOSE, 0, 0);

Wird zwar geöffnet aber nicht wieder geschlossen. Vermutlich gehört das zurückgegebene Handle zu rundll32.exe oder einem anderen aufrufenden Prozess.
Ich könnte das Handle nachträglich per FindWindow holen, aber dafür muss ich den Fenstertitel festlegen, der aber sprachabhängig ist und ich kann keine bestimmte Sprache vorab voraussetzen.

[mirage228]

Der Artikel bringt vielleicht etwas Licht ins Dunkel bei den .THEME-Dateien: http://www.codeproject.com/KB/miscctrl/uxtheme.aspx

Das sind wohl eigentlich INI-Dateien, wo zwar auf die Aero.msstyles verwiesen wird, aber auch noch andere Infos, wie Bildschirmhintergrund und Mauszeiger festgelegt werden.
Vielleicht ist Dir das ja noch ein Ansatzpunkt, Deine Suche noch mal in eine andere Richtung zu gestalten? Irgendwie müsste das ja bestimmt gehen... :)

[Luckie]

Argh, lies doch bitte mal die Dokumentation, was ShellExecute für einen Wert zurück gibt.

Suche mit FindWindow das Fenster und Sende an das gefundene Handle die WM_CLOSE Nachricht.

[Keks]

Zitat:

Zitat von mirage228 (Beitrag 1129526)

Das sind wohl eigentlich INI-Dateien, wo zwar auf die Aero.msstyles verwiesen wird, aber auch noch andere Infos, wie Bildschirmhintergrund und Mauszeiger festgelegt werden.

Danke, das ist interessant. Habe mir die .theme Datei jetzt mal genauer angeschaut und das ist in der Tat "nur" eine Sammlung aller Design-Eigenschaften. Ich könnte jetzt natürlich alle diese Eigenschaften manuell setzen, aber das halte ich doch für etwas aufwändig in der Umsetzung...

Zitat:

Zitat von Luckie (Beitrag 1129527)

Argh, lies doch bitte mal die Dokumentation, was ShellExecute für einen Wert zurück gibt.

Das hatte ich wohl falsch in Erinnerung ... sorry.

Zitat:

Zitat von Luckie (Beitrag 1129527)

Suche mit FindWindow das Fenster und Sende an das gefundene Handle die WM_CLOSE Nachricht.

Dazu hatte ich ja schon geschrieben: "Ich könnte das Handle nachträglich per FindWindow holen, aber dafür muss ich den Fenstertitel festlegen, der aber sprachabhängig ist und ich kann keine bestimmte Sprache vorab voraussetzen." - Außer Du kannst mir sagen, wie ich das Sprachenunabhängig machen kann...

[Luckie]

Dann starte den Prozess mit CreateProcess oder ShellExecuteEx, dann hast du ein Prozesshandle, welches du TerminateProcess übergeben kannst. Ist zwar nicht sehr schön, den Prozess so hart zu beenden. 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. Das wäre die sauberere aber aufwendigerer Lösung.

Und nebenbei bemerkt, gibt es zu dem Problem (Programm starten und beenden) schon genug Beitrage hier im Forum.

[Keks]

Zitat:

Zitat von Luckie (Beitrag 1129545)

Programm starten und beenden

Es handelt sich ja um kein Programm per se. Alles, was ich zu dem Thema gefunden habe, beschäftigt sich mit richtigen Programmen. Hier soll ja ein ControlPlanel geschlossen werden. Da ist die Suche nach dem richtigen Handle imho nicht so trivial. Ich lasse mich aber gerne eines Besseren belehren.

Mein Versuch:

Delphi-Quellcode:

      ShExecInfo.cbSize := sizeof(SHELLEXECUTEINFO);
      ShExecInfo.fMask := SEE_MASK_NOCLOSEPROCESS;
      ShExecInfo.lpVerb := 'runas';
      ShExecInfo.lpFile := 'control';
      ShExecInfo.lpDirectory := nil;
      ShExecInfo.lpParameters := 'C:\Windows\system32\desk.cpl desk,@Themes';
      ShExecInfo.nShow := SW_SHOWNORMAL;

      ShellExecuteEx(@ShExecInfo);

      sleep(5000);

      //PostMessage(ShExecInfo.Wnd, WM_CLOSE, 0,0);
      TerminateProcess(ShExecInfo.hProcess, 0);

Das öffnet zwar den Dialog, schließt ihn aber nicht wieder.
Ich weiß leider wirklich nicht, wie ich das Handle des Fensters bekommen soll. :(

[Union]

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

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