Wizualne Style Windows XP

Zauważ, że artykuł ten nie dotyczy tylko i wyłącznie oprogramowania mojego autorstwa. Porady w nim zawarte mogą być stosowane także względem innych aplikacji.

Najczęściej dostrzeganym nowym elementem systemu Windows XP jest niewątpliwie obsługa tzw. Wizualnych Stylów. Podobną funkcjonalność oferuje także składnik systemu Windows 2003, choć opcja ta domyślnie jest tutaj (w przeciwieństwie do Windows XP) wyłączona. Wizualne Style umożliwiają zmianę wyglądu interfejsu uruchamianych aplikacji, podobnie jak 'skórki' używane w wielu popularnych aplikacjach takich jak np. Winamp. Wizualne Style już od czasu wprowadzenia stały się kontrowersyjnym składnikiem systemu. Niektórzy uważali je za element który należało wprowadzić już dawno, aby urozmaicić używany przez ponad sześć lat - w systemach od Windows 95 aż po Windows 2000 - interfejs systemu. Inni jednak twierdzili, że to tylko typowy 'fajerwerk' jakim światowy potentat chce zachęcić użytkowników systemów linuxowych do korzystania z własnego produktu. Takie jest także i moje zdanie, jednak znając preferencje użytkowników mojego oprogramowania zdecydowałem się napisać ten artykuł.

W edycjach systemu Windows obsługujących Wizualne Style można spotkać się dosyć często z dziwnym problemem. Kiedy obsługa Wizualnych Stylów jest aktywna część programów, a nawet składników systemu, używa klasycznego interfejsu znanego z systemów Windows 95 - 2000, jedynie obramowanie ich okien oraz paski przewijania ulegają zmianie. Dlaczego tak się dzieje ? Otóż Microsoft planując wykorzystanie Wizualnych Stylów w swych systemach operacyjnych zapewne napotkał pewną trudność. Elementy klasycznego interfejsu były bardzo proste, większość kontrolek systemowych (pola edycji, przyciski, rozwijane listy wyboru itd.) składało się wręcz z kilku linii, które przy zachowaniu odpowiedniej kolorystyki dawały wrażenie głębi. Dzięki temu twórcy oprogramowania często decydowali się na 'ręczne' rysowanie elementów interfejsu. W końcu typowy przycisk to jedynie cztery linie w odpowiednich kolorach. Pobierając więc odpowiednie kolory od systemu i rysując go ręcznie - tak aby wyglądał jak typowa systemowa kontrolka - omijało się kilka problemów pojawiających się w systemie, zaś użytkownik programu nie widział żadnej różnicy. Jakich problemów ? M.in. takich iż wiele kontrolek systemowych było pozbawionych wymaganej przez twórców oprogramowania funkcjonalności. Np. klasyczne 'suwaki' używane w systemie informowały aplikację o swym postępie co każdy piksel ruchu, a nie po zakończeniu ich przeciągania, co mogło doprowadzić do pozornego zawieszenia aplikacji, np. w sytuacji gdy wykonywane są czasochłonne operacje po każdej zmianie pozycji suwaka. Podobnie paski postępu pozbawione były napisu informującego o procentowym postępie danej operacji itd. Stąd twórcy oprogramowania często decydowali się na tworzenie 'ręcznie' rysowanych kontrolek zbliżonych wyglądem (czasem wręcz nie do odróżnienia) do tych zawartych w systemie jednak zaopatrzonych w dodatkową funkcjonalność. Nie był to jednak jedyny problem eliminowany w takim wypadku. Także szybko malejące Zasoby Systemowe (w systemach z rodziny 9x, czyli 95, 98, 98 SE, ME), były oszczędzane dzięki zastosowaniu własnych kontrolek. Często taką praktykę stosowały także za plecami programistów same środowiska programistyczne zawierające mechanizmy przyspieszające projektowanie interfejsu (np. Delphi).

