Mint arról az előző részben szó volt, a Windows már alapból rendelkezik jónéhány, az adatbevitelt ill. a felhasználóval történő kommunikációt elősegítő vezérlőelemmel, amelyeket azonban a programozó saját vezérlőelemek definiálásával is szabadon bővíthet. De végső soron hogyan is épülnek fel és működtethetők ezek a vezérlőelemek? Hogyan manipulálják az alkalmazások az azokban megjelenő információkat, és miként kérdezhetik le a felhasználói bevitel eredményeként előálló adatokat?

A megelőző részekben megtudtuk, hogy a vezérlőelemek önmaguk is (gyerek)ablakok v. azok egymáshoz kapcsolt halmazai, amelyek így az ablakkezelő függvények segítségével manipulálhatók, és amelyek részére üzenetek küldhetők. Az ablakkezelő függvények és a standard ablaküzenetek - amelyek pl. a beviteli fókusz változásáról, vagy a szülőablak átméretezéséről tájékoztatnak - azonban nyilvánvalóan csak a vezérlőelemek közös jellemzőinek (pl. kiterjedés, láthatóság) manipulálására ill. a rendszer koherens működését biztosító alapvető viselkedési mintázatok kialakítására alkalmasak, és nem nyújtanak lehetőséget a vezérlőelemek eltérő funkciójából adódó ill. ahhoz kapcsolódó adattartalmak lekérdezésére és módosítására, valamint egyedi állapotváltozások közlésére.
Ezek okból kifolyólag a vezérlőelemekkel kapcsolatban csakis olyan vezérlési struktúrák és interfészek kialakítása képzelhető el, amelyek valahol az elemi ablakkezelő függvényeket és műveleteket "hasznosítják újra" egy magasabb szintű funkcionális réteg megvalósításához és működtetéséhez.

Adattárolás

A vezérlőknek működésük során funkciójuktól függően különböző jellegű információkat fogadnak, dolgoznak  fel és továbbítanak. Ráadásul bár az adatok egy része a rendszer szintjén globális adat (pl. a megjelenítéshez használandó színek), túlnyomó részük azonban szigorúan lokális, a vezérlőelem-példányhoz kapcsolódó egyedi információ (pl. egy beviteli mezőbe írt szöveg). Az ilyen jellegű információk tárolásáról és kezeléséről maguknak az egyes vezérlő-példányoknak kell gondoskodniuk, mégpedig a Windows által részükre bocsátott, egyes ablak-példányokhoz kapcsolódó információk tárolását és visszaolvasását lehetővé tevő függvényekkel.

Ablakadatok

Az adatok tárolásának legtriviálisabb módja azok szekvenciális tárolása egyetlen összefüggő memóriaterületen. E megoldás alkalmazását a Windows az ún. extra ablakadatok (extra window data) használatának lehetőségével támogatja. A megoldás lényege, hogy a kontroll-típus - azaz az ablakosztály - regisztrálásakor egy minden egyes kontroll-példány  létrehozásakor automatikusan lefoglalásra és társításra kerülő plussz terület méretének megadására is lehetőséget biztosít. Az ilyen módon kialakított adatterületet a kontroll teljesen saját céljaira használhatnak fel, de annak tartalmát rajta kívül is bárki (pl. az alkalmazói program) írhatja és olvashatja a kontroll ablak-azonosítójának ismeretében. Ez utóbbi tulajdonságnak nyilván csakis abban az esetben van jelentősége, ha a külső adatmanipulátor tisztában van a tárolt adatok szerkezetével és jelentésével, hiszen egyéb esetben nem sokra megy bájtok halmazával.
Az extra ablakadatok alkalmazásának hátránya, hogy a vezérlőelemnek a kapcsolódó adatok tárolásához felhasználni kívánt terület méretét már az ablak-osztály regisztrálásakor előre meg kell határoznia, tehát az sem példányok között nem változhat, sem az egyes vezérlők aktuális állapotától vagy már körülményektől nem tehető függévő, ami sokszor igen kényelmetlen megszorítás lehet, és erősen leszűkíti az alkalmazási lehetőségek körét.

