Hogyan készítsünk egy egyedi gombot a bitkép alapján?
A gombnak nem kell szabványos megjelenése (bár személyesen nem találom a normál gomb megnyomását vagy "egyszerű" megjelenését). Sok fejlesztőnek és felhasználónak azonban vonzóbbnak tűnik a nem szabványos megjelenésű gombok. Ezért, hogy stílusát adja meg saját programjainak felületéhez, olyan gombokat használhat, amelyek bitképet (bitképet) mutatnak.
A Windows beépített mechanizmusokkal és API-kkal rendelkezik, amelyek támogatják a nem szabványos megjelenésű gombok (és egyéb vezérlők) létrehozását. A vezérlés megjelenésének módja a stílustól függ. Ebben az esetben a stílus, amire szükségünk van, BS_OWNERDRAW. A nevéből látható, hogy a gomb típusának megjelenése végrehajtja a vezérlő ablak-tulajdonosának ablak (párbeszéd) funkciójába helyezett felhasználói kódot.
Nézzük az xx_OWNERDRAW stílus vezérlésének alapvető lépéseit.
- Az üzenet szülőablakja WM_MEASUREITEM. amelyben a MEASUREITEMSTRUCT struktúra mutatója áthalad az lParam paraméteren. Az üzenetkezelőnek meg kell határoznia a szerkezet ItemWidth és ItemHeight mezőit úgy, hogy azok tartalmazzák a vezérlő szélességét és magasságát. Ha feldolgoztuk az üzenetet, a kezelőnek vissza kell térnie a TRUE-ból az ablak eljárásából. Ez az üzenet egyszer a tulajdonoshoz jön, amikor létrehozza a vezérlést.
- Minden alkalommal, ha szükséges, átírja a vezérlőt tulajdonosára a WM_DRAWITEM üzenetet kapja. Az üzenet lParam paramétere egy mutatót tartalmaz a DRAWITEMSTRUCT struktúrához. amelyet a rendszer készít. Ennek az üzenetnek az a feladata, hogy biztosítsa azt a kontextust, amelyben a vezérlés megjelenik. A kontextus fogantyúja további információkat tartalmaz a kontroll belső állapotáról, amely szükséges (valószínűleg) a megjelenés megváltoztatásához, valamint a vezérléssel jelenleg végrehajtott művelet típusával kapcsolatos információk. Ezután megnézzük, hogyan használhatók ezek az információk a gomb megjelenésének megváltoztatására. Továbbá, ha feldolgozzuk ezt az üzenetet, a kezelőnek vissza kell térnie az IGEN az ablakból.
Amint rájövünk, bár egymástól függetlenül is felhívni, de még mindig a gombot, akkor jó lenne, ha ez a viselkedés hagyományos gombok - él a normál állapotban kell szimulálni egy konvex ellenőrzést, amikor depressziós - depressziós, közben fókusz gombot kell lennie képzelni létrehozott négyszög a szaggatott vonal és az inaktív gombot meg élesen eltérő a színe (akár a háttérben, vagy betűk, vagy mindkettő, hogy a másik).
Könnyű látni, hogy ha szeretné teljes mértékben végrehajtani a gomb normál viselkedését, akkor elég nagy raszterképet kell készítenie:- konvex fókusz és gyorsító nélkül
- Konvex, fókusz nélkül gyorsító
- konvex a gázpedál nélkül
- Konvex fókusz és gyorsítóval
- fókusz és gyorsító nélkül
- Gyújtó nélkül fókuszálva
- lenyomva a gázpedál nélkül
- A fókusz és a gázpedál hatása
- tétlen
Ön, mint fejlesztő, jogában áll eldönteni, hogy pontosan hogyan fogod követni ezt a technikát (például a demo alkalmazásban egy gyorsítóeszköz nélküli opciónál megállt :)).
Kielégítik ezeket a feltételeket, tudunk készíteni öt bitmap (domború / mélyített a hangsúly / fókusz nélkül, inaktív), a végrehajtási megjelenése az egyes államok a gombot, és felhívni a megfelelő időben (ez az, ahol szükség van tudni, hogy a jelenlegi állapotában a gomb) egyikük. Ebben az esetben mi magunk teljes mértékben szabályozzuk a gomb megjelenését minden egyes államban. A felhasználó által tapasztalt benyomás teljesen az ízlésedtől és a raszterképek létrehozásától függ.
Ami a szükséges működési logikát végrehajtó kódot illeti, ez úgy néz ki, mint ez:
Mint látható, semmi bonyolult. A kód két részből áll: az első információk alapján a végzett tevékenység (itemAction) és a jelenlegi állapotában a gomb (itemState) kiválasztja a kívánt bitmap, a második részben zajlik a termelés a kiválasztott bitmap gombok összefüggésben.
A fenti kód korábbi verziója a következő részletet tartalmazta a DrawState () felhívása helyett.
Véleményem szerint mindkét opció megegyezik a funkcionalitással, de a BitBlt () töredékében még több lehetőség van hibahelyre, ami forrásszivárgáshoz vezet.
A kódot a szükséges ellenőrzési azonosító ellenőrzésével határozták meg, mivel számos ilyen ellenőrzés létezik a munkaprogramban.
A figyelmes olvasó kész feltenni egy kérdést arról, hogy a legelején, nem csak említett mechanizmusok (végre, ahogy felfedezték, a WM_MEASUREITEM üzenetét és WM_DRAWITEM), de az API?
Valóban, számos jellemzői, amelyek megkönnyítik kapcsolódási szabványos formában OWNERDRAW-kontroll. Fejlesztő előkészíti a fő bitmap a gomb, és felhívni a határokat, és gomb állapotok (inaktív és életlen) függvényeket használja WinAPI - DrawEdge () (határellenőrzés - a „domború / depressziós”), DrawState () (állapot „aktív / inaktív”) és a DrawFocusRect () (a "fókusz" állapot). Ebben az esetben a fenti kód úgy fog kinézni:
Az ilyen megközelítés nyeresége az önállóan előkészített erőforrások kevesebb felhasználása és a program működésének kevesebb fogyasztása. A hátrányok (és nagyon észrevehető, véleményem szerint) az, hogy a gomb különböző megjelenési formáiban a gomb megjelenésének hiánya van. Azonban ezeknek a funkcióknak a munkája az ellenőrzések standard megjelenésének megőrzésére irányul, így az eredmény nem túl kifejező. Véleményem szerint ez a technika jobban megfelel azoknak a gomboknak a megvalósításához, amelyek alapvetően egy szabványos megjelenésűek, de apró képek vannak a gomb szövegének szomszédságában.
Meg kell jegyezni, hogy ha szükséges, akkor lehet (és néha szükséges) kombinációját használni a fenti módszerek, tegyük fel, hogy használja, hogy felhívja a négy (vagy több), a bitmap, hanem felhívni a határ DrawEdge () függvényt.