To co było jednak bardzo wygodne dla autorów oprogramowania stało się przekleństwem dla ludzi projektujących obsługę Wizualnych Stylów w nowych systemach Microsoftu. Gdyby Wizualne Style były automatycznie aplikowane wszystkim uruchamianym programom, w części ich można by było dostrzec dziwaczny problem. Otóż użyte w danej aplikacji kontrolki systemowe były by automatycznie zamieniane na ich odpowiedniki zawarte w danej 'skórce', jednak kontrolki tworzone przez autorów oprogramowania były by dalej 'ręcznie' rysowane i wyraźnie odróżniały by się od pozostałych. Wyobraźmy sobie już przytaczany przykład z suwakami. Można by było spotkać taką sytuację, iż powiedzmy w pewnym programie w miejsce suwaków których pozycja nie wnosi na bieżąco żadnych zmian używano by systemowych kontrolek, jednak w stosunku do suwaków które odpowiadają za znaczne zmiany w programie użyto by kontrolek specjalnie zaprojektowanych na potrzeby tego programu. W normalnych warunkach (czyli pod starszymi systemami, bądź przy wyłączonych Stylach Wizualnych) taki zabieg był by nie do odróżnienia, jednak po 'oskórowaniu' aplikacji był by bez trudu dostrzegalny. Aby zapobiec takim problemom Microsoft wpadł na ciekawe rozwiązanie. Otóż Wizualne Style (nie licząc przytaczanych już wcześniej obramowań okna) stosowane są tylko do tych programów, które 'wyraziły na to zgodę'. Te programy jednak, które zgody na to nie wyraziły pomimo włączonych Wizualnych Stylów używają klasycznego interfejsu, jednak z kolorystyką dostosowaną do wybranej 'skórki'. W ten sposób sztuczki używane przez programistów a także braki w kontrolkach systemowych nigdy nie wyszły by na światło dzienne.

W jaki jednak sposób dany program wyraża bądź nie wyraża zgody na użycie Wizualnych Stylów ? Wystarczy, że w specjalnej sekcji pliku exe danej aplikacji zwanej Sekcją Zasobów (nie ma to nic wspólnego z Zasobami Systemowymi, jedynie przypadkowe podobieństwo nazw) umieści się pewien plik, tzw. Plik Manifestu. Plik ten, to zwykły plik tekstowy, który w formacie XML przechowuje różne informacje interpretowane przez systemy Windows XP/2003. Jedną z takich informacji jest m.in. wymóg użycia pliku ComCtl32.dll w wersji 6.0, zawierającego kontrolki systemowe i umożliwiającego - w tej konkretnej wersji - użycie Wizualnych Stylów. Jeżeli jednak aplikacja nie zawiera Pliku Manifestu, to traktowana jest jako nie przystosowana do obsługi Wizualnych Stylów, dzięki czemu opisane wcześniej problemy związane z interfejsem nie występują m.in. w starszych aplikacjach.

Jeżeli jest to tak prosta operacja, to dlaczego nie zastosowałem jej w moich aplikacjach ? Sprawa jest dosyć złożona. Po pierwsze część programów została napisana przeze mnie na długo przed wydaniem systemu Windows XP, a ponieważ obecnie nie posiadam źródeł tychże aplikacji nie mogę ich ponownie skompilować dodając wymagany plik. Po drugie, teoretycznie Pliki Manifestu powinny mieć wpływ jedynie na aplikacje uruchamiane pod systemami Windows XP/2003. Okazuje się jednak, że pod starszymi systemami aplikacje zawierające je mogą sprawiać problemy, szczególnie kiedy plik exe został wewnętrznie skompresowany (co jest częstą praktyką) - wówczas np. niektóre programy antywirusowe błędnie oceniają wtedy, iż plik wykonywalny zawiera wirusa, co jest dosyć zaskakującym ale potwierdzonym faktem.