Ablak-jellemzők

A felsorolt hátrányok kiküszöbölésére a Windows lehetővé teszi egymástól független, futás közben dinamikusan létrehozható és eltávolítható társított adatok, ún. ablak-jellemzők (window properties) alkalmazását is. Az ablakjellemzők egyedi karakterlánccal azonosított 32-bites értékek, amelyek az ablak életciklusa alatt szabadon hozhatók létre, módosíthatók és törölhetőek. Egy konkrét ablakjellemző aktuális értékének lekérdezése mellett lehetőség van az összes éppen definiált ablakjellemző felsoroltatására (enumeráltatás) is.
Az ablakjellemző kis méretéből (32-bit) adódóan nem alkalmas nagy mennyiségű adat közvetlen befogadására, viszont éppen elég egy pointer értékének eltárolásához. Így bár közvetve, de alkalmas lehet viszonylag nagy méretű kapcsolt adatterületek társítására is, amelyek esetében azonban a tényleges tárolóterület lefoglalásáról, és főleg annak az ablak megsemmisítése előtti felszabadításáról az ablakjellemző használójának kell gondoskodnia.
Kommunikáció a vezérlőkkel

Közvetlen adatmanipuláció

Bár a vezérlőelemekkel történő kommunikáció legtriviálisabb módjának első látásra az előbbiekben megismert, társított adatterületeken keresztül történő kommunikáció tűnik, valójában ez a megoldás számos hátránnyal rendelkezik. Ezen hátrányok egyike, hogy közvetlen hozzáférést enged a kontroll saját adatterületeihez, ami ellentmond a modularitás és az objektum-alapú fejlesztés adatrejtés néven ismert alapelveinek. Ez az elv szerint a rendszert alkotó részelemek megalkotásánál törekedni kell a funkcionalitás és az implementáció részleteinek minél élesebb szétválasztásától olyan módon, hogy a komponens felhasználója csakis a funkcionalitással közvetlenül kapcsolatban álló adatokat tudja manipulálni - és azokat is csak ellenőrzőtt módon, tehát nem közvetlen hozzáféréssel, hanem eljárásokon ill. függvényeken keresztül, amelyek az érvénytelen paramétereket kiszűrhetik - , míg az implementáció igazi részletei rejtve maradjanak előtte.
A megoldás másik hátránya szorosan öszefügg az elsővel. A funkcionalitás bővítése, módosítása legtöbbször a belső adatstruktúrák bővítésével/módósításával jár együtt. Amennyiben az alkalmazások közvetlenül férnek hozzá a belső adatstruktúrákhoz, úgy azok a kontroll részéről nyilvánvalóan nem módosíthatók egyoldalúan a kompatibilitás veszélyeztetése nélkül, hanem csakis a vezérlőelem és az alkalmazás párhuzamos módosítása esetén őrizheti meg a rendszer működőképességét. Ez a gyakorlatban azt jelentené, hogy a vezérlőelemek megjelenését és viselkedését csakis  a. Ez egy folyamatosan fejlesztés alatt rendszer esetében, amelynek egyes részeit más-más cégek szolgáltatják elképzelhetetlen.

Ezen okokból kifolyólag ez a módszer nem alkalmas olyan vezérlőelemek működtetésére, amelyek implementációja és felhasználói egymástól független modulokban helyezkednek el, és amelyek esetén így a verzió-szinkronitás nem garantálható és/vagy erős korlátozó tényező lenne. Ugyanakkor minden további nélkül alkalmazható olyan esetekben, ahol a vezérlőelemet maga az azt felhasználó alkalmazás implemetálja és azt nem kívánja más alkalmazások és független modulok részére elérhetővé tenni.

