egy új generációs grafikus GDI
grafikus objektumok
Megjelenítéséhez primitívek megköveteli, hogy bizonyos beállítások: A szín és a vonal vastagsága ( „toll”), hogy milyen típusú színkitöltéssel ( „hands”), a betűméret és stílus, és így tovább. Jellemzően a különböző grafikai szoftver interfészek tárolt beállítások, például saját adatstruktúrák - grafikus objektumok. Ez igaz GDI és a GDI + azonban különböző tárgyakat. Tekintsük ezek a különbségek a példa egy kis feladat - felhívni a téren.
Állapottartó modell GDI
A GDI programozza modell, az úgynevezett állapot-nyilvántartó modell szerint. Ez azt jelenti, hogy a kimeneti eszköz beállításokat tárolja és elérhetővé tette a koncepció a jelenleg kijelölt objektumot. Kiadása előtt a kívánt grafikus objektum primitívek kell választania a kimeneti eszköz (a SelectObject funkció). Miután így létrehozott, például a vonal szélessége 3 képpont, akkor tudjuk levezetni több szegmens választott vastagsága:
Ennek a megközelítésnek az előnye - miután beállította a kiválasztott toll (HPEN), nem szükséges minden alkalommal, hogy továbbítja azt a kimeneti függvény. Ugyanakkor az egyszerűség nagyon gyakran fordult komoly probléma - a hírhedt erőforrás szivárgás.
Vessen egy pillantást a kiemelt sor. Miért volt szükség megjegyezni és helyreállítani keretében egy régi tollat, ha még nem használt rajz? A lényeg az, hogy összefüggésben a kiválasztott grafikus objektum nem lehet eltávolítani - annyira építészeti került kiválasztásra létrehozásakor GDI. Így anélkül, hogy ez a vonal a hívás sikertelen lesz DeleteObject, és a toll jön létre „lóg” a GDI Heap. Mivel WM_PAINT üzenet ablak jön elég gyakran, a rendszer a Windows 9x (ahol a GDI kupac mérete legfeljebb 64 KB), akkor gyorsan vezet kimerültség grafikai források rendszerének. Ezt követően, az összes program úgy fog viselkedni, nagyon furcsa nem dolgozza át egyes menüpontok és ikonok, rajzoljon szöveget gyanús betűtípusok stb A rendszer NT platform lesz, hogy „a felszínen maradni” egy kicsit hosszabb, mert a grafika kupac nőhet szükség szerint, de van egy határ, hogy hány egyidejűleg keletkezett a folyamat grafikus objektumok - 12 ezer.
A másik probléma az, hogy a C ++ - programozók hozzászokott az automatikus tisztítási a felhasznált források felhasználásával osztályok destruktorok és „intelligens mutató”. Ez könnyű elfelejteni valami kifejezetten feleslegessé. Mindazonáltal a jelenlegi könyvtár-wrapper osztályok GDI nem tudja megoldani a problémát, a programozó, hogy törölje a kiválasztott objektum kontextusában. Az is, hogy szivárgás GDI-források.
Hontalan modell GDI +
A megkülönböztető jegye a programozó, hogy módosítsa a GDI + programozási modell dolgozni a kimeneti eszköz. A koncepció a készülék éppen kiválasztott grafikus objektum kiadja a nem hatékony és elavult. Ahelyett, hogy egy koherens összefüggésben paraméterek (Graphics) használják ezeket a tulajdonságokat minden hívás a grafikus módszer. kimeneti eszköz, mivel nem rendelkezik azzal a feltétellel, és megkapja a szükséges információkat a paramétereket. Egy ilyen modell az úgynevezett hontalan modell szerint.
Természetesen ez a besorolás önkényes. Vannak még paramétereket (pl, a jelenlegi anti-aliasing beállítások a kiválasztott koordináta-rendszer, stb), amely tárolja a Graphics osztály és a hozzá kapcsolódó szerkezetek. De az állam primitívek GDI + nem tárolja keretében a kijelzőn.
Most, mindegyik eljárást megjelenítéséhez használt grafikus objektum paraméterként kifejezett, az jelzi az objektum:
Paraméter segítségével callbackData, akkor például, hogy át metaCallback eljárás (verzió C ++) mutatót a metafile rekord, amely felsorolja megadva. Aztán, hogy végre grafikus parancsokat használja a módszert Metafile :: PlayRecord:
Paraméter RecordType minden hívás visszahívást eljárás értékét veszi a felsorolás EmfPlusRecordType. Már tartalmazó tag 253 (a legnagyobb átviteli GDI +). Ezek az elemek a közvetlenül megfelelnek az utasítások GDI / GDI +, vagy olvassa el a hivatalos feljegyzések a metafile. Ha telefonál PlayRecord helyettesítheti ezt a beállítást az értékeiket, hogy végre egy teljesen más csapat GDI + eljárás PlayRecord. De ehhez szükséges alapos ismerete a megfelelő paramétereket nem dokumentált recordData és dataSize (és továbbítására, illetve megváltozott értékek őket).
Átigazolási rekordok: a különlegességre .NET
A dokumentáció WinForms azt jelzi, hogy a .NET környezet biztosítja a saját verzióját egy küldött, hogy végre megfelelő parancsokat metafile a szervezetben a visszahívás-kezelő. Ez a változat jut el a felvezető callbackData paramétert. A parancs végrehajtásához elegendő ahhoz, hogy a kapott megbízottja (pl másolt a dokumentációt):
Figyelem! Ez egy nyilvánvaló hiba .NET Framework dokumentáció (ó, a sokadik alkalommal!) Ez a példa összeállításának, de a megvalósítása, hogy semmi jó nem. Ugyanezt mondta a könyv Petzold [3].
A kísérletek azt mutatták, hogy a paraméter callbackData nulla értéket mindig továbbítják, függetlenül attól, hogy a fázisok a hold. Ezt „delegált” teljes kivétel NullReferenceException.
Mégis, hogy hozzon létre egy működő verziója az adott alkalmazásnak EnumerateMetafile eljárás .NET nagyon is lehetséges. Ehhez mi kell bütykölni egy kicsit a módszer Metafile.PlayRecord. Az a tény, hogy ő, mint egy adat paraméter vesz egy sor bájt:
Igen, annak érdekében, hogy a dédelgetett cél (válogatás rekordok az metafile WinForms) volt némi tennivaló. De ezeket a nehézségeket messze meghaladta a többi .NET méltó minőséget - reflexió. Bármilyen átadóelem (akár egy óriás, mint EmfPlusRecordType) «tudja” karakterlánc nevét, amely megkönnyíti, hogy hozzon létre egy verziója az adott alkalmazásnak, amely felsorolja a kiválasztott metafile rekordokat név szerint. Itt egy részlet demo:
Egyszerű, nem? A toString eljárás egy karakterlánccal tér vissza felsorolja az elem nevét, enyhíti a programozó az unalmas kódoló 253 sztring konstansok. Itt az eredménye ennek a módszernek:
Teljes szövege a mellékletben (amely lehetővé teszi Metafile csapat a felhasználó által kiválasztott kizárólag) a CD-ROM-ról a magazin. Ez is egy lefordított változat, hogy lehet használni, hogy vizsgálja meg a tartalmát különböző metafile (például szerepel a Microsoft Visual Studio csomag):
Sok szerencsét a kutatás!