Tak więc wygląda na to, że wystarczyło by użyć edytora Zasobów plików wykonywalnych (jak np. Resource Hacker) i w odpowiedniej sekcji dodać Plik Manifestu aby wymusić obsługę Wizualnych Stylów we wszystkich pożądanych aplikacjach. Ponieważ jednak z punktu widzenia użytkownika nie jest to zbyt wygodny sposób, a poza tym niektóre pliki exe mają także skompresowaną wewnętrznie Sekcję Zasobów co uniemożliwia edycję jej zawartości, można użyć innej metody. Wystarczy, że pobierzesz ten plik, a następnie - po wypakowaniu - umieścisz go w katalogu zawierającym plik wykonywalny danej aplikacji. Dodatkowo wypakowanemu Plikowi Manifestu trzeba odpowiednio zmienić nazwę (z domyślnej: Program.exe.manifest). Nazwa tego pliku powinna mieć format: <nazwa pliku exe>.exe.manifest. Czyli np. gdy plik wykonywalny nosi nazwę Pirmidka.exe to Plik Manifestu winien nosić nazwę Piramidka.exe.manifest. Plik ten jest dosyć uniwersalny i nie należy się przejmować jego zawartością, pomimo iż zgodnie z wytycznymi Microsoftu ma on w odpowiednich miejscach zawierać nazwę producenta programu i jego opis, dane te nie są jednak obecnie wykorzystywane w żadnym znanym mi celu przez systemy Windows XP/2003.

I na koniec jeszcze tylko drobna uwaga. Zauważ, iż aplikacje pisane przeze mnie nie są nigdy testowane pod względem kompatybilności z Wizualnymi Stylami, stąd wyżej opisane operacje wykonujesz na własną odpowiedzialność.

Czas na kilka interesujących screenów wraz z opisem (kliknij aby powiększyć):

Główne okno a także dialog Konfiguracja (jak widać z wersji beta) programu MP3 Rename. Pierwszy screen to klasyczny wygląd przy typowym schemacie kolorystycznym - tak prezentuje się interfejs programu pod każdym systemem z serii Windows 95-2000 a także XP/2003 kiedy Wizualne Style są wyłączone. Drugi screen przedstawia te same okna, jednak przy włączonych Wizualnych Stylach. Jak widać, oskórowane zostaje jedynie ich obramowanie. I wreszcie trzeci screen, po raz kolejny prezentuje te same okna, jednak aplikacja została uruchomiona z aktywnymi Wizualnymi Stylami a także z obecnym Plikiem Manifestu. Jak widać wszystkie elementy interfejsu zostały oskórowane a mimo to wszystko posiada dokładnie taki sam rozmiar jak przedtem i proporcja między poszczególnymi kontrolkami zostaje zachowana.

Dialog wyboru zestawu kamieni pochodzący z gry Piramidka. Kolejność screenów pozostała taka jak poprzednio. Interesujące są dwie sprawy. Po pierwsze, jak już wspominałem, pomimo braku Pliku Manifestu włączenie Wizualnych Stylów powoduje nie tylko oskórowanie obramowania okna, ale także pasków przewijania. Druga sprawa, nawet przy obecnym Pliku Manifestu obramowanie grupujące kilka kontrolek nie zmienia wyglądu na charakterystyczny dla tej 'skórki' (proszę porównać z poprzednimi screenami). Wynika to z faktu, że Piramidka kompilowana była pod starszą wersją Delphi niż MP3 Rename, stąd niektóre kontrolki były 'po cichu' rysowane 'ręcznie' co nie dawało żadnej wyraźnej różnicy pod starszymi systemami pod które docelowo zaprojektowano tę wersję Delphi.

Ostatnia grupa screenów przedstawia główne okno Przypominacza. Jak widać screeny: drugi i trzeci są identyczne. Wynika to z faktu, że dla oszczędności Zasobów Systemowych (w końcu jest to aplikacja działająca przez cały czas w tle) użyłem kontrolek rysowanych 'ręcznie', stąd też nawet wymuszenie obsługi Wizualnych Stylów nie przynosi żadnych efektów. Podobnie zachowuje się także kilka innych aplikacji mojego autorstwa.

Specjalne podziękowania za wnikliwe testy różnych wersji Pliku Manifestu i dostarczenie screenów należą się Wojciechowi Czuszowi.

Życzę miłego upiększania moich programów :)
Wasz Aionel

 Powrót do: Artykuły