A megoldás harmadik hátránya az, hogy a közösen manipulált adatterületek változásairól a felek nem tudják közvetlenül értesíteni egymást, hanem mindegyikük csakis az előző tartalommal történő periodikus összehasonlítás újtán döntheti el, hogy történt -e változás az adatterület legutóbbi átvizsgálása óta, vagy sem, és cselekedhetnek a kapott paramétereknek megfelelően.

Vezérlőüzenetek

A vezérlőelemekkel történő kommunikáció egy másik lehetséges, és egyben a standard vezérlőelemek által is alkalmazott módja az ablakok üzenet-feldolgozó eljárásának, azaz ablakeljárásának (window procedure) a kibővítése olyan módon, hogy az bizonyos előre meghatározott üzenetkódok hatására a vezérlőelem beállításait, viselkedését módosítsa a kapott paramétereknek megfelelően ill. hogy annak állapotáról meghatározott információkat szolgáltasson.
Természetesen az üzenetkódok által hordozott információ mérete véges (sőt, direkt korlátos), azonban az üzenethez kapcsolódó két 32-bites egész megadásának lehetőségét kihasználva már akár 64 bitnyi információ is átvihető a kontroll felé. A kontroll maga az üzenetekre válaszul pedig a 32-bites eredménykód (result code) részére fenntartott mezőben juttathat vissza adatokat az alkalmazás részére.

Természetesen elképzelhető olyan eset is, amikor ez az kapacitás nem elegendő az átvivendő  adatok tárolására, hanem ennél jóval nagyobb adatcsere területre lenne szükség. Ebben az esetben a megoldást egy mind az alkalmazás, mind a vezérlőelem részéről ismert formátumú pufferterület alkalmazása jelentheti, amelynek azonban nem tartalma, hanem csakis kezdőcíme kerül az üzenet paramétereként átvitelre (ehhez elég az egyik 32-bites egész). A pufferterületet mindig az alkalmazás maga biztosítja, és a vezérlőelem az ott szereplő paramétereket az üzenet feldolgozása során saját belső pufferterületeire másolja, ill. lekérdezések során oda gyűjti össze saját belső struktúráiból a megfelelő adatokat.

Ebben az esetben a felhasználó alkalmazások a vezérlő belső adatstruktúráihoz nem közvetlenül férnek hozzá, hanem egy független interfészen keresztül kommunikálnak egymással. Ez az architektúra lehetővé teszi a vezérlőelem belső működésének, implementációjának megváltoztatását a felhasználó alkalmazás legcsekélyebb módosításának szükségessége nélkül, egészen addíg, amíg a vezérlőelem az adott interfészt továbbra is támogatja. Más üzenetkódok alkalmazásával természetesen ezzel párhuzamosan akár egy teljesen új interfész támogatására is lehetőség nyílik, amivel bővített funkcióit az azt már ismerő alkalmazások részére bocsáthatja. Ezzel a módszerrel eléhető, hogy ugyanannak a vezérlőelemnek akár teljesen eltérő változatait ismerő/elváró felhasználói programok is sikeresen futtathatók párhuzamosan ugyanabban a rendszerben.

Természetesen az üzenetek segítségével nem csak az alkalmazás befolyásolhatja a vezérlőelem működését, vagy kérdezhet le adatokat attól, hanem szükség esetén maga a vezérlőelem is küldhet értesítéseket ill. röpte-jellegű (on-the-fly) információk utáni kéréseket az alkalmazás felé.
E megoldás alkalmazásával tehát eseményalapú programozás valósítható meg, amelyben nincs szükség a közösen manipulálható adatterületek periodikus, változások utáni átkutatására (pollozás), hanem amelyben a rendszer elemei a paraméterek változásáról, vagy éppen bizonyos adatok utáni igényükről kölcsönösen értesíthetik egymást, ami a haszontalan feldolgozási időt (overhead) minimálisra csökkenti.