Elemente de Grafică

Programarea în Windows
Home / My courses / PWINDOWS / Capitolul 4. Noţiuni elementare de grafică / Elemente de grafică
Elemente de grafică
Filozofia GDI
În versiunile pe 32 de biţi ale sistemului de operare Windows elementele grafice sunt manipulate, în principal, prin funcţii exportate din biblioteca
cu legături dinamice GDI32.DLL, care, la rândul ei, foloseşte biblioteca cu legături dinamice pe 16 biţi GDI.EXE. (În versiunile Windows anterioare,
bibliotecile cu legături dinamice erau fişiere cu extensia .EXE, nu .DLL.) Aceste module apelează proceduri din diferite fişiere driver pentru afişare -
un fişier .DRV pentru afişarea pe ecran şi, probabil, unul sau mai multe fişiere .DRV care controlează imprimantele şi plotterele. Driverele execută
operaţiile de acces la componentele hardware ale monitorului video sau convertesc comenzile GDI în coduri sau comenzi pe care le pot interpreta
diferite tipuri de imprimante. Pentru diferite tipuri de plăci video sau de imprimante este nevoie, desigur, de diferite fişiere driver.
Deoarece la calculatoarele compatibile PC pot fi ataşate diferite dispozitive de afişare, unul dintre scopurile principale ale interfeţei GDI este să
permită manipularea elementelor grafice independent de dispozitiv. Programele scrise pentru Windows ar trebui să ruleze fără probleme, indiferent
de dispozitivul grafic de afişare folosit, dacă acesta este acceptat de sistemul de operare. Interfaţa GDI realizează acest lucru prin furnizarea unor
componente care izolează programele de caracteristicile particulare ale diferitelor dispozitive de ieşire.
Lumea dispozitivelor grafice de ieşire este împărţită în două categorii: dispozitive rastru şi dispozitive vectoriale. Majoritatea dispozitivelor de ieşire
pentru PC sunt dispozitive rastru, ceea ce înseamnă că reprezentarea imaginilor se face prin matrice de puncte. Această categorie include plăcile
video, imprimantele matriceale şi imprimantele laser. Dispozitivele vectoriale, care desenează imaginile prin linii, sunt, în general, limitate la
plottere.
Majoritatea limbajelor de programare cu posibilităţi grafice tradiţionale se bazează în exclusivitate pe vectori. Aceasta înseamnă că un program care
foloseşte unul dintre aceste limbaje grafice este despărţit de componentele hardware printr-un nivel de abstractizare. Dispozitivul de ieşire
foloseşte pixeli pentru reprezentarea elementelor grafice, dar programul nu comunică deloc cu interfaţa în limbajul pixelilor. Deşi puteţi să folosiţi
interfaţa Windows GDI ca sistem de desenare vectorială la nivel înalt, puteţi să folosiţi aceeaşi interfaţa şi pentru manipularea la nivel scăzut a
pixelilor.
Din acest punct de vedere, interfaţa Windows GDI este pentru limbajele grafice de interfaţa tradiţionale ceea ce este C pentru alte limbaje de
programare. Limbajul C e bine cunoscut pentru gradul înalt de portabilitate între diferite medii şi sisteme de operare. Dar, în acelaşi timp, limbajul C
e cunoscut şi pentru faptul că permite efectuarea unor operaţii de nivel scăzut, care în alte limbaje de nivel înalt sunt, deseori, imposibile. Aşa cum
C este numit uneori „limbaj de asamblare de nivel înalt", puteţi să consideraţi că GDI este o interfaţă de nivel înalt către componentele hardware ale
dispozitivelor grafice.
Aşa cum aţi văzut, în mod prestabilit, Windows foloseşte un sistem de coordonate bazat pe pixeli. Majoritatea limbajelor grafice tradiţionale
folosesc un sistem de coordonate „virtual", cu o axă verticală şi una orizontală care merg, de exemplu, de la 0 la 32 767. Deşi unele limbaje grafice
nu vă permit să folosiţi coordonate în pixeli, interfaţă GDI vă lasă să lucraţi în oricare dintre cele două sisteme de coordonate (şi chiar într-un alt
sistem, bazat pe dimensiunile fizice). Puteţi să folosiţi un sistem de coordonate virtual şi să izolaţi astfel programul de componentele hardware, sau
să folosiţi sistemul de coordonate al dispozitivului şi să scrieţi programul direct pentru componentele hardware utilizate.
Unii programatori consideră că în momentul în care începeţi să gândiţi programul în pixeli aţi renunţat la independenţa de dispozitiv. Aţi văzut deja
în Capitolul 3 că acest lucru nu este întotdeauna adevărat. Secretul constă în utilizarea pixelilor într-o manieră independentă de dispozitiv. Pentru
aceasta este necesar ca limbajul grafic să furnizeze programului posibilitatea de determinare a caracteristicilor hardware ale dispozitivului de ieşire,
astfel încât să poată face modificările corespunzătoare. De exemplu, în programele SYSMETS am folosit dimensiunile în pixeli ale unui caracter din
fontul sistem standard, ca să stabilim spaţiile pentru textul de pe ecran. Această metodă permite programului să se adapteze la plăci video cu
diferite rezoluţii, dimensiuni ale textului şi rate de afişare, în acest capitol veţi vedea şi alte metode de determinare a dimensiunilor ecranului.
La început, mulţi utilizatori foloseau sistemul de operare Windows pe un monitor monocrom. Pană nu demult, utilizatorii calculatoarelor portabile
(laptop) nu aveau la dispoziţie decât diferite tonuri de gri. Chiar şi astăzi monitoarele video folosite pentru Windows 95 au posibilităţi diferite de
afişare a culorilor (16 culori, 256 de culori sau „full-color") şi mulţi utilizatori folosesc imprimante alb-negru. Este posibil să folosiţi aceste dispozitive
„orbeşte", dar programul are şi posibilitatea să determine numărul culorilor disponibile pentru un anumit dispozitiv de afişare şi să folosească toate
avantajele oferite de componentele hardware.
Desigur, aşa cum este posibil să scrieţi programe C care au probleme ascunse de portabilitate atunci când sunt rulate pe alte calculatoare, este
posibil să se strecoare în programele Windows şi anumite probleme neprevăzute, legate de dependenţa de dispozitiv. Acesta e preţul plătit pentru
izolarea incompletă de componentele hardware. Vom studia în acest capitol capcanele dependenţei de dispozitiv.
De asemenea, trebuie să ştiţi că interfaţă Windows GDI îşi are limitele ei. Cel puţin în acest moment, interfaţă GDI nu poate să facă tot ce v-aţi
putea dori de la o interfaţă grafică. Deşi puteţi să mutaţi pe ecran obiecte grafice, GDI este, în general, un sistem de afişare static, ce permite numai
animaţii limitate. Aşa cum este implementată în Windows 95, interfaţă GDI nu asigură un suport direct pentru afişarea tridimensională sau pentru
rotirea obiectelor. De exemplu, atunci când desenaţi o elipsă, axele acesteia trebuie să fie paralele cu axele sistemului de coordonate. Deşi unele
limbaje grafice folosesc numere în virgulă mobilă pentru coordonatele virtuale, Windows 95 - din motive legate de performanţă - foloseşte numai
numere întregi pe 16 biţi aceasta este una dintre deficienţele sistemului de operare Windows 95. Windows NT permite folosirea coordonatelor pe
32 de biţi.
Structura interfeţei GDI

Din punctul de vedere al programatorului, interfaţa GDI este formată din câteva sute de apeluri de funcţii şi unele tipuri de date, macroinstrucţiuni
şi structuri asociate acestor funcţii. Înainte de a studia în detaliu câteva dintre aceste funcţii, haideţi să vedem care este structura generală a
interfeţei GDI.
Tipuri de apeluri de funcţii

În general, apelurile de funcţii GDI pot fi clasificate în mai multe categorii. Chiar dacă nu sunt foarte stricte şi există unele suprapuneri, aceste
categorii pot fi enunţate astfel:
· Funcţii care obţin (sau creează) şi eliberează (sau distrug) un context de dispozitiv. Aşa cum am văzut în Capitolul 3, pentru a desena aveţi
nevoie de un context de dispozitiv. Funcţiile GetDC şi ReleaseDC vă permit să faceţi aceste lucruri în timpul prelucrării altor mesaje decât
WM_PAINT, pe când funcţiile BeginPaint şi EndPaint (deşi din punct de vedere tehnic fac parte din subsistemul USER din Windows) sunt folosite în
timpul prelucrării mesajului WM_PAINT. Vom discuta în curând despre alte funcţii legate de contextul de dispozitiv.
· Funcţii care obţin informaţii despre contextul de dispozitiv. În programele SYSMETS, cu care aţi făcut cunoştinţă în Capitolul 3, am folosit
funcţia GetTextMetrics ca să obţinem informaţii despre dimensiunile fontului selectat în contextul de dispozitiv. Mai târziu în acest capitol vom
prezenta programul DEVCAPS1, pentru a obţine informaţii generale despre contextul de dispozitiv.
· Funcţii care desenează ceva. Evident, după rezolvarea problemelor preliminare, acestea sunt funcţiile cu adevărat importante. În Capitolul 3 am
folosit funcţia TextOut pentru afişarea textului în zona client a ferestrei. Aşa cum vom vedea, alte funcţii GDI sunt folosite pentru desenarea liniilor, a
zonelor colorate şi a imaginilor de tip bitmap.
· Funcţii care stabilesc sau obţin atribute ale contextului de dispozitiv. Un „atribut" al contextului de dispozitiv specifică modul de lucru al
funcţiilor de desenare. De exemplu, folosiţi funcţia SetTextColor ca să precizaţi culoarea textului afişat cu funcţia TextOut (sau cu o altă funcţie de
afişare a textului). În programele SYSMETS din Capitolul 3 am folosit funcţia SetTextAlign ca să arătăm interfeţei GDI faptul că poziţia de început a
şirului de caractere este în partea dreaptă a şirului de caractere, nu în partea stângă, aşa cum se întâmplă de obicei. Toate atributele contextului de
dispozitiv au valori prestabilite, care devin active la obţinerea contextului de dispozitiv. Pentru fiecare funcţie de tip Set există şi o funcţie Get
corespondentă, folosită pentru obţinerea valorilor curente ale atributelor contextului de dispozitiv.
· Funcţii care lucrează cu obiecte GDI. Aici este punctul în care lucrurile se încurcă puţin în interfaţa GDI. Mai întâi vom da un exemplu: în mod
prestabilit, toate liniile pe care le desenaţi folosind interfaţa GDI sunt continue şi au o grosime standard. Ce se întâmplă, însă, dacă doriţi să
desenaţi o linie mai groasă sau o linie punctată ori întreruptă? Grosimea şi stilul liniei nu sunt atribute ale contextului de dispozitiv. Acestea sunt
caracteristici ale „peniţei logice" („logical pen"). Puteţi să indicaţi o peniţă logică prin specificarea acestor caracteristici în funcţiile CreatePen,
CreatePenIndirect şi ExtCreatePen. Funcţiile de mai sus returnează o variabilă handle a peniţei logice create. (Deşi se consideră că aceste funcţii fac
parte din interfaţa GDI, spre deosebire de majoritatea celorlalte funcţii acestea nu au nevoie, ca parametru, de o variabilă handle a contextului de
dispozitiv.) Pentru folosirea peniţei selectaţi variabila handle a acesteia în contextul de dispozitiv. Din acest moment, orice linie va fi desenată cu
peniţa selectată. Ulterior, deselectaţi obiectul peniţă din contextul de dispozitiv şi distrugeţi-l. În afara peniţelor, puteţi să folosiţi obiecte GDI pentru
crearea pensulelor care colorează o suprafaţă închisă, pentru fonturi, pentru imagini bitmap şi pentru alte aspecte ale interfeţei GDI, despre care
vom discuta în acest capitol.
Primitive GDI
Elementele grafice pe care le afişaţi pe ecran sau le tipăriţi la imprimantă pot fi împărţite în mai multe categorii, numite „primitive". Iată care sunt
aceste categorii:
· Linii şi curbe. Liniile reprezintă baza oricărui sistem de desenare vectorial. GDI permite folosirea liniilor drepte, a dreptunghiurilor, a elipselor
(inclusiv subsetul de elipse cunoscute sub numele de cercuri), a arcelor - care sunt curbe reprezentând porţiuni din circumferinţa unei elipse sau a
curbelor Bezier. Despre toate aceste clemente vom mai discuta în capitolul de faţă. Orice curbă mai complexă poate fi desenată ca o linie
poligonală, adică o serie de linii foarte scurte care definesc o curbă. Liniile sunt desenate folosind peniţa curentă selectată în contextul de dispozitiv.
· Suprafeţe pline. Dacă o serie de linii sau de curbe închid o suprafaţă, aceasta poate fi „umplută" folosind pensula GDI curentă. Această pensulă
poate fi o culoare compactă, un model (haşuri orizontale, verticale sau pe diagonală) sau o imagine bitmap repetată pe verticală sau pe orizontală.
· Imagini bitmap. Imaginile bitmap sunt matrice dreptunghiulare de biţi, care corespund pixelilor unui dispozitiv de afişare. Imaginile bitmap
sunt instrumente de bază pentru sistemele grafice de tip rastru. În general, acestea sunt folosite pentru afişarea imaginilor complexe (deseori
preluate din lumea reală) pe ecran sau pentru tipărirea acestora la imprimantă. De asemenea, imaginile bitmap sunt folosite pentru afişarea unor
mici imagini (cum ar fi pictograme, indicatoare de mouse şi butoane de pe barele cu instrumente de lucru ale aplicaţiilor) care trebuie afişate foarte
rapid. Interfaţa GDI acceptă două tipuri de imagini bitmap: un tip mai vechi (dar util) de imagini bitmap dependente de dispozitiv şi un tip mai nou
(precum cele din Windows 3.0) de imagini bitmap independente de dispozitiv (DIB - Device Independent Bitmap) care pot fi stocate în fişiere.
· Text. Textul este mai puţin „matematic" decât alte aspecte ale graficii pe calculator. Textul, aşa cum îl ştim, este legat de sute de ani de
tipografia tradiţională, apreciată adesea ca adevărată artă. Din acest motiv, textul este de multe ori nu doar cea mai complexă parte a sistemului
grafic, ci şi cea mai importantă. Structurile create pentru definirea fonturilor şi pentru obţinerea informaţiilor despre fonturi sunt printre cele mai
mari din Windows. Începând cu versiunea Windows 3.1, interfaţa GDI acceptă fonturile TrueType, bazate pe contururi umplute, care pot fi
manipulate de alte funcţii GDI. Windows 95 acceptă în continuare şi fonturile mai vechi, de tip bitmap (cum este fontul sistem prestabilit) pentru
compatibilitate şi pentru economisirea spaţiului de memorie.
Alte aspecte
Alte aspecte ale interfeţei GDI nu sunt la fel de uşor de clasificat. Printre acestea se numără:
· Moduri de mapare şi transformări. Deşi, în mod prestabilit, desenarea se face folosind ca unităţi de măsură pixelii, nu sunteţi limitat la acest
sistem de măsură. Modurile de mapare GDI vă permit să desenaţi folosind ca unitate de măsură inci (sau fracţiuni de inci), milimetri sau orice altă
unitate de măsură. De asemenea, Windows 95 asigură suportul pentru o „transformare reală" exprimată printr-o matrice 3x3. Această transformare
permite deformarea şi rotirea obiectelor grafice. Din păcate, această transformare nu este acceptată sub Windows 95.
· Metafişiere (metafiles). Un metafişier este o colecţie de comenzi GDI stocate într-o formă binară. Metafişierele sunt folosite, în primul rând,
pentru transferarea reprezentărilor unor elemente grafice vectoriale prin intermediul memoriei temporare (clipboard).
· Regiuni (regions). O regiune este o suprafaţă complexă de orice formă, definită ca o combinaţie booleană de regiuni mai simple. În general,
regiunile sunt stocate intern de GDI ca o serie de linii de scanare, diferite de combinaţia de linii folosită iniţial pentru definirea regiunii. Puteţi să
folosiţi regiunile pentru contururi, pentru umplere sau pentru decupare.
· Căi (paths). O cale este o colecţie de linii drepte şi curbe stocate intern de GDI. Căile pot fi folosite pentru desenare, pentru umplere sau
pentru decupare. De asemenea, căile pot fi transformate în regiuni.
· Decupare (clipping). Desenarea poate fi limitată la o anumită secţiune a zonei client, numită zonă de decupare, care poate fi dreptunghiulară
sau poate avea o altă formă, definită printr-o serie de linii. Zona de decupare este definită, în general, de o cale sau de o regiune.
· Palete (palettes). Folosirea paletelor proprii este limitată, în general, numai la monitoarele care pot reda 256 de culori. Windows rezervă 20
dintre aceste culori pentru sistemul de operare. Celelalte 236 de culori pot fi modificate pentru afişarea corespunzătoare a imaginilor din lumea
reală, stocate ca imagini bitmap.
· Tipărire (printing). Deşi discuţiile din acest capitol sunt limitate doar la afişarea pe ecran, tot ceea ce învăţaţi în acest capitol poate fi aplicat şi
operaţiilor de tipărire. (Vezi Capitolul 15 pentru alte informaţii despre tipărire.)
CONTEXTUL DE DISPOZITIV
Înainte de a începe să desenăm, haideţi să mai aflăm câte ceva despre contextele de dispozitiv.
Atunci când vreţi să desenaţi la un dispozitiv de ieşire grafic (cum ar fi ecranul sau imprimanta) trebuie să obţineţi mai întâi o variabilă handle a
contextului de dispozitiv (DC - device context). Prin obţinerea acestei variabile handle primiţi permisiunea de folosire a dispozitivului. Variabila
handle este apoi inclusă ca parametru în apelul unei funcţii GDI, identificând dispozitivul la care vreţi să desenaţi.
Contextul de dispozitiv conţine mai multe atribute curente, care specifică modul de lucru al funcţiilor GDI pentru dispozitivul respectiv. Aceste
atribute permit ca la apelarea funcţiilor GDI să fie specificate numai coordonatele de început sau dimensiunea, nu şi toate celelalte informaţii de
care sistemul de operare are nevoie pentru desenarea obiectelor pe dispozitivul folosit. De exemplu, atunci când apelaţi funcţia TextOut trebuie să
specificaţi numai variabila handle a contextului de dispozitiv, coordonatele de început, textul şi lungimea acestuia. Nu trebuie să precizaţi fontul,
culoarea textului, culoarea fondului din spatele textului şi spaţiul dintre caractere, deoarece aceste atribute fac parte din contextul de dispozitiv.
Atunci când doriţi să modificaţi unul dintre aceste atribute ale contextului de dispozitiv, apelaţi o funcţie specializată. Următoarele apeluri ale
funcţiei TextOut pentru acelaşi context de dispozitiv vor folosi atributul modificat.
Obţinerea variabilei handle a contextului de dispozitiv
Sistemul de operare Windows vă pune la dispoziţie mai multe metode pentru obţinerea variabilei handle a contextului de dispozitiv. Dacă obţineţi
o variabilă handle a contextului de dispozitiv în timpul prelucrării unui mesaj, ar trebui să ştergeţi această variabilă înainte de ieşirea din procedura
de fereastră. După ce este ştearsă, variabila handle nu mai poate fi folosită (nu mai este validă).
Cea mai cunoscută metodă de obţinere şi de ştergere a variabilei handle a contextului de dispozitiv implică folosirea funcţiilor BeginPaint şi
EndPaint în timpul prelucrării mesajului WM_PAINT:
hdc = BeginPaint (hwnd, &ps);
[alte Unii de program]
EndPaint (hwnd, &ps);
Variabila ps este o structură de tip PAINTSTRUCT. Câmpul hdc al acestei structuri conţine variabila handle a contextului de dispozitiv. Structura
PAINTSTRUCT conţine şi o structură de tip RECT numită rcPaint, care defineşte dreptunghiul ce cuprinde regiunea invalidă a zonei client a ferestrei.
Folosind variabila handle a contextului de dispozitiv, obţinută prin apelarea funcţiei BeginPaint, nu puteţi să desenaţi decât în regiunea invalidă a
ferestrei. Funcţia BeginPaint validează regiunea invalidă.
Programele Windows pot să obţină variabila handle a contextului de dispozitiv şi în timpul prelucrării altor mesaje decât WM_PAINT:
hdc = GetDC (hwnd);
(alte linii de program]

ReleaseDC (hwnd, hdc);
Acest context de dispozitiv se aplică zonei client a ferestrei care are variabila handle hwnd. Principala diferenţă între apelul de mai sus şi metoda
folosirii funcţiilor BeginPaint şi EndPaint este că variabila handle returnată de funcţia GetDC vă permite să desenaţi în toată zona client a ferestrei. În
plus, funcţiile GetDC şi ReleaseDC nu validează eventualele regiuni invalide ale zonei client.
Un program Windows poate să obţină şi o variabilă handle a unui context de dispozitiv care se aplică întregii ferestre, nu numai zonei client a
ferestrei:
hdc = GetWindowDC (hwnd);
[alte linii de program]
Contextul de dispozitiv include, în afară de zona client, bara de titlu a ferestrei, barele de derulare şi chenarul. Funcţia GetWindowDC este rareori
folosită de aplicaţii. Dacă vreţi să experimentaţi folosirea acestei funcţii, trebuie să interceptaţi mesajele WM_NCPAINT („nonclient paint"),
împiedicând sistemul de operare să redeseneze porţiunile din fereastră care nu fac parte din zona client.
Funcţiile BeginPaint, GetDC şi GetWindowDC obţin variabila handle a contextului de dispozitiv asociat unei anumite ferestre de pe ecran. O funcţie
mai generală pentru obţinerea variabilei handle a unui context de dispozitiv este CreateDC:
hdc = CreateDC (pszDriver, pszDevice, pszOutput, pData);
DeleteDC (hdc);
De exemplu, puteţi să obţineţi variabila handle a contextului de dispozitiv pentru tot spaţiul de afişare, cu următorul apel:
hdc = CreateDC ("DISPLAY", NULL, NULL, NULL);
Scrierea în afara ferestrei proprii nu este în general recomandată, dar poate fi convenabilă pentru unele aplicaţii speciale. (Deşi această metodă nu e
documentată, se poate obţine o variabila handle a contextului de dispozitiv pentru întregul ecran şi prin apelarea funcţiei GetDC, cu parametrul
NULL). În Capitolul 15 vom folosi funcţia CreateDC pentru a obţine o variabilă handle a contextului de dispozitiv pentru o imprimantă.
Uneori aveţi nevoie de unele informaţii despre un context de dispozitiv fără să desenaţi nimic. În această situaţie puteţi să obţineţi o variabila
handle a contextului de informaţii („information context") folosind funcţia CreateIC. Parametrii sunt aceiaşi ca şi pentru funcţia CreateDC:
hdclnfo = CreatelC ("DISPLAY", NULL, NULL, NULL);
DeleteDC (hdclnfo);
Nu puteţi să executaţi operaţii de scriere la un dispozitiv folosind această variabilă handle.
Atunci când lucraţi cu imagini bitmap, poate fi uneori utilă obţinerea unui „context de dispozitiv în memorie":
hdcMem = CreateCompatibleDC (hdc);
DeleteDC (hdcHem)
Acesta este un concept destul de abstract. În esenţă, puteţi să selectaţi o imagine bitmap într-un context de dispozitiv în memorie şi apoi să
desenaţi peste folosind funcţiile GDI. Vom discuta mai târziu despre această tehnică şi o vom folosi în programul GRAFMENU din Capitolul 10.
Aşa cum am menţionat mai devreme, un metafişier este o colecţie de apeluri GDI codificate într-o formă binară. Puteţi să creaţi un metafişier prin
obţinerea unui context de dispozitiv pentru metafişiere:
hdcMeta = CreateMetaFile(pszFilename);
hmf = CloseMetaFile (hdcMeta);
Cât timp acest context este valid, nici un apel GDI pe care îl faceţi folosind parametrul hdcMeta nu afişează nimic pe ecran, ci devine parte a
metafişierului. Apelaţi apoi funcţia CloseMetaFile şi contextul de dispozitiv este invalidat. Funcţia returnează o variabilă handle a metafişierului
(hmf).
Obţinerea informaţiilor despre contextul de dispozitiv

Un context de dispozitiv se referă, de obicei, la un dispozitiv fizic de ieşire, cum ar fi un monitor video sau o imprimantă. Dacă aveţi nevoie de
anumite informaţii despre acest dispozitiv, cum ar fi dimensiunile ecranului (dimensiunile în pixeli şi cele fizice) sau posibilităţile de folosire a
culorilor, puteţi să le obţineţi prin apelarea funcţiei GetDeviceCaps („get device capabilities"):
iValue = GetDeviceCaps (hdc, iIndex) ;
Parametrul iIndex este unul dintre cei 28 de identificatori definiţi în fişierele antet din Windows. De exemplu, dacă iIndex are valoarea HORZRES
funcţia GetDeviceCaps returnează lăţimea dispozitivului în pixeli; VERTRES returnează înălţimea dispozitivului în pixeli. Dacă hdc este o variabilă
handle a contextului de dispozitiv pentru un monitor video, informaţiile obţinute sunt aceleaşi cu cele returnate de funcţia GetSystemMetrics. Dacă
hdc este o variabilă handle a contextului de dispozitiv pentru o imprimantă, funcţia GetDeviceCaps returnează înălţimea şi lăţimea zonei pe care
imprimantă o poate tipări.
Puteţi să folosiţi funcţia GetDeviceCaps şi ca să obţineţi informaţii despre posibilităţile unui dispozitiv de prelucrare a anumitor tipuri de elemente
grafice. Această posibilitate nu este importantă pentru ecran, dar poate fi folosită în cazul imprimantelor. De exemplu, majoritatea plotterelor nu
pot tipări imagini bitmap - iar funcţia GetDeviceCaps vă poate comunica acest lucru.
Programul DEVCAPS1
Programul DEVCAPS1, prezentat în Figura 4-1, afişează o parte dintre informaţiile pe care poate să le returneze funcţia GetDeviceCaps.
DEVCAPS1.C -- Device Capabilities Display Program No. 1
(c) Charles Petzold, 1996
---------------------------------------------------------*/
#include <windows.h>
#include <string.h>
#define NUMLINES ((int) (sizeof devcaps / sizeof devcaps [0]))
struct
int iIndex ;
char *szLabel ;
char *szDesc ;
devcaps [] =
HORZSIZE, "HORZSIZE", "Width in millimeters:",
VERTSIZE, "VERTSIZE", "Height in millimeters:",
HORZRES, "HORZRES", "Width in pixels:",
VERTRES, "VERTRES", "Height in raster lines:",
BITSPIXEL, "BITSPIXEL", "Color bits per pixel:",
PLANES, "PLANES", "Number of color planes:",
NUMBRUSHES, "NUMBRUSHES", "Number of device brushes:",
NUMPENS, "NUMPENS", "Number of device pens:",
NUMMARKERS, "NUMMARKERS", "Number of device markers:",
NUMFONTS, "NUMFONTS", "Number of device fonts:",
NUMCOLORS, "NUMCOLORS", "Number of device colors:",
PDEVICESIZE, "PDEVICESIZE", "Size of device structure:",
ASPECTX, "ASPECTX", "Relative width of pixel:",
ASPECTY, "ASPECTY", "Relative height of pixel:",
ASPECTXY, "ASPECTXY", "Relative diagonal of pixel:",

LOGPIXELSX, "LOGPIXELSX", "Horizontal dots per inch:",
LOGPIXELSY, "LOGPIXELSY", "Vertical dots per inch:",
SIZEPALETTE, "SIZEPALETTE", "Number of palette entries:",
NUMRESERVED, "NUMRESERVED", "Reserved palette entries:",
COLORRES, "COLORRES", "Actual color resolution:"
};
LRESULT CALLBACK WndProc (HWND, UINT, WPARAM, LPARAM);
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,PSTR szCmdLine, int iCmdShow)
static char szAppName[] = "DevCaps1" ;
HWND hwnd ;
MSG msg ;
WNDCLASSEX wndclass ;
wndclass.cbSize = sizeof (wndclass) ;
wndclass.style = CS_HREDRAW | CS_VREDRAW ;
wndclass.lpfnWndProc = WndProc ;
wndclass.cbClsExtra = 0 ;
wndclass.cbWndExtra = 0 ;
wndclass.hInstance = hInstance ;
wndclass.hIcon = LoadIcon (NULL, IDI_APPLICATION) ;
wndclass.hCursor = LoadCursor (NULL, IDC_ARROW) ;
wndclass.hbrBackground = (HBRUSH) GetStockObject (WHITE_BRUSH) ;
wndclass.lpszMenuName = NULL ;
wndclass.lpszClassName = szAppName ;
wndclass.hIconSm = LoadIcon (NULL, IDI_APPLICATION) ;
RegisterClassEx (&wndclass) ;
hwnd = CreateWindow (szAppName, "Device Capabilities", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT,

CW_USEDEFAULT, NULL, NULL, hInstance, NULL) ;
ShowWindow (hwnd, iCmdShow) ;
UpdateWindow (hwnd) ;
while (GetMessage (&msg, NULL, 0, 0))
TranslateMessage (&msg) ;
DispatchMessage (&msg) ;
}
return msg.wParam ;
LRESULT CALLBACK WndProc (HWND hwnd, UINT iMsg, WPARAM wParam, LPARAM lParam)
static int cxChar, cxCaps, cyChar ;
char szBuffer[10] ;
HDC hdc ;
int i ;
PAINTSTRUCT ps ;
TEXTMETRIC tm ;
switch (iMsg)
case WM_CREATE:
hdc = GetDC (hwnd) ;
GetTextMetrics (hdc, &tm) ;
cxChar = tm.tmAveCharWidth ;
cxCaps = (tm.tmPitchAndFamily & 1 ? 3 : 2) * cxChar / 2 ;
cyChar = tm.tmHeight + tm.tmExternalLeading ;
ReleaseDC (hwnd, hdc) ;
return 0 ;
case WM_PAINT:
hdc = BeginPaint (hwnd, &ps) ;
for (i = 0 ; i < NUMLINES ; i++)
TextOut (hdc, cxChar, cyChar * (1 + i),
devcaps[i].szLabel,
strlen (devcaps[i].szLabel)) ;
TextOut (hdc, cxChar + 22 * cxCaps, cyChar * (1 + i),
devcaps[i].szDesc,
strlen (devcaps[i].szDesc)) ;
SetTextAlign (hdc, TA_RIGHT | TA_TOP) ;
TextOut (hdc, cxChar + 22 * cxCaps + 40 * cxChar,
cyChar * (1 + i), szBuffer,
wsprintf (szBuffer, "%5d",
GetDeviceCaps (hdc, devcaps[i].iIndex))) ;
SetTextAlign (hdc, TA_LEFT | TA_TOP) ;
}
EndPaint (hwnd, &ps) ;
return 0 ;
case WM_DESTROY:
PostQuitMessage (0) ;
return 0 ;
return DefWindowProc (hwnd, iMsg, wParam, lParam) ;
Figura 4-1. Programul DEVCAPS1.
Aşa cum se poate vedea, acest program este foarte asemănător cu programul SYSMETS din Capitolul 3. Pentru a micşora dimensiunea codului, nu
am inclus bare de derulare, deoarece ştiam că textul afişat va încăpea pe ecran. Rezultatele afişate de acest program pe un monitor VGA cu 256 de
culori sunt prezentate în Figura 4-2.
Figura 4-2. Fereastra afişata de programul DEVCAPS1 pe un monitor VGA cu 256 de culori.
Dimensiunea dispozitivului
Cea mai importantă informaţie pe care poate să o obţină programul despre monitorul video prin apelarea funcţiei GetDeviceCaps este dimensiunea
ecranului (măsurată atât în pixeli, cat şi în milimetri) şi proporţia dimensiunilor unui pixel. Aceste informaţii pot fi folosite pentru scalarea imaginilor
afişate pe ecran.
Valorile HORZSIZE şi VERTSIZE reprezintă lăţimea şi înălţimea suprafeţei de afişare, în milimetri. Desigur, driverul Windows nu ştie exact ce tip de
monitor este ataşat la placa video. Dimensiunile returnate sunt bazate pe dimensiunile standard cunoscute de placa video.
Valorile HORZRES şi VERTRES reprezintă lăţimea şi înălţimea suprafeţei de afişare, în pixeli. Pentru contextul de dispozitiv al unui ecran, aceste
dimensiuni sunt aceleaşi cu cele returnate de funcţia GetSystemMetrics. Folosind aceste valori împreună cu HORZSIZE şi VERTSIZE puteţi să obţineţi
rezoluţia dispozitivului în pixeli pe milimetru. Dacă ştiţi că un inci are 25,4 milimetri, puteţi să calculaţi rezoluţia în puncte pe inci (dpi - dots per
inch).
Valorile ASPECTX, ASPECTY şi ASPECTXY reprezintă dimensiunile aproximative pentru lăţimea, înălţimea şi diagonală unui pixel, rotunjite la cel mai
apropiat număr întreg. ASPECTXY este rădăcina pătrată a sumei pătratelor valorilor ASPECTX şi ASPECTY, aşa cum vă amintiţi din teorema lui
Pitagora.
Valorile LOGPIXELSX şi LOGPIXELSY reprezintă numărul de pixeli pe un „inci logic", pe orizontală şi pe verticală. În cazul monitoarelor, un inci logic
nu este egal cu un inci fizic (25,4 milimetri) aşa cum puteţi să vă daţi seama imediat dacă faceţi câteva calcule cu valorile HORZSIZE, VERTSIZE,
HORZRES şi VERTRES. Probabil aţi observat că majoritatea procesoarelor de text sub Windows afişează o riglă care însă nu este prea corectă: dacă
măsuraţi rigla aşa cum este aceasta afişată pe un ecran VGA, veţi vedea că un inci de pe aceasta are de fapt cam 1,5 inci reali. Aceste programe
folosesc pentru afişarea riglei valorile LOGPIXELSX şi LOGPIXELSY. Dacă programele ar folosi dimensiunile fizice reale, textul de 10 sau 12 puncte ar
fi atât de mic, încât nu ar putea fi citit. Dimensiunile logice măresc elementele afişate, astfel încât textul să fie corect dimensionat. Atunci când vom
începe să lucrăm cu texte, vom relua această problemă. Această problemă priveşte doar ecranele; toate dimensiunile returnate de funcţia
GetDeviceCaps pentru imprimante sunt consecvente.
Obţinerea informaţiilor despre culori
Pentru afişarea culorilor este nevoie de mai mulţi biţi. Cu cât se folosesc mai mulţi biţi, cu atât pot fi afişate mai multe culori. Sau, mai precis,
numărul culorilor care pot fi afişate simultan este egal cu 2 la o putere egală cu numărul de biţi folosiţi. De obicei, biţii sunt organizaţi în planuri de
culori - un plan pentru roşu, un plan pentru verde, unul pentru albastru şi unul pentru intensitatea culorii. Adaptoarele video cu 8, 16 sau 24 de biţi
pentru fiecare pixel au un singur plan de culoare, în care un număr de biţi adiacenţi reprezintă culoarea fiecărui pixel.
Funcţia GetDeviceCaps vă permite să determinaţi modul de organizare a memoriei în adaptoarele video şi numărul de culori care pot fi
reprezentate. Apelul de mai jos returnează numărul de planuri de culoare:
iPlanes = GetDeviceCaps (hdc, PLANES);
Apelul următor returnează numărul de biţi de culoare folosiţi pentru fiecare pixel:
iBitsPixel = GetDeviceCaps (hdc, BITSPIXEL)
Majoritatea adaptoarelor video care pot afişa culori folosesc fie mai multe planuri de culoare, fie mai mulţi biţi de culoare pentru fiecare pixel, dar
nu pe amândouă; cu alte cuvinte, unul dintre cele două apeluri de mai sus va returna valoarea 1. Numărul de culori care pot fi redate de o placă
video se poate calcula cu formula următoare:
iColors = 1<<(iPlanes * iBitsPixel);
Această valoare poate să nu fie identică cu numărul de culori obţinut prin apelarea funcţiei GetDeviceCaps cu parametrul NUMCOLORS:
iColors = GetDeviceCaps (hdc, NUMCOLORS);
De exemplu, cele două numere vor fi diferite pentru majoritatea plotterelor. În cazul unui plotter, PLANES şi BITSPIXEL vor avea valoarea 1, dar
NUMCOLORS va reprezenta numărul de peniţe pe care le foloseşte plotterul. Pentru dispozitivele monocrome, funcţia GetDeviceCaps apelată cu
parametrul NUMCOLORS returnează valoarea 2.
Aceste valori pot fi diferite şi în cazul adaptoarelor video care permit încărcarea paletelor de culori. Funcţia GetDeviceCaps apelată cu parametrul
NUMCOLORS returnează numărul de culori rezervate de Windows, adică 20. Celelalte 236 de culori pot fi stabilite de program folosind un manager
de palete.
Windows foloseşte pentru reprezentarea culorilor o valoare întreagă fără semn, pe 32 de biţi. Tipul de date folosit pentru culori se numeşte
COLORREF. Ultimii trei octeţi ai numărului (cei mai puţin semnificativi) specifică valorile pentru culorile roşu, verde şi albastru, de la 0 la 255, aşa
cum se poate vedea în Figura 4.3. Rezultă o paletă potenţială de 224 culori (aproximativ 16 milioane de culori).
Figura 4.3. Valoarea pe 32 de biţi folosita pentru reprezentarea culorilor.
Valoarea pe 32 de biţi de mai sus e numită deseori „culoare RGB". În fişierele antet din Windows sunt definite mai multe macroinstrucţiuni pentru
lucrul cu valorile RGB. Macroinstrucţiunea RGB acceptă trei argumente, care reprezintă valorile pentru culorile roşu, verde şi albastru şi le combină
într-o valoarea întreagă pe 32 de biţi, fără semn:
#define RBG (r, g, b) ((COLORREF)(((BYTE)(r)|\
((WORD)(g)<<8))|\
(((DWORD) (BYTE) (b))<<16)))
Astfel, valoarea RGB (255, 0, 255) este de fapt 0x00FF00FF, valoarea RGB pentru magenta. Dacă toate cele trei argumente au valoarea 0, se obţine
negrul, iar dacă au valoarea 255, se obţine albul. Macroinstrucţiunile GetRValue, GetGValue şi GetBValue extrag valorile pentru culorile primare, sub
forma unor octeţi fără semn, din valoarea RGB a culorii. Aceste macroinstrucţiuni sunt utile atunci când apelaţi funcţii Windows care returnează
culori RGB.
Numărul de culori returnat de funcţia GetDeviceCaps reprezintă numărul de culori pure pe care le poate afişa dispozitivul respectiv. Windows poate
să folosească amestecarea culorilor - aceasta implică folosirea unui model de pixeli de diferite culori - pentru reprezentarea altor culori în afara
celor pure. Nu toate combinaţiile de valori pentru roşu, verde şi albastru produc modele diferite de amestecare a culorilor. De exemplu, în cazul
unui monitor VGA pe care pot fi afişate 16 culori, valorile pentru roşu, verde şi albastru trebuie să fie incrementate cu patru, ca să genereze un
model diferit de amestecare. Ca urmare, pentru aceste tipuri de adaptoare aveţi la dispoziţie 218 (sau 262 144) culori amestecate.
Puteţi să determinaţi cea mai apropiată culoare pură pentru o anumită valoare apelând funcţia GetNearestColor:
rgbPureColor = GetNearestColor (hdc, rgbColor) ;
Atributele contextului de dispozitiv

Aşa cum am menţionat mai sus, Windows foloseşte contextul de dispozitiv ca să stocheze atributele care specifică modul de lucru al funcţiilor GDI
pentru afişare. De exemplu, atunci când afişaţi un text folosind funcţia TextOut nu trebuie să specificaţi culoarea textului sau fontul folosit. Windows
foloseşte contextul de dispozitiv ca să obţină aceste informaţii.
Atunci când un program obţine o variabilă handle a unui context de dispozitiv, Windows creează un context de dispozitiv cu valorile prestabilite
pentru toate atributele. Atributele contextului de dispozitiv sunt prezentate în tabelul următor. Un program poate să schimbe sau să obţină aceste
atribute.
Atributul Valoare Funcţia folosită pentru Funcţia folosită pentru

contextului de prestabilită modificarea atributului obţinerea atributului
dispozitiv
Mod de MM_TEXT SetMapMode GetMapMode
mapare
Originea (0,0) SetWindowOrgEx GetWindowOrgEx

ferestrei OffsetWindowOrgEx
Originea (0,0) SetViewportOrgEx GetViewportOrgEx

vizorului OffsetViewportOrgEx
Extensia (1,1) SetWindowExtEx GetWindowExtEx

ferestrei
SetMapMode
ScaleWindowExtEx
Extensia (1,1) SetViewportExtEx GetViewportExExt

vizorului SetMapMode
ScaleViewportExtEx
Peniţă (pen) BLACK_PEN SelectObject SelectObject
Pensulă (brush) WHITE_BRUSH SelectObject SelectObject
Font SYSTEM_FONT SelectObject SelectObject
Bitmap Nu există SelectObject SelectObject
Poziţia curentă a (0,0) MoveToEx GetCurrentPositionEx

peniţei
LineTo PolylineTo
PolyBezierTo
Modul de OPAQUE SetBkMode GetBkMode

afişare a
fondului
Culoarea Alb SetBkColor GetBkColor
fondului
Culoarea Negru SetTextColor GetTextColor

textului
Mod de R2COPYPEN SetROPZ GetROP2
desenare
Mod de BLACKONWHITE SetStretchBltMode GetStretchBltMode
întindere
Mod de ALTERNATE SetPolyFillMode GetPolyFillMode

umplere a
prigoanelor
Spaţiu între 0 SetTextCharacterExtra GetTextCharacterExtra
caractere
Originea (0,0) în SetBrushOrgEx GetBrushOrgEx

pensulei coordonate
ecran
Regiune de Nu există SelectObject GetClipBox

decupare SelectClipRgn
Salvarea contextului de dispozitiv
În acest capitol veţi întâlni diferite funcţii folosite pentru modificarea atributelor contextului de dispozitiv. În mod normal, Windows creează un nou
context de dispozitiv cu valori prestabilite atunci când apelaţi una dintre funcţiile GetDC sau BeginPaint. Toate modificările făcute în atributele
contextului de dispozitiv se pierd atunci când contextul de dispozitiv este şters din memorie prin apelarea funcţiei ReleaseDC sau a funcţiei
EndPaint. Dacă programul trebuie să folosească un atribut cu o valoarea diferită de cea prestabilită va trebui să iniţializaţi contextul de dispozitiv de
fiecare dată când obţineţi o variabilă handle:
case WM_Paint:
hdc = BeginPaint (hwnd, &ps);
[iniţializează atributele contextului de dispozitiv]
[desenează zona client a ferestrei]
EndPaint (hwnd, &ps);
return 0;
Deşi această abordare este în general satisfăcătoare, s-ar putea să preferaţi să salvaţi modificările făcute asupra contextului de dispozitiv la
distrugerea acestuia, astfel încât valorile salvate să redevină active la apelarea funcţiilor GetDC sau BeginPaint.
Puteţi realiza acest lucru incluzând indicatorul flag CS_OWNDC în clasa ferestrei, atunci când o înregistraţi:
wndclass.style = CS_HREDRAW | CS_VREDRAH | CS_OWNDC;
Acum fiecare fereastră pe care o creaţi pe baza acestei clase va avea propriul context de dispozitiv, care va fi păstrat până la distrugerea ferestrei.
Atunci când folosiţi stilul de fereastră CS_OWNDC, trebuie să iniţializaţi contextul de dispozitiv o singură dată, de obicei în timpul prelucrării
mesajului WM_CREATE:
case WM_CREATE:
hdc = GetDC (hwnd);
[iniţiallzează atributele contextului de dispozitiv]
Atributele sunt valide până când le modificaţi în mod explicit.
Stilul de fereastră CS_OWNDC afectează numai contextele de dispozitiv obţinute prin apelarea funcţiilor GetDC sau BeginPaint, nu şi cele obţinute
prin apelarea altor funcţii (cum ar fi GetWindowDC). Stilul de fereastră CS_OWNDC are şi un dezavantaj: sistemul de operare Windows consumă
aproximativ 800 de octeţi pentru salvarea contextului de dispozitiv al fiecărei ferestre create cu acest stil. Chiar dacă folosiţi stilul de fereastră
CS_OWNDC, trebuie să distrugeţi contextul de dispozitiv înainte de ieşirea din procedura de fereastră.
De asemenea, puteţi să folosiţi şi stilul CS_CLASSDC:
wndclass.style = CS_HREDRAW | CS_VREDRAW | CS_CLASSDC;
Acest stil face ca fiecare clasă de fereastră să aibă un context de dispozitiv, folosit în comun de toate ferestrele create pe baza clasei respective. În
general, stilul de fereastră CS_CLASSDC este mai greu de folosit decât stilul CS_OWNDC, deoarece orice modificare pe care o faceţi asupra
atributelor contextului de dispozitiv afectează toate ferestrele create pe baza aceleiaşi clase. Uneori efectele pot fi destul de bizare.
Dacă s-ar putea să doriţi să modificaţi unele dintre atributele contextului de dispozitiv, să desenaţi ceva folosind noile atribute şi apoi să reveniţi la
vechile valori, salvaţi starea curentă a contextului de dispozitiv prin următorul apel:
iSavedID = SaveDC (hdc);
Modificaţi atributele dorite. Atunci când vreţi să reveniţi la starea contextului de dispozitiv dinaintea apelării funcţiei SaveDC, folosiţi funcţia
RestoreDC:
RestoreDC (hdc, iSavedID);

Puteţi să apelaţi funcţia SaveDC de oricâte ori înainte de a apela funcţia RestoreDC. Dacă vreţi să reveniţi la starea contextului de dispozitiv de
dinaintea ultimului apel al funcţiei SaveDC, folosiţi următorul apel:
RestoreDC (hdc, -1);
Desenarea liniilor
Teoretic, singura funcţie necesară pentru desenare este SetPixel (şi, în unele situaţii, GetPixel). Orice altceva poate fi făcut prin apelarea unor funcţii
de nivel înalt, implementate chiar în modulul GDI sau chiar în codul aplicaţiei. De exemplu, pentru desenarea unei linii nu trebuie decât să apelaţi
de mai multe ori funcţia de „scriere" a unui pixel şi să modificaţi corespunzător coordonatele x şi y.
În realitate, puteţi să executaţi orice operaţie de desenare folosind numai funcţiile de scriere şi de citire a unui pixel, doar dacă nu vă deranjează să
aşteptaţi rezultatele. Pentru un sistem grafic este mult mai eficientă manipularea operaţiilor de desenare a unei linii sau a altor operaţii grafice
complexe la nivelul driverului dispozitivului, care poate conţine un cod optimizat pentru executarea acestor operaţii. Mai mult, pe măsură ce
tehnologia de afişare devine tot mai complexă, plăcile specializate conţin coprocesoare tot mai performante, care permit chiar componentelor
video hardware să facă desenarea figurilor.
Interfaţa Windows GDI conţine şi funcţiile SetPixel şi GetPixel. Deşi vom folosi funcţia SetPixel în programul CONNECT din Capitolul 7, în programele
de grafică propriu-zisă aceste funcţii sunt rareori folosite. În majoritatea cazurilor, cea mai simplă primitivă grafică vectorială trebuie să fie
considerată linia.
Windows poate să deseneze linii drepte, linii eliptice (linii curbe, pe circumferinţa unei elipse) şi curbe Bezier. Cele şapte funcţii acceptate de
Windows 95 pentru desenarea liniilor sunt LineTo (linii drepte), Polyline şi PolylineTo (o serie de linii drepte conectate), PolyPolyline (mai multe linii
poligonale), Arc (linii eliptice), PolyBezier şi PolyBezierTo. (Interfaţa GDI din Windows NT acceptă încă trei funcţii pentru desenarea liniilor: ArcTo,
AngleArc şi PolyDraw. Aceste funcţii nu sunt însă acceptate în Windows 95.) Aspectul liniilor desenate cu aceste funcţii poate fi influenţat de cinci
atribute ale contextului de dispozitiv: poziţia curentă a peniţei (numai pentru funcţiile LineTo, PolylineTo şi PolyBezierTo), peniţa selectată, modul de
afişare a fondului (numai pentru peniţele care nu desenează cu o culoare compactă), culoarea fondului (pentru modul OPAQUE de afişare a
fondului) şi modul de desenare.
Din motive pe care le voi arăta puţin mai târziu, tot în această secţiune voi prezenta şi funcţiile Rectangle, Ellipse, RoundRect, Chord şi Pie, chiar dacă
aceste funcţii sunt folosite şi pentru desenarea suprafeţelor pline.
Funcţia LineTo este una dintre puţinele funcţii GDI care nu are nevoie de dimensiunile complete ale obiectului ce urmează să fie desenat. Funcţia
LineTo desenează o linie de la „poziţia curentă" definită în contextul de dispozitiv pană la punctul specificat la apelarea funcţiei (exclusiv acest
punct). Poziţia curentă este folosită ca punct de plecare şi de alte funcţii GDI. În contextul de dispozitiv prestabilit, poziţia curentă are iniţial valoarea
(0,0). Dacă apelaţi funcţia LineTo fără să stabiliţi mai întâi poziţia curentă, funcţia desenează o linie pornind din colţul din stânga-sus al zonei client.
Dacă doriţi să desenaţi o linie din punctul (xStart, yStart) pană în punctul (xEnd, yEnd) trebuie să apelaţi mai întâi funcţia MoveToEx ca să stabiliţi ca
poziţie curentă punctul (xStart, ySfart):
MoveToEx (hdc, xStart, yStart, &pt) ;
unde pt este o structură de tip POINT, definită în fişierele antet din Windows astfel:
typedef struct tag POINT
LONG x ;
LONG y ;
POINT ;
Funcţia MoveToEx nu desenează nimic, ci doar schimbă poziţia curentă. Poziţia curentă anterioară este stocată în structura de tip POINT. Puteţi apoi
să folosiţi funcţia LineTo ca să desenaţi linia:
LineTo (hdc, xEnd, yEnd);
Apelul de mai sus desenează o linie până în punctul (xEnd, yEnd), exclusiv acest punct. După apelul funcţiei LineTo, poziţia curentă devine (xEnd,
yEnd).
O scurtă notă istorică: în versiunile pe 16 biţi ale sistemului de operare Windows, funcţia folosită pentru modificarea poziţiei curente era MoveTo,
care avea numai trei parametri - variabila handle a contextului de dispozitiv şi coordonatele x şi y. Funcţia MoveTo returna poziţia curentă
anterioară sub forma a două valori pe 16 biţi împachetate într-un întreg fără semn pe 32 de biţi. În versiunile pe 32 de biţi ale sistemului de operare
(Windows NT şi Windows 95) coordonatele sunt valori pe 32 de biţi. Deoarece în versiunea pe 32 de biţi a limbajului C nu este definit un tip de date
întreg pe 64 de biţi, funcţia MoveTo a fost înlocuită cu funcţia MoveToEx. Această modificare a fost necesară chiar dacă valoarea returnată de
funcţia MoveTo nu a fost folosită aproape niciodată cu adevărat în programare !
Iată o veste bună: dacă nu aveţi nevoie de poziţia curentă anterioară - ceea ce se întâmplă destul de des - puteţi să daţi ultimului parametru al
funcţiei MoveToEx valoarea NULL. De fapt, dacă doriţi să transformaţi codul pe 16 biţi existent în cod pentru Windows 95, puteţi să definiţi o
macroinstrucţiune, astfel:
#define MoveTo (hdc, x, y) MoveToEx (hdc, x, y, NULL)
Vom folosi această macroinstrucţiune în mai multe programe din capitolele următoare.
Iată însă şi o veste proastă. Chiar dacă în Windows 95 coordonatele par a fi valori pe 32 de biţi, din acestea sunt folosiţi numai cei 16 biţi mai puţin
semnificativi. Coordonatele pot avea valori numai între -32.768 şi 32.767.
Puteţi să obţineţi poziţia curentă a peniţei apelând funcţia GetCurrentPosition astfel:
GetCurrentPositionEx (hdc, &pt) ;
Secvenţa de cod care urmează desenează în zona client a ferestrei o grilă formată din linii aflate la distanţa de 100 de pixeli una de alta, începând
din colţul din stânga-sus. Variabila hwnd reprezintă variabila handle a ferestrei, hdc este variabila handle a contextului de dispozitiv, iar x şi y sunt
numere întregi:
GetClientRect (hwnd, &rect);
for (x = 0 ; x < rect.right ; x +=100)
MoveToEx (hdc, x, 0, NULL) ;
LineTo (hdc, x, rect.bottom) ;
for (y = 0 ; y < rect.bottom ; y +=100)
MoveToEx (hdc, 0, y. NULL) ;
LineTo (hdc, rect.right, y) ;
Deşi pare incomodă folosirea a două funcţii pentru desenarea unei singure linii, poziţia curentă devine utilă atunci când trebuie să desenaţi o serie
de linii conectate. De exemplu, să presupunem că definiţi o matrice de cinci puncte (10 valori) care marchează un dreptunghi:
POINT pt [5] = { 100, 100, 200, 100, 200, 200, 100, 200, 100, 100 } ;
Remarcaţi faptul că ultimul punct este acelaşi cu primul. Acum trebuie doar să folosiţi funcţia MoveToEx pentru primul punct şi apoi funcţia LineTo
pentru punctele următoare:
MoveToEx (hdc, pt[0].x, pt[0].y, NULL) ;
for (i = 1; i < 5; i++) LineTo (hdc, pt[i].x, pt[i].y) ;
Deoarece funcţia LineTo desenează o linie care începe la punctul curent şi se termină la punctul specificat la apelare (exclusiv acesta), nici una dintre
coordonate nu este scrisă de două ori de codul de mai sus. Deşi suprascrierea unui punct nu este, în mod normal, o problemă în cazul monitoarelor
video, s-ar putea să nu aibă un rezultat prea plăcut în cazul unui plotter sau în alte moduri de afişare (despre care vom discuta în curând).
Atunci când aveţi o matrice de puncte pe care vreţi să le conectaţi prin linii, puteţi să desenaţi mai uşor liniile folosind funcţia Polyline. Instrucţiunea
de mai jos desenează acelaşi dreptunghi ca şi secvenţa de cod din exemplul anterior:
Polyline (hdc, pt, 5) ;
Ultimul parametru reprezintă numărul de puncte. Această valoare putea fi reprezentată şi prin expresia (sizeof(pt) / sizeof(POINT)). Funcţia Polyline
are acelaşi efect ca şi o funcţie MoveToEx urmată de mai multe funcţii LineTo, exceptând faptul că funcţia Polyline nu schimbă poziţia curentă.
Funcţia PolylineTo este puţin diferită. Aceasta foloseşte ca punct de plecare poziţia curentă şi stabileşte ca poziţie curentă sfârşitul ultimei linii
desenate. Codul de mai jos desenează acelaşi dreptunghi folosit ca exemplu şi mai sus:
MoveToEx (hdc, pt[0].x, pt[0].y, NULL) ;
PolylineTo (hdc, pt + 1,4) ;
Deşi puteţi să folosiţi funcţiile Polyline şi PolylineTo şi pentru un număr mic de funcţii, acestea sunt mai utile atunci când desenaţi o curbă complexă
formată din sute sau chiar mii de linii. De exemplu, să presupunem că vreţi să desenaţi o sinusoidă. Programul SINEWAVE, prezentat în Figura 4-4,
vă arată cum să faceţi acest lucru.
/*-----------------------------------------
SINEWAVE.C -- Sine Wave Using Polyline

-----------------------------------------*/
#include <math.h>
#define NUM 1000
#define TWOPI (2 * 3.14159)
LRESULT CALLBACK WndProc (HWND, UINT, WPARAM, LPARAM) ;
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
PSTR szCmdLine, int iCmdShow)
{
static char szAppName[] = "SineWave" ;
HWND hwnd ;
MSG msg ;
hwnd = CreateWindow (szAppName, "Sine Wave Using Polyline",
WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT, CW_USEDEFAULT,
NULL, NULL, hInstance, NULL) ;
{
}
return msg.wParam ;
}
{
static int cxClient, cyClient ;
HDC hdc ;
int i ;
PAINTSTRUCT ps ;
POINT pt [NUM] ;
switch (iMsg)
{
case WM_SIZE:
cxClient = LOWORD (lParam) ;
cyClient = HIWORD (lParam) ;
return 0 ;
case WM_PAINT:
MoveToEx (hdc, 0, cyClient / 2, NULL) ;
LineTo (hdc, cxClient, cyClient / 2) ;
for (i = 0 ; i < NUM ; i++)
{
pt[i].x = i * cxClient / NUM ;
pt[i].y = (int) (cyClient / 2 *
(1 - sin (TWOPI * i / NUM))) ;
}
Polyline (hdc, pt, NUM) ;
return 0 ;
case WM_DESTROY:
return 0 ;
}
}
Figura 4-4. Programul SINEWAVE
Acest program conţine o matrice cu 1000 de structuri POINT. Odată cu incrementarea variabilei de ciclare a ciclului for de la 0 la 999 este
incrementată şi variabila membru x de la 0 la cxClient. Variabila membru y a structurii primeşte valorile corespunzătoare unui ciclu al unei sinusoide
lărgite astfel încât să umple zona client. Curba este desenată cu funcţia Polyline. Deoarece funcţia Polyline este implementată la nivelul driverului,
desenarea se face mult mai repede decât dacă ar fi fost apelată de 1000 de ori funcţia LineTo. Rezultatele programului sunt prezentate în Figura 4-
5.
Figura 4-5. Fereastra afişată de programul SINEWAVE.
Dreptunghiuri de încadrare
În continuare aş vrea să discutăm despre funcţia Arc, funcţie care desenează o curbă eliptică. Dar funcţia Arc nu prea are sens dacă nu discutăm mai
întâi despre funcţia Ellipse, care, la rândul ei, nu are sens fără o discuţie despre funcţia Rectangle. Si dacă discutăm despre funcţiile Rectangle şi
Ellipse, putem la fel de bine să discutăm şi despre funcţiile RoundRect, Chord şi Pie.
Problema este că funcţiile Rectangle, Ellipse, RoundRect, Chord şi Pie nu sunt tocmai nişte funcţii de desenare a liniilor. Desigur, ele desenează şi linii,
dar şi colorează zona închisă, cu pensula curentă de colorare a suprafeţelor. În mod prestabilit, această pensulă are culoarea albă, aşa că s-ar putea
ca operaţia să nu fie atât de evidentă atunci când încercaţi pentru prima dată să utilizaţi aceste funcţii. Deşi, în sens strict, funcţiile aparţin unei alte
secţiuni din capitolul de faţă, „Desenarea suprafeţelor pline", vom discuta acum despre fiecare.
Funcţiile de mai sus sunt asemănătoare prin faptul că sunt construite pe baza unui „dreptunghi de încadrare" („bounding box"). Dumneavoastră
definiţi o casetă care încadrează obiectul - dreptunghiul de încadrare - şi Windows desenează obiectul în acest dreptunghi.
Cea mai simplă dintre aceste funcţii desenează un dreptunghi:
Rectangle (hdc, xLeft, yTop, xRight, yBottom) ;
Punctul (xLeft, yTop) reprezintă colţul din stânga-sus al dreptunghiului, iar punctul (xRight, yBottom) reprezintă colţul din dreapta-jos. O figură
desenată prin apelarea funcţiei Rectangle e prezentată în Figura 4-6. Laturile dreptunghiului sunt întotdeauna paralele cu laturile orizontală şi
verticală ale ecranului.
Figura 4-6. O figură desenată folosind funcţia Rectangle.
Programatorii care au mai lucrat cu sisteme grafice sunt deja familiarizaţi probabil cu problema pixelului suplimentar. Unele sisteme grafice
desenează figurile astfel încât să includă şi coordonatele din dreapta şi de jos, iar alte sisteme grafice desenează figurile până la aceste coordonate
(fără să le includă). Windows foloseşte cea de-a doua metodă; voi prezenta în continuare o comparaţie, care vă va ajuta să înţelegeţi mai bine
mecanismul.
Să presupunem că avem următorul apel de funcţie:
Rectangle (hdc, 1, 1, 5, 4) ;
Am menţionat mai sus faptul că Windows desenează figura într-un dreptunghi de încadrare. Puteţi să vă gândiţi la ecran ca la o grilă în care fiecare
pixel este o celulă delimitată de liniile grilei. Caseta de încadrare imaginară este desenată pe grilă, apoi dreptunghiul este desenat în limitele
casetei. Iată cum va fi desenată figura respectivă:
Zona care separă dreptunghiul de marginile din stânga şi de sus ale zonei client are lăţimea de un pixel. Windows foloseşte pensula curentă pentru
colorarea celor doi pixeli din interiorul dreptunghiului.
După ce aţi aflat cum se desenează un dreptunghi, folosind aceiaşi parametri, veţi putea, la fel de simplu, să desenaţi şi o elipsă:
Ellipse (hdc, xLeft, yTop, xRight, yBottom) ;
În Figura 4-7 este prezentată o figură (împreună cu dreptunghiul de încadrare) desenată cu ajutorul funcţiei Ellipse.
Funcţia pentru desenarea unui dreptunghi cu colţurile rotunjite foloseşte acelaşi dreptunghi de încadrare ca şi funcţiile Rectangle şi Ellipse, dar are
încă doi parametri:
RoundRect (hdc, xLeft, yTop, xRight, yBottom, xCornerEllipse, yCornerEllipse) ;
În Figura 4-8 este prezentată o figură desenată cu această funcţie.
Pentru desenarea colţurilor rotunjite, Windows foloseşte o mică elipsă. Lăţimea elipsei este xCornerEllipse iar înălţimea acesteia este yCornerEllipse.
Imaginaţi-vă că Windows împarte elipsa în patru părţi egale, folosind fiecare sfert pentru câte un colţ al dreptunghiului. Colţurile dreptunghiului
sunt cu atât mai rotunjite cu cât valorile parametrilor xCornerEllipse şi yCornerEllipse sunt mai mari. Dacă xCornerEllipse este egal cu jumătate din
diferenţa dintre xLeft şi xRight iar yCornerEllipse este egal cu jumătate din diferenţa dintre yTop şi yBottom, atunci funcţia RoundRect va desena o
elipsă.
Colţurile rotunjite ale dreptunghiului din Figura 4-8 au fost desenate folosind o elipsă ale cărei dimensiuni au fost calculate cu următoarele formule:
xCornerEllipse = (xRight - xLeft) / 4 ;
yCornerEllipse = (yTop - yBottom) / 4 ;
Aceasta este o abordare simplistă, iar rezultatele nu arată foarte bine, deoarece rotunjirea colţurilor este mai pronunţată pe latura mai mare a
dreptunghiului. Pentru corectarea acestei probleme, probabil veţi stabili dimensiuni reale pentru parametrii xCornerEllipse şi yCornerEllipse.
Funcţiile Arc, Chord şi Pie primesc aceiaşi parametri:
Arc (hdc, xLeft, yTop, xRight, yBottom, xStart, yStart, xEnd, yEnd) ;
Chord (hdc, xLeft, yTop, xRight, yBottom, xStart, yStart, xEnd, yEnd) ;
Pie (hdc, xLeft, yTop, xRight, yBottom, xStart, yStart, xEnd, yEnd) ;
În Figura 4-9 este prezentată o linie desenată cu ajutorul funcţiei Arc; Figurile 4-10 şi 4-11 prezintă desene realizate cu ajutorul funcţiilor Chord şi
Pie. Windows foloseşte o linie imaginară ca să lege punctul definit de coordonatele xStart, yStart cu centrul elipsei. Din punctul în care această linie
intersectează dreptunghiul de încadrare, Windows începe să deseneze o linie pe circumferinţa elipsei. De asemenea, Windows foloseşte o linie
imaginară ca să lege punctul (xEnd, yEnd) cu centrul elipsei. În punctul în care această linie intersectează dreptunghiul de încadrare, Windows
încheie desenul.
În cazul funcţiei Arc, Windows şi-a terminat treaba, deoarece arcul este o linie eliptică, nu o suprafaţă plină. În cazul funcţiei Chord, Windows uneşte
capetele arcului, iar în cazul funcţiei Pie, uneşte capetele arcului cu centrul elipsei. Interioarele suprafeţelor închise obţinute astfel sunt colorate cu
pensula curentă.
S-ar putea să vă întrebaţi de ce trebuie să folosiţi aceste poziţii de început şi de sfârşit în funcţiile Arc, Chord şi Pie. De ce să nu specificaţi chiar
punctele de început şi de sfârşit ale arcului pe circumferinţa elipsei? Ei bine, puteţi să o faceţi, dar mai întâi trebuie să determinaţi unde se află
aceste puncte, pe când metoda folosită de Windows rezolvă problema fără să fie nevoie de o asemenea precizie.
Programul LINEDEMO prezentat în Figura 4-12 desenează un dreptunghi, o elipsă, un dreptunghi cu colţurile rotunjite şi două linii, dar nu în
această ordine. Programul demonstrează faptul că funcţiile care desenează suprafeţe închise colorează aceste suprafeţe, deoarece liniile desenate
anterior sunt ascunse în spatele elipsei. Rezultatele rulării programului LINEDEMO sunt prezentate în Figura 4-13.
/*--------------------------------------------------
LINEDEMO.C -- Line-Drawing Demonstration Program
--------------------------------------------------*/
{
static char szAppName[] = "LineDemo" ;
HWND hwnd ;
MSG msg ;
hwnd = CreateWindow (szAppName, "Line Demonstration",
{
}
return msg.wParam ;
}
{
static int cxClient, cyClient ;
HDC hdc ;

PAINTSTRUCT ps ;
switch (iMsg)
{
case WM_SIZE:
return 0 ;
case WM_PAINT:
Rectangle (hdc, cxClient / 8, cyClient / 8,
7 * cxClient / 8, 7 * cyClient / 8) ;
MoveToEx (hdc, 0, 0, NULL) ;
LineTo (hdc, cxClient, cyClient) ;
MoveToEx (hdc, 0, cyClient, NULL) ;
LineTo (hdc, cxClient, 0) ;
Ellipse (hdc, cxClient / 8, cyClient / 8,
7 * cxClient / 8, 7 * cyClient / 8) ;
RoundRect (hdc, cxClient / 4, cyClient / 4,
3 * cxClient / 4, 3 * cyClient / 4,
cxClient / 4, cyClient / 4) ;
return 0 ;
case WM_DESTROY:
return 0 ;
}
}
Figura 4-12. Programul LINEDEMO.
Curbe Bezier (Bezier splines)
Termenul „spline" se referea odată la o riglă flexibilă din lemn, metal sau cauciuc (florar), folosită pentru desenarea curbelor. De exemplu, dacă
aveaţi un număr de puncte aparţinând unui grafic şi doreaţi să desenaţi o curbă între acestea (prin interpolare sau extrapolare) trebuia să marcaţi
mai întâi punctele pe hârtie. Ancorând apoi rigla în punctele respective, nu vă rămânea decât să trasaţi curba de-a lungul riglei. (Vă rog să nu râdeţi.
Metoda evocată seamănă cu practici utilizate în secolul trecut, dar eu ştiu din proprie experienţă că riglele mecanice şi riglele de calcul erau încă
folosite în anumite instituţii acum 15 ani.)
Figura 4-13. Fereastra afişată de programul LINEDEMO.
În prezent, „spline" se referă la o funcţie matematică. Aceste funcţii au diferite forme. Curbele Bezier sunt unele dintre cele mai cunoscute pentru
programarea grafică. Această funcţie este o achiziţie destul de recentă în arsenalul instrumentelor grafice de lucru disponibile la nivelul sistemului
de operare şi are o origine mai puţin obişnuită. În anii '60, compania de automobile Renault trecea de la proiectarea manuală a caroseriilor (care
implica folosirea argilei) la o proiectare asistată de calculator. Erau necesare instrumente matematice, iar Pierre Bezier a pus la punct un set de
formule care s-au dovedit foarte utile pentru rezolvarea acestei probleme.
De atunci, datorită formei bidimensionale, curba Bezier s-a dovedit a fi cea mai utilă curbă pentru grafica pe calculator. De exemplu, în limbajul
PostScript funcţiile Bezier sunt folosite pentru toate curbele - elipsele sunt aproximare prin curbe Bezier De asemenea, funcţiile Bezier sunt folosite
pentru definirea contururilor caracterelor din fonturile PostScript. (Fonturile TrueType folosesc o formă simplificată, mai rapida, a curbelor.)
O curbă Bezier este definită prin patru puncte - două capete şi două puncte de control. Capetele curbei sunt ancorate în cele două puncte finale.
Punctele de control acţionează ca nişte „magneţi" care deformează linia dreaptă dintre cele două puncte finale. Acest lucru este ilustrat cel mai bine
de un program interactiv, numit Bezier prezentat în Figura 4-14.
/*---------------------------------------
BEIZER.C -- Bezier Splines Demo
---------------------------------------*/
{
static char szAppName[] = "Bezier" ;
HWND hwnd ;
MSG msg ;
hwnd = CreateWindow (szAppName, "Bezier Splines",
{
}
return msg.wParam ;
}
void DrawBezier (HDC hdc, POINT apt[])
{
PolyBezier (hdc, apt, 4) ;
MoveToEx (hdc, apt[0].x, apt[0].y, NULL) ;
LineTo (hdc, apt[1].x, apt[1].y) ;
MoveToEx (hdc, apt[2].x, apt[2].y, NULL) ;
LineTo (hdc, apt[3].x, apt[3].y) ;
}
{
static POINT apt[4] ;
HDC hdc ;
int cxClient, cyClient ;
PAINTSTRUCT ps ;
switch (iMsg)
{
case WM_SIZE:

apt[0].x = cxClient / 4 ;
apt[0].y = cyClient / 2 ;
apt[2].y = 3 * cyClient / 4 ;
apt[3].x = 3 * cxClient / 4 ;
return 0 ;
case WM_MOUSEMOVE:
if (wParam & MK_LBUTTON || wParam & MK_RBUTTON)
{
hdc = GetDC (hwnd) ;
SelectObject (hdc, GetStockObject (WHITE_PEN)) ;
DrawBezier (hdc, apt) ;
if (wParam & MK_LBUTTON)
{
apt[1].x = LOWORD (lParam) ;
apt[1].y = HIWORD (lParam) ;
}
if (wParam & MK_RBUTTON)
{
apt[2].x = LOWORD (lParam) ;
apt[2].y = HIWORD (lParam) ;
}
SelectObject (hdc, GetStockObject (BLACK_PEN)) ;
ReleaseDC (hwnd, hdc) ;
}
return 0 ;
case WM_PAINT:
InvalidateRect (hwnd, NULL, TRUE) ;
return 0 ;
case WM_DESTROY:
return 0 ;
}
}
Figura 4-14. Programul BEZIER.
Deoarece acest program foloseşte unele tehnici de prelucrare a mesajelor de la mouse pe care le vom studia abia în Capitolul 6, nu vom discuta
modul intern de lucru al programului (deşi acesta poate să vi se pară evident). În schimb, puteţi să folosiţi programul ca să experimentaţi modul de
funcţionare a curbelor Bezier. În acest program, cele două puncte finale ale curbei sunt stabilite, pe verticală, la jumătatea zonei client şi, pe
orizontală, la 1/4 şi 3/4 din lăţimea zonei client. Cele două puncte de control pot fi mutate, primul - apăsând butonul din stânga al mouse-ului şi
deplasând mouse-ul până când indicatorul Iui ajunge în locul dorit, iar al doilea -apăsând butonul din dreapta al mouse-ului şi deplasând mouse-
ul. Figura 4-15 prezintă un rezultat tipic.
În afara curbei Bezier, programul desenează şi două linii drepte: una de la primul capăt al curbei (cel din stânga) până la primul punct de control, şi
a doua de la celălalt capăt al curbei (din dreapta) până la al doilea punct de control.
Funcţiile Bezier sunt considerate utile pentru proiectarea asistată de calculator, datorită câtorva caracteristici:
În primul rând, cu puţină practică, de obicei puteţi să manipulaţi curba până ajunge la o formă apropiată de cea dorită.
În al doilea rând, curbele Bezier sunt foarte uşor de controlat. În unele variante ale funcţiilor spline, curba nu trece prin nici unul din punctele care o
definesc. Curbele Bezier, însă, sunt întotdeauna ancorate în cele două puncte finale. (Aceasta este una dintre ipotezele de la care porneşte calculul
formulei Bezier.) De asemenea, unele forme ale funcţiilor spline au puncte de singularitate, din care curba se întinde la infinit. În proiectarea asistată
de calculator acest lucru este de cele mai multe ori evitat. Ca urmare, curbele Bezier sunt întotdeauna limitate de un patrulater (numit „carcasă
convexă" - „convex hull") format prin unirea punctelor finale şi a punctelor de control.
În al treilea rând, o altă caracteristică a curbelor Bezier implică relaţiile dintre punctele finale şi punctele de control. Curba este întotdeauna
tangentă la linia trasată de la primul punct final la primul punct de control şi are întotdeauna aceeaşi direcţie cu această linie. (Această caracteristică
este ilustrată vizual de programul BEZIER.) De asemenea, curba este întotdeauna tangentă la linia trasată de la al doilea punct final la al doilea
punct de control şi are întotdeauna aceeaşi direcţie cu această linie. (Acestea sunt alte două ipoteze de la care este derivată formula Bezier.)
În al patrulea rând, curbele Bezier sunt satisfăcătoare şi din punct de vedere estetic. Ştiu că acesta este un criteriu subiectiv, dar nu este numai
părerea mea.
Înainte de apariţia sistemului de operare Windows 95, trebuia să creaţi propriile curbe Bezier folosind funcţia Polyline. De asemenea, trebuia să
cunoaşteţi următoarele ecuaţii parametrice ale curbelor Bezier:
x(t) = (1-t)3x0 + 3t(1-t)2x1 + 3t2(1-t)x2 + t3x3
y(t) = (1-t)3y0 + 3t(1-t)2y1 + 3t2(1-t)y2 + t3y3
unde (x0, y0) este punctul de început al curbei, (x3, y3) este punctul de sfârşit al curbei, iar cele două puncte de control sunt (x1, y1) şi (x2, y2). Curba
este trasată pentru t având valori de la 0 la 1.
Figura 4-15. Fereastra afişată de programul BEZIER.
În Windows 95 nu mai este nevoie să ştiţi aceste formule. Pentru trasarea uneia sau a mai multor curbe Bezier conexe, puteţi să folosiţi
instrucţiunea:
PolyBezier (hdc, pt, iCount) ;
sau instrucţiunea:
PolyBezierTo (hide, pt, iCount) ;
În ambele cazuri, pt este o matrice de structuri POINT. Pentru funcţia PolyBezier primele patru puncte specifică (în această ordine) punctul de
început, primul punct de control, al doilea punct de control şi punctul final al curbei Bezier. Următoarele curbe Bezier au nevoie doar de trei puncte,
deoarece punctul de început al următoarei curbe Bezier este punctul de sfârşit al primei curbe, şi aşa mai departe. Parametrul iCount reprezintă
numărul de puncte din matrice, adică unu plus de trei ori numărul curbelor pe care vreţi să le desenaţi.
Funcţia PolyBezierTo foloseşte poziţia curentă ca punct de început pentru prima curbă Bezier. Fiecare curbă desenată are nevoie doar de trei
puncte. La returnarea funcţiei, poziţia curentă este punctul final al ultimei curbe desenate.
Atenţie: atunci când trasaţi o serie de curbe Bezier conectate între ele, legătura va fi lină numai dacă al doilea punct de control al primei curbe,
punctul de sfârşit al primei curbe (care este şi punctul de început al celei de-a doua curbe) şi primul punct de control al celei de-a doua curbe sunt
coliniare, adică se află pe aceeaşi linie dreaptă.
Folosirea peniţelor de stoc
Atunci când apelaţi oricare dintre funcţiile de desenare a liniilor despre care am discutat, Windows foloseşte pentru desenarea liniilor „peniţa" (pen)
curentă selectată în contextul de dispozitiv. Peniţa selectată determină culoarea, lăţimea şi tipul de linie (acestea pot fi continue, punctate sau
întrerupte). Peniţa din contextul prestabilit de dispozitiv se numeşte BLACK_PEN. Aceasta desenează o linie compactă, de culoare neagră, cu
grosimea de un pixel, indiferent de modul de mapare. BLACK_PEN este una dintre cele trei peniţe „de stoc" (stock pen) furnizate de Windows.
Celelalte două peniţe de stoc sunt WHITE_PEN şi NULL_PEN. NULL_PEN este o peniţă care nu desenează nimic. În plus, puteţi să creaţi peniţe
proprii.
În programele Windows puteţi ajunge la aceste peniţe prin variabile handle. În fişierele antet din Windows este definit tipul de date HPEN, care
reprezintă o variabilă handle a unei peniţe. Puteţi să definiţi o variabilă (de exemplu, hPen) folosind această definiţie de tip:
HPEN hPen ;
Puteţi să obţineţi variabila handle a uneia dintre peniţele de stoc apelând funcţia GetStockObject. De exemplu, să presupunem că vreţi să folosiţi
peniţa de stoc numită WHITE_PEN. Obţineţi variabila handle a acesteia astfel:
hPen = GetStockObject (WHITE_PEN) ;
Apoi trebuie să selectaţi în contextul de dispozitiv peniţa a cărei variabilă aţi obţinut-o, apelând funcţia SelectObject:
SelectObject (hdc, hPen) ;
După acest apel toate liniile pe care le desenaţi vor folosi peniţa WHITE_PEN, până când selectaţi o altă peniţă în contextul de dispozitiv sau ştergeţi
contextul de dispozitiv.
În loc să definiţi explicit variabila hPen, puteţi să combinaţi funcţiile GetStockObject şi SelectObject într-o singură instrucţiune:
SelectObject (hdc, GetStockObject (WHITE_PEN)) ;
Dacă apoi vreţi să reveniţi la peniţa BLACK_PEN, puteţi să obţineţi o variabilă handle a acesteia şi să o selectaţi în contextul de dispozitiv tot cu o
singură instrucţiune:
SelectObject (hdc, GetStockObject (WHITE_PEN));
Funcţia SelectObject returnează variabila handle a peniţei selectate anterior în contextul de dispozitiv. Dacă deschideţi un nou context de dispozitiv
şi executaţi instrucţiunea:
hPen = SelectObject (hdc, GetStockObject (WHITE_PEN)) ;
atunci peniţa curentă selectată în contextul de dispozitiv va fi WHITE_PEN şi hPen va fi variabila handle a peniţei BLACK_PEN. Puteţi apoi să selectaţi
peniţa BLACK_PEN în contextul de dispozitiv cu următoarea instrucţiune:
SelectObject (hdc, hPen) ;
Crearea, selectarea şi ştergerea peniţelor

Deşi folosirea peniţelor definite ca obiecte de stoc este foarte convenabilă, aveţi la dispoziţie doar un număr limitat de opţiuni: o peniţă neagră,
pentru linie continuă, una albă pentru linie continuă sau una care nu desenează nimic. Dacă doriţi ceva diferit, trebuie să creaţi propriile
dumneavoastră peniţe. Iată procedura generală: creaţi mai întâi o „peniţă logică" (logical pen) care este doar o descriere a unei peniţe, folosind
funcţiile CreatePen sau CreatePenIndirect. (De asemenea, puteţi să folosiţi şi funcţia ExtCreatePen, despre care vom discuta atunci când vom ajunge
la căile GDI.) Aceste funcţii returnează o variabilă handle a peniţei logice. Selectaţi peniţa în contextul de dispozitiv apelând funcţia SelectObject.
Apoi puteţi să desenaţi linii cu peniţa selectată. La un moment dat nu poate fi selectată, într-un context de dispozitiv, decât o peniţă. După ce
ştergeţi contextul de dispozitiv (sau după ce selectaţi o altă peniţă în contextul de dispozitiv) puteţi să ştergeţi peniţa logică pe care aţi creat-o
apelând funcţia DeleteObject. După ce faceţi acest lucru, variabila handle a peniţei nu mai este validă.
O peniţă logică este un „obiect GDI". Dumneavoastră creaţi şi folosiţi peniţa, dar aceasta nu aparţine programului, ci modulului GDI. Peniţa este
unul dintre cele şase obiecte GDI pe care puteţi să le creaţi. Celelalte cinci sunt pensulele, imaginile bitmap, regiunile, fonturile şi paletele.
Exceptând paletele, toate celelalte obiecte pot fi selectate în contextul de dispozitiv folosind funcţia SelectObject.
Pentru folosirea obiectelor GDI trebuie să respectaţi următoarele reguli:
Ø La sfârşitul programului ştergeţi toate obiectele GDI pe care le-aţi creat.
Ø Nu ştergeţi obiectele GDI în timp ce sunt selectate într-un context de dispozitiv valid.
Ø Nu ştergeţi obiectele de stoc.
Chiar dacă sunt nişte reguli rezonabile, neplăcerile pot exista. Voi prezenta câteva exemple ca să înţelegeţi cum funcţionează aceste reguli şi pentru
a putea evita eventuale probleme.
Sintaxa generică a funcţiei CreatePen este:
hPen = CreatePen (iPenStyle, iWidth, rgbColor) ;
Parametrul iPenStyle precizează dacă se desenează o linie continuă, o linie punctată sau una întreruptă. Parametrul iPenStyle poate fi unul dintre
identificatorii definiţi în fişierele antet din Windows. Figura 4-16 prezintă stilul de linie produs de fiecare identificator.
Figura 4-16. Cele şapte stiluri de peniţe.
Pentru stilurile PS_SOLID, PS_NULL şi PS_INSIDEFRAME, parametrul iWidth reprezintă grosimea liniei. Dacă iWidth are valoarea 0, liniile desenate de
Windows vor avea grosimea de un pixel. Liniile desenate cu peniţele de stoc au grosimea de un pixel. Dacă parametrul iWidth are o valoare mai
mare de 1, Windows va desena o linie continuă.
Parametrul rgbColor din funcţia CreatePen este un număr întreg fără semn reprezentând culoarea peniţei. Pentru toate stilurile de peniţe, exceptând
PS_INSIDEFRAME, atunci când selectaţi peniţa în contextul de dispozitiv, Windows converteşte acest parametru la cea mai apropiată culoare pură
pe care o poate reprezenta dispozitivul de afişare. PS_INSIDEFRAME este singurul stil care poate folosi culori amestecate, dar numai pentru grosimi
mai mari de un pixel.
Stilul PS_INSIDEFRAME are şi o altă particularitate atunci când este folosit pentru funcţii care definesc o suprafaţă plină: pentru toate stilurile de
peniţe, exceptând PS_INSIDEFRAME, dacă grosimea liniei este mai mare de un pixel, peniţa este centrată pe linie, astfel încât o parte a liniei poate
să fie desenată în afara dreptunghiului de încadrare; în cazul folosirii stilului PS_INSIDEFRAME, linia este desenată în întregime în interiorul
dreptunghiului de încadrare.
Puteţi să creaţi o peniţă şi cu ajutorul unei structuri de tip LOGPEN („logical pen"), apelând funcţia CreatePenIndirect. Dacă programul foloseşte un
număr mai mare de peniţe diferite pe care Ie iniţializaţi în codul sursă, această metodă este mai eficientă. Mai întâi definiţi o variabilă de tip
LOGPEN, cum ar fi logpen:
LOGPEN logpen ;
Această structură are trei membri: lopnStyle (UINT) este stilul peniţei, lopn Width (POINT) este grosimea peniţei în unităţi logice, iar lopnColor
(COLORREF) este culoarea peniţei. Membrul lopn Width este o structură de tip POINT, dar Windows foloseşte numai membrul lopnWidth.x al
acestei structuri şi ignoră membrul lopnWidth.y. Apoi creaţi peniţa, transmiţând funcţiei CreatePenIndirect adresa structurii logpen:
hPen = CreatePenIndirect (&logpen) ;
De asemenea, puteţi să obţineţi informaţii despre o peniţă logică existentă. Dacă aveţi deja o variabilă handle a unei peniţe puteţi să copiaţi datele
care definesc peniţa logică într-o structură de tip LOGPEN folosind funcţia GetObject:
GetObject (hPen, sizeof (LOGPEN), (LPVOID) &logpen) ;
Remarcaţi faptul că funcţiile CreatePen şi CreatePenIndirect nu au nevoie de o variabilă handle a contextului de dispozitiv. Aceste funcţii creează
peniţe logice care nu au nici o legătură cu contextul de dispozitiv până când nu apelaţi funcţia SelectObject. De exemplu, puteţi să folosiţi aceeaşi
peniţă logică pentru mai multe dispozitive, cum ar fi imprimanta şi ecranul.
Iată o metodă pentru crearea, selectarea şi ştergerea peniţelor. Să presupunem că programul foloseşte trei peniţe: una neagră cu grosimea de un
pixel, una roşie cu grosimea de trei pixeli şi una neagră cu linie punctată. Mai întâi definiţi variabilele pentru stocarea variabilelor handle ale celor
trei stilouri:
static HPEN hPen1, hPen2, hPen3;
În timpul prelucrării mesajului WM_CREATE, creaţi cele trei peniţe:
hPen1 = CreatePen (PS_SOLID, 1, 0);
hPen2 = CreatePen (PS_SOLID, 3, RGB (255, 0, 0));
hPen3 = CreatePen (PS_DOT, 0, 0);
În timpul prelucrării mesajului WM_PAINT (sau în orice alt moment în care aveţi o variabilă handle validă a contextului de dispozitiv) puteţi să
selectaţi oricare dintre aceste peniţe în contextul de dispozitiv şi să desenaţi:
SelectObject (hdc, hPen2) ;
[funcţii de desenare a liniilor]
SelectObject (hdc, hPen1) ;
[alte funcţii de desenare a liniilor]
În timpul prelucrării mesajului WM_DESTROY puteţi să ştergeţi cele trei peniţe create:
DeleteObject (hPen1) ;
Aceasta este metoda cea mai directă pentru crearea, selectarea şi ştergerea peniţelor, dar are dezavantajul că peniţele create ocupă spaţiu în
memorie pe toată durata rulării programului. O altă soluţie este să creaţi peniţele necesare în timpul prelucrării fiecărui mesaj WM_PAINT şi să le
ştergeţi după apelarea funcţiei EndPaint. (Puteţi să le ştergeţi şi înainte de apelarea funcţiei EndPaint, dar trebuie să aveţi grijă să nu ştergeţi peniţa
curentă selectată în contextul de dispozitiv.)
De asemenea, puteţi să creaţi peniţele atunci când sunt necesare, combinând funcţiile CreatePen şi SelectObject în aceeaşi instrucţiune:
SelectObject (hdc, CreatePen (PS_DASH, 0, RGB (255, 0, 0))) ;
Din acest moment, veţi folosi o peniţă pentru linii întrerupte de culoare roşie. După ce terminaţi de făcut desenele cu acest tip de linie, puteţi să
ştergeţi peniţa. Hopa! Cum puteţi să ştergeţi peniţa dacă nu aţi salvat variabila handle a acesteia? Vă amintiţi că funcţia SelectObject returnează
variabila handle a peniţei selectate anterior în contextul de dispozitiv. Aşa că puteţi să ştergeţi peniţa selectând în contextul de dispozitiv peniţa de
stoc BLACK_PEN şi ştergând variabila handle returnată de funcţia SelectObject:
DeleteObject (SelectObject (hdc, GetStockObject (BLACK PEN))) ;
Există şi o altă metodă. Atunci când selectaţi în contextul de dispozitiv o peniţă nou creată, salvaţi variabila handle returnată de funcţia SelectObject;
hPen = SelectObject (hdc, CreatePen (PS_DASH, 0, RGB (255, 0, 0))) ;
Ce este hPen? Dacă aceasta este prima apelare a funcţiei SelectObject de la obţinerea contextului de dispozitiv, atunci hPen este variabila handle a
obiectului de stoc BLACK_PEN. Puteţi acum să selectaţi peniţa BLACK_PEN în contextul de dispozitiv şi să o ştergeţi pe cea creată (variabila handle
returnată la a doua apelare a funcţiei SelectObject) printr-o singură instrucţiune:
DeleteObject (SelectObject (hdc, hPen)) ;
Umplerea golurilor
Folosirea peniţelor pentru linii punctate sau pentru linii întrerupte ridică o întrebare interesantă: ce se întâmplă cu pauzele dintre puncte sau dintre
liniuţe? Culoarea acestor spaţii depinde de atributele pentru culoarea fondului şi de modul de desenare a fondului, definite în contextul de
dispozitiv.
Modul prestabilit de desenare a fondului este OPAQUE, ceea ce înseamnă că Windows umple spaţiile cu culoarea fondului, care în mod prestabilit
este alb. Rezultatele sunt aceleaşi în cazul pensulei WHITE_BRUSH, folosită de majoritatea programelor în clasa ferestrei pentru ştergerea fondului.
Puteţi să schimbaţi culoarea fondului pentru completarea spaţiilor goale dintre linii, prin apelarea funcţiei SetBkColor:
SetBkColor (hdc, rgbColor) ;
Ca şi în cazul valorii rgbColor folosită pentru culoarea peniţei, Windows converteşte valoarea specificată într-o culoare pură. Puteţi să obţineţi
culoarea definîtă în contextul de dispozitiv prin apelarea funcţiei GetBkColor.
De asemenea, puteţi să împiedicaţi colorarea spaţiilor stabilind modul TRANSPARENT de desenare a fondului:
SetBkMode (hdc, TRANSPARENT) ;
Windows va ignora culoarea fondului şi nu va mai colora spaţiile goale. Modul de desenare a fondului (TRANSPARENT sau OPAQUE) poate fi
obţinut cu ajutorul funcţiei GetBkMode.
Moduri de desenare
Apectul liniilor desenate pe ecran este afectat şi de modul de desenare definit în contextul de dispozitiv. Imaginaţi-vă că desenaţi o linie a cărei
culoare este bazată nu numai pe culoarea peniţei, ci şi pe culoarea originală a suprafeţei pe care se face desenarea. Imaginaţi-vă o cale prin care să
puteţi folosi aceeaşi peniţă ca să desenaţi o linie albă pe fond negru, dar şi o linie neagră pe fond alb, ştiind ce culoare are fondul. Dacă vă este
utilă această facilitate, puteţi să o obţineţi prin schimbarea modului de desenare.
Atunci când foloseşte o peniţă pentru desenarea unei linii, Windows face de fapt o operaţie booleană între pixelii peniţei şi pixelii de pe suprafaţa
destinaţie. Efectuarea operaţiei booleene între pixeli se numeşte „operaţie rastru" (ROP - raster operation).
Deoarece desenarea unei linii implică numai două modele de pixeli (peniţa şi destinaţia), operaţia booleană se numeşte „operaţie rastru binară" sau
ROP2. Windows defineşte 16 coduri ROP2 care specifică modul de combinare între pixelii peniţei şi pixelii suprafeţei, în contextul de dispozitiv
prestabilit, modul de desenare definit este R2_COPYPEN, ceea ce înseamnă că Windows copiază pixelii peniţei pe suprafaţa destinaţie - adică modul
normal în care suntem obişnuiţi să funcţioneze o peniţă. Există alte 15 coduri ROP2.
Care este originea celor 16 coduri ROP2 diferite? Pentru exemplificare, să presupunem că avem un sistem monocrom. Culoarea destinaţiei (culoarea
zonei client a ferestrei) poate fi negru (reprezentată prin valorea 0) sau alb (1). La fel, culoarea peniţei poate fi alb sau negru. Există patru combinaţii
posibile în cazul folosirii unei peniţe alb/negru pe o suprafaţă alb/negru: alb pe alb, alb pe negru, negru pe alb şi negru pe negru.
Ce se întâmplă cu destinaţia după ce desenaţi cu peniţa? O posibilitate este ca linia să fie desenată întotdeauna cu negru, indiferent de culoarea
peniţei şi a destinaţiei: acest mod de desenare este indicat de codul R2_BLACK. O altă posibilitate este ca linia să fie desenată cu negru, exceptând
situaţia în care atât peniţa cât şi destinaţia sunt negre, caz în care linia este desenată cu alb. Deşi pare puţin ciudat, Windows are un nume pentru
acest mod de desenare: R2_NOTMERGEPEN. Windows face o operaţie orientată pe biţi de tip SAU între pixelii destinaţie şi pixelii peniţei, şi
inversează rezultatul.
Tabelul de mai jos prezintă toate cele 16 moduri de desenare ROP2. Tabelul indică modul în care sunt combinate culoarea peniţei (P) şi culoarea
destinaţiei (D) pentru obţinerea culorii afişate. În coloana „Operaţia booleană" sunt folosite notaţiile C pentru indicarea modului în care sunt
combinaţi pixelii peniţei cu pixelii destinaţiei.
Peniţă (P): 1 1 0 0 Operaţia Mod de desenare

Destinaţie (D): booleană
1 0 1 0
Rezultate: 0 0 0 0 0 R2_BLACK
0 0 0 1 ~(P | D) R2_NOTMERGEPEN
0 0 1 0 ~P & D R2_MASKNOTPEN
0 0 1 1 ~P R2_NOTCOPYPEN
0 1 0 0 P & ~D R2_MASKPENNOT
0 1 0 1 ~D R2_NOT
0 1 1 0 P^D R2_XORPEN
0 1 1 1 ~(P & D) R2_NOTMASKPEN
1 0 0 0 P&D R2_MASKPEN
1 0 0 1 ~(P ^ D) R2_NOTXORPEN
1 0 1 0 D R2_NOP
1 0 1 1 ~P | D R2_MERGENOTPEN
1 1 0 0 P R2_COPYPEN
(prestabilit)
1 1 0 1 P | ~D R2_MERGEPENNOT
1 1 1 0 P|D R2_MERGEPEN
1 1 1 1 1 R2_WHITE
Puteţi să selectaţi un nou mod de desenare în contextul de dispozitiv astfel:
SetROP2 (hdc, iDrawMode) ;

unde parametrul iDrawMode este una dintre valorile din coloana „Mod de desenare" a tabelului de mai sus. Puteţi să obţineţi modul curent de
desenare astfel:
iDrawMode = GetROP2 (hdc) ;
Modul de desenare prestabilit al contextului de dispozitiv este R2_COPYPEN, care transferă la destinaţie culoarea peniţei. Modul R2_NOTCOPYPEN
desenează cu alb dacă peniţa este neagră şi cu negru dacă peniţa este albă. Modul R2_BLACK desenează întotdeauna cu negru, indiferent de
culoarea peniţei şi a destinaţiei. În mod similar, modul R2_WHITE desenează întotdeauna cu alb. Modul R2_NOP este o „operaţie nulă" - destinaţia
rămâne nemodificată.
Pentru început, am folosit ca exemplu un sistem monocrom. În realitate, pe un monitor monocrom Windows poate simula diferite tonuri de gri prin
amestecarea pixelilor albi cu cei negri. Atunci când desenează cu o peniţă pe un fond având culori amestecate, Windows execută o operaţie
orientată pe biţi pentru fiecare pixel. Modul R2_NOT inversează întotdeauna destinaţia, indiferent de culoarea acesteia şi de culoarea peniţei. Acest
mod de desenare este util atunci când nu cunoaşteţi culoarea destinaţiei, deoarece liniile vor fi întotdeauna vizibile. (Sau aproape întotdeauna,
pentru că în cazul unui fond 50% gri, liniile vor fi virtual invizibile.) Folosirea modului R2_NOT este ilustrată în programul BLOKOUT din Capitolul 6.
Desenarea suprafeţelor pline
Să mergem un pas mai departe şi să trecem la desenarea figurilor. Cele şapte funcţii Windows pentru desenarea figurilor sunt prezentate în tabelul
următor:
Funcţie Figura
Rectangle Dreptunghi cu colţuri drepte
Ellipse Elipsă

RoundRect Dreptunghi cu colţuri rotunjite
Chord Arc pe circumferinţa unei elipse, având capetele unite printr-o coardă
Pie Suprafaţă de forma unei felii de plăcintă, reprezentând un segment de

elipsă.
Polygon PolyPolygon
Figură geometrică având mai multe laturi Mai multe figuri geometrice cu
mai multe laturi
Windows desenează conturul figurilor folosind peniţa curentă selectată în contextul de dispozitiv. Pentru acest contur sunt folosite atributele
stabilite pentru modul de desenare a fondului, culoarea fondului şi modul de desenare, ca şi în cazul desenării unei linii simple. Tot ceea ce aţi
învăţat despre linii se aplică şi în cazul contururilor.
Figurile sunt umplute folosind pensula selectată în contextul de dispozitiv. În mod prestabilit, aceasta este pensula de stoc WHITE_BRUSH, ceea ce
înseamnă că interiorul figurilor va fi umplut cu alb. Windows defineşte şase pensule de stoc: WHITE_BRUSH, LTGRAY_BRUSH, GRAY_BRUSH,
DKGRAY_BRUSH, BLACK_BRUSH şi NULL_BRUSH (sau HOLLOW_BRUSH).
Puteţi să selectaţi una dintre aceste pensule în contextul de dispozitiv la fel cum selectaţi o peniţă de stoc. Windows defineşte tipul HBRUSH ca
variabilă handle a unei pensule, aşa că puteţi să definiţi mai întâi o variabilă de acest tip:
HBRUSH hBrush ;
Puteţi să obţineţi variabila handle a pensulei de stoc GRAY_BRUSH apelând funcţia GetStockObject:.
hBrush = GetStoCkObject (GRAY_BRUSH) ;
Puteţi să o selectaţi apoi în contextul de dispozitiv folosind funcţia SelectObject:
SelectObject (hdc, hBrush) ;
Din acest moment, figurile desenate vor avea interiorul gri.
Dacă vreţi să desenaţi o figură fără contur, selectaţi în contextul de dispozitiv peniţa NULL_PEN:
SelectObject (hdc, GetStockObject (NULL_PEN)) ;
Dacă vreţi să desenaţi o figură fără să îi umpleţi interiorul, selectaţi în contextul de dispozitiv pensula NULL_BRUSH:
SelectObject (hdc, GetStockObject (NULL_BRUSH)) ;
Aşa cum puteţi să creaţi peniţe proprii, puteţi să creaţi şi pensule proprii. Vom trata în curând şi acest subiect
Funcţia Polygon şi modul de umplere a poligoanelor
Am discutat deja despre primele cinci funcţii de desenare a suprafeţelor pline. Polygon este cea de-a şasea funcţie de desenare a unei figuri
colorate în interior, cu contur. Apelul funcţiei Polygon este asemănător cu cel al funcţiei Polyline:
Polygon (hdc, pt, iCount) ;

Parametrul pt este un pointer la o matrice de structuri POINT, iar iCount reprezintă numărul de puncte din matrice. Dacă ultimul punct din matrice
este diferit de primul punct, Windows mai desenează o linie care conectează ultimul şi primul punct. (Acest lucru nu se întâmplă şi în cazul funcţiei
Polyline.)
Suprafaţa închisă de poligon este colorată folosind pensula curentă în două moduri, în funcţie de modul de umplere a poligoanelor, definit în
contextul de dispozitiv. Modul prestabilit de umplere a poligoanelor este ALTERNATE, ceea ce înseamnă că Windows colorează numai suprafeţele
închise la care se poate ajunge din exteriorul poligonului prin traversarea unui număr impar de laturi (1, 3, 5 şi aşa mai departe). Celelalte suprafeţe
interioare nu sunt umplute. Dacă selectaţi WINDING ca mod de umplere, Windows colorează toate suprafeţele închise de poligon. Puteţi să
selectaţi modul de umplere cu ajutorul funcţiei SetPolyFillMode:
SetPolyFillMode (hdc, iMode) ;
Cele două moduri de umplere a poligoanelor sunt ilustrate cel mai bine pe modelul unei stele cu cinci colţuri. În Figura 4-17 steaua din partea
stângă a fost desenată cu modul de umplere ALTERNATE, iar steaua din partea dreaptă a fost desenată cu modul de umplere WINDING.
Figura 4-17. Figuri desenate cu cele două moduri de umplere a poligoanelor ALTERNATE (stângă) şi WINDING
Umplerea suprafeţelor interioare
Interiorul figurilor Rectangle, RoundRect, Ellipse, Chord, Pie, Polygon şi PollyPolygon este umplut cu pensula - numită uneori şi „model" („pattern") -
selectată în contextul de dispozitiv. O pensulă este de fapt o imagine bitmap 8x8 repetată pe verticală şi pe orizontală, pentru umplerea unei
suprafeţe.
Atunci când Windows foloseşte metoda amestecării culorilor (dithering) pentru afişarea unui număr mai mare de culori decât ar fi în mod normal
disponibile pe monitorul respectiv, de fapt foloseşte o pensulă pentru fiecare culoare. Pe un ecran monocrom, Windows poate să afişeze 64 de
tonuri de gri prin amestecarea pixelilor pentru alb cu cei pentru negru. Pentru negru toţi biţii din matricea 8x8 au valoarea zero. Unul dintre cei 64
de biţi are valoarea 1 (adică alb) pentru primul ton de gri, doi biţi au valoarea 1 pentru al doilea ton de gri şi aşa mai departe, până când toţi cei 64
de biţi au valoarea 1 ca să se obţină albul pur. În cazul unui monitor color, culorile amestecate sunt tot imagini bitmap, dar domeniul disponibil de
culori este mult mai mare.
Windows conţine patru funcţii pe care puteţi să le folosiţi pentru crearea pensulelor logice. Selectaţi o pensulă în contextul de dispozitiv folosind
funcţia SelectObject. Ca şi peniţele logice, pensulele logice sunt obiecte GDI. Trebuie să ştergeţi toate pensulele pe care le-aţi creat, dar nu trebuie
să le ştergeţi cât timp sunt selectate în contextul de dispozitiv.
Iată prima funcţie pentru crearea unei pensule logice:
hBrush = CreateSolidBrush (rgbColor) ;
Cuvântul Solid din numele acestei funcţii nu înseamnă că pensula foloseşte o culoare pură. Atunci când selectaţi pensula în contextul de dispozitiv,
Windows creează o imagine bitmap 8x8 pentru culorile amestecate şi foloseşte imaginea respectivă atunci când este necesară pensula selectată.
Puteţi să creaţi şi o pensulă „haşurată" cu linii orizontale, verticale sau oblice. Acest stil de pensule este folosit frecvent pentru colorarea barelor din
diagrame sau grafice şi pentru desenele executate de plottere. Funcţia care creează o pensulă haşurată este:
hBrush = CreateHatchBrush (iHatchStyle, rgbColor) ;
Parametrul iHatchStyle precizează aspectul haşurii şi poate avea una dintre următoarele valori: HS_HORIZONTAL, HS_VERTICAL, HS_FDIAGONAL,
HS_BDIAGONAL, HS_CROSS şi HS_DIAGCROSS. Figura 4-18 prezintă haşurile produse de fiecare dintre stilurile de mai sus.
Parametrul rgbColor din funcţia CreateHatchBrush reprezintă culoarea liniilor cu care se face haşurarea. Atunci când selectaţi pensula în contextul
de dispozitiv, Windows converteşte această culoare în cea mai apropiată culoare pură. Spaţiul dintre liniile de haşură sunt colorate în funcţie de
modul de desenare a fondului şi de culoarea fondului, definite în contextul de dispozitiv. Dacă modul de desenare a fondului este OPAQUE,
culoarea fondului (care este convertită, la rândul ei, într-o culoare pură) este folosită pentru umplerea spaţiilor dintre linii, în acest caz, nici liniile de
haşură, nici culoarea de umplere nu pot fi culori amestecate. Dacă modul de desenare a fondului este TRANSPARENT, Windows desenează liniile de
haşura fără să umple spaţiile dintre acestea.
Figura 4-18. Cele şase stiluri de haşura.
Deoarece pensulele sunt întotdeauna imagini bitmap 8x8, aspectul pensulelor haşurate va depinde de rezoluţia dispozitivului pe care se face
afişarea. Fiecare dintre haşurile din Figura 4-18 a fost desenată într-un dreptunghi de 32x16 pixeli, ceea ce înseamnă că imaginea bitmap 8x8 a fost
repetată de patru ori pe orizontală şi de două ori pe verticală. Pe o imprimantă laser cu rezoluţia 300 dpi (dots per inch) acelaşi dreptunghi de
32x16 pixeli ar ocupa o suprafaţă cu înălţimea de 1 /9 inci si lăţimea de 1/19 inci.
Cu ajutorul funcţiei CreatePatternBrush puteţi să creaţi pensule proprii, bazate pe o imagine bitmap:
hBrush = CreatePatternBrush (hBitmap) ;
Vom discuta despre această funcţie în secţiunea rezervată imaginilor bitmap din capitolul de faţă.
Windows conţine o funcţie care poate înlocui toate celelalte trei funcţii de creare a pensulelor (CreateSolidBrush, CreateHatchBrush şi
CreatePatternBrush):
hBrush = CreateBrushIndirect (&logbrush) ;
Variabila logbrush este o structură de tip LOGBRUSH („logical brush"). Cele trei câmpuri ale structurii sunt prezentate mai jos. Valoarea câmpului
lbStyle determină modul în care Windows interpretează celelalte două câmpuri:
lbStyle (UINT) lbColor (COLORREF) lbHatch (LONG)
BS_SOLID Culoarea pensulei Ignorat
BS_HOLLOW Ignorat Ignorat
BS_HATCHED Culoarea haşurii Stilul de haşură
BS_PATTERN Ignorat Variabila handle a unei imagini bitmap
Am folosit mai devreme funcţia SelectObject ca să selectăm în contextul de dispozitiv o peniţă logică, funcţia DeleteObject ca să ştergem o peniţă
logică şi funcţia GetObject ca să obţinem informaţii despre o peniţă logică. Puteţi să folosiţi aceleaşi funcţii şi pentru pensule. Dacă aveţi o variabilă
handle a unei pensule, puteţi să selectaţi pensula în contextul de dispozitiv folosind funcţia SelectObject:
SelectObject (hdc, hBrush) ;
O pensulă creată poate fi ştearsă cu ajutorul funcţiei DeleteObject:
DeleteObject (hBrush) ;
Totuşi, nu ştergeţi pensula selectată în contextul de dispozitiv. Dacă vreţi să obţineţi informaţii despre o pensulă, apelaţi funcţia GetObject:
GetObject (hBrush, sizeof (LOGBRUSH), (LPVOID) &logbrush) ;
unde variabila logbrush este o structură de tip LOGBRUSH („logical brush").
Modurile de mapare
Până acum am presupus că toate desenele se fac într-un sistem de coordonate raportate la colţul, din stânga-sus al zonei client şi folosind ca
unitate de măsură pixelul. Acesta este modul de lucru prestabilit, dar nu este singurul mod de lucru.
Un atribut al contextului de dispozitiv care afectează aproape toate operaţiile de desenare din zona client este „modul de mapare" („mapping
mode"). Alte patru atribute ale contextului de dispozitiv - originea ferestrei, originea vizorului (viewport), extensia ferestrei şi extensia vizorului -
sunt strâns legate de modul de mapare.
Majoritatea funcţiilor GDI primesc coordonate sau dimensiuni ca parametri. Iată, ca exemplu, funcţia TextOut:
TextOut (hdc, x, y, szBuffer, iLength) ;
Parametrii x şi y indică poziţia în care începe textul. Parametrul x reprezintă poziţia pe axa orizontală, iar parametrul y reprezintă poziţia pe axa
verticală. Deseori, pentru indicarea acestui punct este folosită notaţia (x, y).
În funcţia TextOut şi, de fapt, în toate funcţiile GDI, coordonatele sunt furnizate în „unităţi logice". Windows trebuie să transforme „unităţile logice"
în „unităţi de dispozitiv", adică în pixeli. Această transformare este guvernată de modul de mapare, de originile ferestrei, ale vizorului şi de extensiile
ferestrei şi ale vizorului. De asemenea, modul de mapare stabileşte şi orientarea axelor x şi y, adică determină sensul în care cresc valorile
coordonatelor x şi y.
Windows defineşte opt moduri de mapare. Acestea sunt prezentate în tabelul următor, folosind identificatorii definiţi în fişierele antet din Windows:
Mod de mapare Unităţi logice Creşterea valorilor axax axay
MM_TEXT Pixel Spre dreapta În jos
MM_LOMETRIC 0,1 mm Spre dreapta În sus
MM_HIMETRIC 0,01mm Spre dreapta În sus
MM_LOENGLISH 0,01 inci Spre dreapta În sus
MM_HIENGLISH 0,001 inci Spre dreapta Însus
MM_TWIPS* 1/1440 inci Spre dreapta În sus
MM_ISOTROPIC Arbitrar (x = y) Selectabil Selectabil
MM_ANISOTROPIC Arbitrar (x != y) Selectabil Selectabil
Puteţi să selectaţi modul de mapare folosind funcţia SetMapMode:
SetMapMode (hdc, iMapHode) ;
unde iMapMode este unul dintre cei opt identificatori definiţi pentru modurile de mapare. Puteţi să obţineţi modul de mapare curent folosind
funcţia GefMapMode:
iMapMode = GetMapMode (hdc) ;
Modul de mapare prestabilit este MM_TEXT. În acest mod de mapare unităţile logice sunt aceleaşi cu unităţile fizice, ceea ce vă permite (sau,
privind dintr-o altă perspectivă, vă forţează) să lucraţi în pixeli. Într-un apel al funcţiei TextOut care arată astfel:
TextOut (hdc, 8, 16, szBuffer, iLength) ;
textul începe la o distanţă de opt pixeli faţă de marginea din stânga a zonei client şi de 16 pixeli faţă de marginea de sus a acesteia.
Dacă modul de mapare este MM_LOENGLISH, o unitate logică este egală cu o sutime de inci:
SetMapHode (hdc, HM_LOENGLISH) ;
Acum apelul de mai sus al funcţiei TextOut trebuie să arate astfel:
TextOut (hdc, 50, -100, szBuffer, iLength) ;
Textul afişat începe la 0,5 inci faţă de marginea din stânga şi la 1 inci faţă de marginea de sus a zonei client. (Motivul folosirii unei valori negative
pentru coordonata y va deveni evident ceva mai târziu, atunci când vom discuta în detaliu despre modurile de mapare.) Celelalte moduri de
mapare permit programului să specifice coordonatele în milimetri, în puncte pentru imprimantă sau într-un sistem de coordonate arbitrar.
Dacă vi se pare convenabilă folosirea pixelilor ca unitate de măsură, puteţi să folosiţi numai modul de mapare MM_TEXT. Dacă trebuie să afişaţi o
imagine la dimensiunile reale în inci sau milimetri, puteţi să obţineţi informaţiile necesare cu ajutorul funcţiei GetDeviceCaps şi să faceţi singur
scalarea. Celelalte moduri de mapare sunt doar metode convenabile de evitare a acestor operaţii de scalare.
Indiferent de modul de mapare folosit, toate coordonatele specificate la apelarea funcţiilor Windows trebuie să fie numere întregi cu semn având
valori de la -32 768 la 32 767. În plus, unele funcţii care folosesc coordonate pentru punctele de început şi de sfârşit ale unui dreptunghi cer ca
lăţimea şi înălţimea dreptunghiului să nu depăşească 32 767.
Coordonate de dispozitiv şi coordonate logice

S-ar putea să vă puneţi următoarea întrebare: „Dacă folosesc modul de mapare MM_LOENGLISH voi primi mesajele WM_SIZE în sutimi de inci?"
Bineînţeles că nu. Windows va folosi în continuare coordonatele de dispozitiv pentru toate mesajele (cum ar fi WM_SIZE, WM_MOVE şi
WM_MOUSEMOVE), pentru toate funcţiile care nu fac parte din interfaţa GDI şi chiar pentru unele funcţii GDI. Lucrurile se petrec în felul următor:
modul de mapare fiind un atribut al contextului de dispozitiv, are efect numai atunci când folosiţi funcţii GDI care primesc o variabilă handle a
contextului de dispozitiv ca parametru. GetSystemMetrics nu este o funcţie GDI, aşa că va returna în continuare dimensiunile în unităţi de dispozitiv,
adică în pixeli. Deşi GetDeviceCaps este o funcţie GDI care primeşte ca parametru o variabilă handle a contextului de dispozitiv, Windows continuă
să returneze unităţi de dispozitiv pentru identificatorii HORZRES şi VERTRES, deoarece unul dintre scopurile acestei funcţii este să furnizeze
programului dimensiunea în pixeli a dispozitivului.
Totuşi, valorile din structura TEXTMETRIC pe care le obţineţi prin apelarea funcţiei GetTextMetrics sunt furnizate în unităţi logice. Dacă modul de
mapare este MM_LOENGLISH în momentul apelării funcţiei, GetTextMetrics returnează lăţimea şi înălţimea caracterelor, în sutimi de inci. Atunci
când apelaţi funcţia GetTextMetrics ca să obţineţi înălţimea şi lăţimea caracterelor, modul de mapare trebuie să fie acelaşi cu cel pe care îl veţi folosi
atunci când afişaţi textul pe baza acestor dimensiuni. Pe măsură ce voi prezenta diferite funcţii GDI în acest capitol, voi preciza dacă acestea
utilizează coordonate logice sau coordonate de dispozitiv. Toate funcţiile despre care am discutat până acum utilizează coordonate logice,
exceptând cele pentru stabilirea spaţiilor între puncte sau liniuţe pentru stilurile de linii şi între liniile de haşură din modele. Acestea sunt
independente de modul de mapare.
Sistemele de coordonate ale dispozitivului

Windows mapează coordonatele logice specificate în funcţiile GDI la coordonatele dispozitivului. Înainte de a discuta despre sistemele de
coordonate logice folosite de diferitele moduri de mapare, vom discuta despre diferitele sisteme de coordonate de dispozitiv definite în Windows
pentru zona de afişare. Deşi în general am lucrat doar în zona client a ferestrei, în anumite situaţii Windows foloseşte alte două sisteme de
coordonate de dispozitiv. În toate sistemele de coordonate de dispozitiv sunt folosiţi pixelii ca unitate de măsură. Valorile de pe axa orizontală (x)
cresc de la stânga la dreapta iar valorile de pe axa verticală (y) cresc de sus în jos.
Atunci când folosim întregul ecran, spunem că lucrăm în „coordonate ecran". Colţul din stânga-sus este punctul de coordonate (0, 0). Coordonatele
ecran sunt folosite în mesajul WM_MOVE (pentru alte ferestre decât ferestrele descendent) şi în următoarele funcţii Windows: CreateWindow şi
MoveWindow (ambele pentru alte ferestre decât ferestrele descendent), GetMessagePos, GetCursorPos, SetCursorPos, GetWindowRect,
WindowFromPoint şi SetBrushOrgEx. Acestea sunt funcţii care fie nu au o fereastră asociată (cum ar fi cele două funcţii pentru cursor), fie trebuie să
mute (sau să găsească) o fereastră pe baza unui punct de pe ecran. Dacă folosiţi funcţia CreateDC cu parametrul DISPLAY ca să obţineţi un context
de dispozitiv pentru întregul ecran, atunci coordonatele logice specificate la apelarea funcţiilor GDI vor fi mapate la coordonatele ecranului.
„Coordonatele de fereastră" se referă la întreaga fereastră a ecranului, inclusiv bara de titlu, meniu, barele de derulare şi chenarul ferestrei. Pentru o
fereastră normală, punctul (0, 0) este colţul din stânga-sus al chenarului de redimensionare. Coordonatele de fereastră sunt folosite mai rar în
Windows, dar dacă obţineţi un context de dispozitiv cu ajutorul funcţiei GetWindowDC, atunci coordonatele logice specificate la apelarea funcţiilor
GDI vor fi mapate la coordonatele ferestrei.
Al treilea sistem de coordonate de dispozitiv - cu care vom lucra cel mai des -foloseşte „coordonatele zonei client". Punctul (0,0) este colţul din
stânga-sus al zonei client. Dacă obţineţi un context de dispozitiv cu ajutorul funcţiei GetDC sau al funcţiei BeginPaint, atunci coordonatele logice
specificate Ia apelarea funcţiilor GDI vor fi mapate la coordonatele zonei client.
Puteţi să transformaţi coordonatele zonei client în coordonatele ecranului şi invers folosind funcţiile ClientToScreen şi ScreenToClient. De asemenea,
puteţi şă obţineţi poziţia şi dimensiunea întregii ferestre în coordonate ecran folosind funcţia GetWindowRect. Aceste funcţii vă furnizează suficiente
informaţii ca să transferaţi coordonatele între oricare dintre sistemele de coordonate de dispozitiv.
Vizorul şi fereastra
Modurile de mapare definite în Windows stabilesc modul în care sunt mapate coordonatele logice specificate în funcţiile GDI la coordonatele de
dispozitiv, pe baza faptului că sistemul de coordonate de dispozitiv folosit depinde de funcţia folosită pentru obţinerea contextului de dispozitiv.
Pentru a ne continua discuţia despre modurile de mapare, trebuie să mai facem o precizare legată de terminologie: se spune că modul de mapare
defineşte maparea coordonatelor „de fereastră" (window) -coordonate logice - la coordonatele vizorului (viewport) - coordonate de dispozitiv.
Folosirea termenilor window (fereastră) şi viewport (vizor) nu este totuşi cea mai potrivită alegere. În alte limbaje pentru interfeţele grafice, termenul
viewport se referă la o regiune de decupare (clipping region). Termenul window defineşte, în general, zona pe care o ocupă un program pe ecran. În
timpul discuţiilor de faţă va trebui să renunţăm la vechile definiţii ale acestor termeni.
Pentru vizor se folosesc coordonatele de dispozitiv (pixeli). De cele mai multe ori, vizorul coincide cu zona client a ferestrei, dar poate să însemne şi
coordonatele întregii ferestre sau coordonatele întregului ecran, dacă aţi obţinut contextul de dispozitiv prin apelarea funcţiilor GetWindowDC sau
CreateDC. Punctul de coordonate (0, 0) este colţul din stânga-sus al zonei client (sau al ferestrei, ori al ecranului). Valorile coordonatei x cresc către
dreapta, iar valorile coordonatei y cresc în jos.
Pentru fereastră se utilizează coordonatele logice, care pot fi,exprimate în pixeli, milimetri, inci sau orice altă unitate de măsură doriţi. Coordonatele
logice ale ferestrei sunt specificate la apelarea funcţiilor GDI.
Pentru toate modurile de mapare, Windows transformă coordonatele ferestrei (coordonate logice) în coordonate ale vizorului (coordonate de
dispozitiv) folosind două formule:
unde (xWindow, yWindow) este punctul în coordonate logice care trebuie translatat iar (xViewport, yViewport) este punctul în coordonate de
dispozitiv. În cazul în care coordonatele de dispozitiv sunt coordonate ale zonei client sau coordonate ale ferestrei, Windows trebuie să le
transforme în coordonate ecran înainte de a desena un obiect.
Formulele de mai sus folosesc două puncte corespunzătoare originii ferestrei şi a vizorului: (xWinOrg, yWinOrg) reprezintă originea ferestrei în
coordonate logice, iar (xViewOrg, yViewOrg) reprezintă originea, vizorului în coordonate de dispozitiv. În contextul de dispozitiv prestabilit, aceste
puncte au valoarea (0, 0), dar pot fi modificate. Formulele de mai sus implică faptul că punctul (xWinOrg, yWinOrg) este întotdeauna mapat la
punctul (xViewOrg, yViewOrg).
De asemenea, formulele de mai sus folosesc două puncte, pentru specificarea „extensiilor" ferestrei şi vizorului: (xWinExt, yWinExt) reprezintă
extensia, ferestrei în coordonate logice, iar (xViewExt, yViewExt) reprezintă extensia vizorului în coordonate de dispozitiv. În majoritatea modurilor
de mapare, extensiile sunt implicate de modul de mapare şi nu pot fi modificate. Extensia în sine nu are nici o semnificaţie, dar raportul între
extensia vizorului şi extensia ferestrei reprezintă un factor de scalare folosit pentru convertirea unităţilor logice în unităţi de dispozitiv. Extensiile pot
avea valori negative: aceasta înseamnă că nu este obligatoriu ca valorile pe axa x să crească spre dreapta şi valorile pe axa y să crească în jos.
Windows poate să transforme şi coordonatele vizorului (coordonate de dispozitiv) în coordonate ale ferestrei (coordonate logice):
Windows include două funcţii care vă permit să convertiţi punctele de dispozitiv în puncte logice şi invers. Funcţia următoare converteşte punctele
de dispozitiv în puncte logice:
DPtoLP (hdc, pPoints, iNumber) ;
Variabila pPoints este o matrice de structuri POINT, iar iNumber este numărul de puncte ce urmează să fie convertite. Veţi vedea că această funcţie
este foarte utilă pentru convertirea dimensiunii zonei client obţinute prin apelarea funcţiei GetClientRect (care returnează valorile în unităţi de
dispozitiv) în coordonate logice:
GetClientRect (hwnd, &rect);
DPtoLP (hdc, (PPoint) &rect, 2);
Funcţia următoare converteşte punctele logice în puncte de dispozitiv:
LPtoDP (hdc, pPoints, iNumber) ;
Folosirea modului de mapare MM_TEXT
Pentru modul de mapare MM_TEXT, originile şi extensiile prestabilite sunt următoarele:
Originea ferestrei: (0, 0) Poate fi modificată
Originea vizorului: (0, 0) Poate fi modificată
Extensia ferestrei: (1, 1) Nu poate fi modificată
Extensia vizorului: (1, 1) Nu poate fi modificată
Raportul din extensia ferestrei şi extensia vizorului este 1, aşa că nu este necesară nici o operaţie de scalare pentru transformarea coordonatelor
logice în coordonate de dispozitiv. Formulele prezentate anterior se reduc la acestea:
xViewport = xWindow - xWinOrg + xViewOrg
yViexport = yWindow - yWinOrg + yViewOrg
Acest mod de mapare se numeşte „mapare de tip text", nu fiindcă este cea mai potrivită pentru text, ci datorită orientării axelor. În general, citim
textul de la stânga spre dreapta şi de sus în jos, iar în modul de mapare MM_TEXT, valorile cresc în acelaşi sens:
Windows furnizează funcţiile SetViewportOrgEx şi SetWindowOrgEx pentru modificarea originii vizorului şi a ferestrei. Aceste funcţii au ca efect
deplasarea axelor, astfel încât punctul de coordonate (0, 0) nu se mai referă la colţul din stânga-sus al ecranului. În general, veţi folosi ori funcţia
SetViewportOrgEx, ori SetWindowOrgEx, dar nu pe amândouă.
Iată cum lucrează aceste funcţii: dacă schimbaţi originea vizorului la (xViewOrg, yViewOrg), atunci punctul logic de coordonate (0, 0) va fi mapat la
punctul de dispozitiv (xViewOrg, yViewOrg). Dacă schimbaţi originea ferestrei la (xWinOrg, yWinOrg), atunci punctul logic (xWinOrg, yWinOrg) va fi
mapat la punctul de dispozitiv (0, 0). Indiferent de modificările pe care le faceţi asupra originii ferestrei şi a vizorului, punctul de dispozitiv (0, 0) este
întotdeauna colţul din stânga-sus al zonei client.
De exemplu, să presupunem că zona client are lăţimea cxClient şi înălţimea cyClient. Dacă vreţi ca punctul logic de coordonate (0, 0) să se afle în
centrul zonei client, puteţi să apelaţi funcţia următoare:
SetViewportOrgEx (hdc, cxClient/2, cyClient/2, NULL) ;
Argumentele funcţiei SetViewportEx sunt exprimate întotdeauna în unităţi de dispozitiv. Punctul logic (0, 0) va fi acum mapat la punctul de
dispozitiv (cxClient/2, cyClient/2). Din acest moment folosiţi zona client ca şi cum ar avea următorul sistem de coordonate:
Valorile logice ale axei x sunt cuprinse în intervalul de la -cxClient/2 la +cxClient/2 iar valorile logice ale axei y sunt cuprinse în intervalul de la -
cyClient/2 la +cyClient/2. Colţul din dreapta-jos al zonei client are coordonatele (cxClient/2, cyClient/2). Dacă vreţi să afişaţi text începând din colţul
din stânga-sus al zonei client, care are coordonatele de dispozitiv (0, 0), trebuie să folosiţi coordonate logice negative:
TextOut (hdc, -cxClient/2, -cyClient/2, "Hello", 5) ;
Acelaşi rezultat poate fi obţinut cu ajutorul funcţiei SetWindowOrgEx în locul funcţiei SetViewportOrgEx:
SetWindowOrgEx (hdc, -cxClient/2, -cyClient/2, NULL) ;
Argumentele funcţiei SetWindowOrgEx sunt exprimate întotdeauna în coordonate logice. După apelul de mai sus, punctul logic (-cxClient/2, -
cyClient/2) este mapat la punctul de dispozitiv (0, 0), care este colţul din stânga-sus al zonei client.
Ceea ce probabil nu doriţi să faceţi (decât dacă ştiţi ce rezultat veţi obţine) este să folosiţi cele două funcţii împreună:
SetWindowOrgEx (hdc, -cxClient/2, -cyClient/2, NULL) ;
Aceasta înseamnă că punctul logic (-cxClient/2, -cyClient/2) este mapat la punctul de dispozitiv (cxClient/2, cyClient/2), rezultând următorul sistem
de coordonate:
Puteţi să obţineţi originea vizorului apelând funcţia GetViewportOrgEx:
GetViewportOrgEx (hdc, &pt) ;
şi originea ferestrei apelând funcţia GetWindowOrgEx:
GetWindowOrgEx (hdc, &pt) ;
unde pt este o structură de tip POINT. Valorile returnate de funcţia GetViewportOrgEx sunt în coordonate de dispozitiv, iar valorile returnate de
funcţia GetWindowOrgEx sunt în coordonate logice.
Uneori este de dorit să modificaţi originea ferestrei sau a vizorului ca să deplasaţi imaginea afişată pe ecran - de exemplu, ca răspuns la acţionarea
barei de derulare de către utilizator. Modificarea originii nu determină deplasarea imediată a imaginii afişate. Mai întâi modificaţi originea, apoi
redesenaţi ecranul. De exemplu, în programul SYSMETS2 din Capitolul 2 am folosit valoarea iVscrollPos (poziţia curentă a casetei de derulare de pe
bara de derulare verticală) ca să ajustăm coordonatele de afişare pe axa y:
case WM_PAINT :
BeginPaint (hwnd, &ps) ;
for 0 = 0; i<NUMLINES ; i++)
y = cyChar * (1 - iVscrollPos + 1) ;
[afişează textul]
return 0 ;
Putem să obţinem acelaşi rezultat cu ajutorul funcţiei SetWindowOrgEx:
case WM_PAINT :
BeginPaint (hwnd, &ps);
SetWindowOrgEx (ps.hdc, 0, cyChar * iVscrollPos) ;
for (i = 0; i < NUMLINES ; i++)
y = cyChar * (1 + i) ;
[afişează textul]
}
return 0 ;
Acum nu mai este nevoie să fie folosită valoarea iVscrollPos pentru calcularea coordonatei y pentru funcţia TextOut. Aceasta înseamnă că puteţi să
apelaţi funcţiile de afişare a textului dintr-o subrutină, fără să transmiteţi subrutinei valoarea iVscrollPos, deoarece ajustarea poziţiei de afişare a
textului s-a făcut prin modificarea originii ferestrei.
Dacă aţi mai lucrat cu sistemele de coordonate rectangulare (carteziene), probabil deplasarea punctului logic de coordonate (0, 0) în centrul zonei
client vi se pare o operaţie logică. Totuşi, modul de mapare MM_TEXT prezintă o mică problemă: de obicei, într-un sistem de coordonate cartezian,
valorile de pe axa y cresc în sus, pe când în modul de mapare MM_TEXT acestea cresc în jos. In acest sens, modul de mapare MM_TEXT este un caz
izolat, această problemă fiind corectată de celelalte cinci moduri de mapare.
Modurile de mapare „metrice"

Windows include două moduri de mapare în care coordonatele logice sunt exprimate în unităţi fizice. Deoarece coordonatele logice pe axele x şi y
sunt mapate la unităţi fizice identice, aceste moduri de mapare vă ajută să desenaţi cercuri „mai rotunde" şi pătrate „mai pătrate".
Cele cinci moduri de mapare „metrice" sunt prezentate mai jos în ordinea crescătoare a preciziei. Cele două coloane din partea dreaptă prezintă
dimensiunile unităţilor logice în inci (in.) şi în milimetri (mm) pentru comparare:
Mod de mapare Unităţi logice Inci Milimetri
MM_LOENGLISH 0,01 in. 0,001 0,254

MM_LOMETRIC
MM_HIENGLISH 0,1 mm 0,00394 0,1
MM_TWIPS*
0,001 in. 0,001 0,0254
MM_HIMETRIC
1/1440 in. 0,000694 0,0176
0,000394
0,01 mm 0,01
* Un twip este 1/20 dintr-un punct (care este 1/72 dintr-un inci),
deci 1 /1440 dintr-un inci.
Ca să puteţi face o comparaţie între modul de mapare MM_TEXT şi aceste rezoluţii, trebuie să vă amintesc faptul că, pe un monitor VGA standard,
fiecare pixel este un pătrat cu latura de 0,325 mm, ceea ce înseamnă că coordonatele unui dispozitiv VGA sunt mult mai grosiere decât oricare
dintre modurile de mapare metrice.
Pentru o imprimantă laser cu rezoluţia de 300 dpi (puncte pe inci) fiecare pixel are 0,0033 inci - o rezoluţie mai mare decât cea a modurilor de
mapare MM_LOENGLISH si MM_LOMETRIC, dar mai mică decât cea a modurilor de mapare MM_HIENGLISH, MM_TWIPS şi MM_HIMETRIC.
Originile şi extensiile prestabilite sunt următoarele:
Originea ferestrei: (0,0) Poate fi modificată
Originea vizorului: (0,0) Poate fi modificată
Extensia ferestrei: (?, ?) Nu poate fi modificată
Extensia vizorului: (?, ?) Nu poate fi modificjată
Extensiile ferestrei şi ale vizorului depind de modul de mapare şi de raportul de afişare a dispozitivului. Aşa cum am menţionat anterior, extensiile
nu sunt impor tante ca atare, având o semnificaţie numai exprimate ca rapoarte. Iată care sunt formulele de transformare a coordonatelor:
De exemplu, pentru modul de mapare MM_LOENGLISH, Windows foloseşte extensiile pentru următoarele calcule:
Pentru multe dispozitive de afişare (cum ar fi VGA) acest raport va fi mai mic decât 1. Deoarece Windows lucrează numai cu numere întregi,
folosirea unui raport în locul unui factor de scalare este absolut necesară pentru o mai mare precizie în transformarea coordonatelor logice în
coordonate de dispozitiv, şi invers.
Remarcaţi semnul minus din faţa raportului extensiilor pe axa verticală. Acest semn modifică orientarea axei y. Pentru cele cinci moduri de mapare,
valorile y cresc pe măsură ce vă deplasaţi în sus pe dispozitiv. Originile prestabilite ale ferestrei şi ale vizorului sunt (0,0). Consecinţele sunt
interesante: atunci când treceţi la unul dintre aceste cinci moduri de mapare, sistemul de coordonate arată astfel:
Singurul mod în care puteţi să afişaţi ceva pe ecran este să folosiţi valori negative pentru coordonata y. De exemplu, codul următor:
SetMapMode (hdc, MM_LOENGLISH) ;
TextOut (hdc, 100, -100, "Hello", 5 ) ;
afişează textul „Hello" la o distanţă de un inci de marginea din stânga şi de marginea de sus a zonei client.
Ca să vă păstraţi judecata limpede, probabil veţi dori să schimbaţi această situaţie. O soluţie este să mutaţi punctul de coordonate (0,0) în colţul din
stânga-jos al zonei client. Presupunând că cyClient este înălţimea zonei client în pixeli, puteţi să faceţi acest lucru apelând funcţia SetViewportOrgEx
astfel:
SetViewportOrgEx (hdc, 0, cyClient, NULL) ;
Acum sistemul de coordonate arată astfel:
O altă soluţie este să mutaţi punctul de coordonate (0,0) în centrul zonei client:
Acum sistemul de coordonate arată astfel:
Acum avem un sistem de coordonate cartezian, cu patru cadrane, cu aceleaşi unităţi de măsură pe axele x şi y, în inci, milimetri sau twips.
Pentru mutarea punctului logic (0,0) puteţi să folosiţi şi funcţia SetWindowOrgEx, dar această cale este puţin mai dificilă, deoarece parametrii
funcţiei SetWindowOrgEx trebuie să fie în coordonate logice. Mai întâi trebuie să transformaţi coordonatele de dispozitiv (cxClient, cyClient) în
coordonate logice, folosind funcţia DPtoLP. Presupunând că pt este o structură de tip POINT, codul de mai jos mută punctul logic (0,0) în centrul
zonei client:
pt.x = cxClient ;
pt.y = cyClient ;
DPtoLP (hdc, &pt, 1) ;
SetWindowOrgEx (hdc, -pt.x/2, -pt.y/2, NULL) ;
Moduri de mapare proprii
Ultimele două moduri de mapare se numesc MM_ISOTROPIC şi MM_ANISOTROPIC. Acestea sunt singurele moduri de mapare care vă permit să
modificaţi extensiile ferestrei şi ale vizorului, ceea ce înseamnă că vă permit să modificaţi factorul de scalare pe care Windows îl foloseşte pentru
convertirea coordonatelor logice şi a coordonatelor de dispozitiv. Cuvântul „izotrop" înseamnă „egal în toate direcţiile"; „anizotrop" este antonimul
acestuia. Ca şi modurile de mapare metrice prezentate mai înainte, MM_ISOTROPIC foloseşte axe scalate egal. Unităţile logice de pe axa x au
aceeaşi dimensiune fizică ca şi unităţile logice de pe axa y. Acest fapt vă ajută să creaţi imagini care păstrează raportul corect de afişare, indiferent
de raportul de afişare al dispozitivului.
Diferenţa dintre modurile de mapare metrice şi modul de mapare MM_ISOTROPIC constă în faptul că puteţi să controlaţi dimensiunea fizică a
unităţilor logice. Dacă doriţi, puteţi să ajustaţi dimensiunea fizică a unităţilor logice în funcţie de dimensiunea zonei client, astfel încât imaginile pe
care le desenaţi să fie întotdeauna conţinute de zona client, mărindu-se şi micşorându-se corespunzător. Programul ANACLOCK (ceasul analogic)
din Capitolul 7 este un exemplu de imagine izotropă. Ceasul este întotdeauna rotund. Dacă redimensionaţi fereastra, ceasul se redimen-sionează
automat. Un program Windows poate să manipuleze redimensionarea unei imagini prin ajustarea extensiilor ferestrei şi ale vizorului. Apoi
programul poate să folosească aceleaşi unităţi logice la apelarea funcţiilor de desenare, indiferent de dimensiunea ferestrei.
Uneori, modurile de mapare metrice şi modul MM_TEXT sunt numite moduri de mapare „complet restricţionate" („fully constrained"). Aceasta
înseamnă că nu puteţi să modificaţi extensiile ferestrei şi ale vizorului sau modul în care Windows scalează coordonatele logice faţă de
coordonatele de dispozitiv. MM_ISOTROPIC este un mod de mapare „partial restricţionat" („partly constrained"). Windows vă permite să modificaţi
extensiile ferestrei şi ale vizorului, dar le ajustează astfel încât unităţile logice x şi y să aibă aceleaşi dimensiuni fizice. Modul de mapare
MM_ANISOTROPIC este „nerestricţionat". Puteţi să modificaţi extensiile ferestrei şi ale vizorului, fără ca Windows să mai facă vreo ajustare a
valorilor.
Modul de mapare MM_ISOTROPIC

Modul de mapare MM_ISOTROPIC este ideal pentru folosirea unor axe arbitrare, cu unităţi logice egale pe cele două axe. Dreptunghiurile cu lăţimi
şi înălţimi logice egale sunt afişate ca pătrate. Elipsele cu lăţimi şi înălţimi logice egale sunt afişate ca cercuri.
Atunci când selectaţi pentru prima dată modul de mapare MM_ISOTROPIC, Windows foloseşte aceleaşi extensii pentru fereastră şi pentru vizor, ca
şi pentru modul de mapare MM_LOMETRIC. (Totuşi, nu vă bazaţi pe acest fapt.) Diferenţa este că acum puteţi să schimbaţi extensiile după cum
dopţi, apelând funcţiile SetWindowExtEx şi SetViewportExtEx. Windows va ajusta apoi aceste extensii astfel încât unităţile logice de pe ambele axe să
reprezinte distanţe fizice egale.
În general, veţi folosi ca parametri ai funcţiei SetWindowExtEx dimensiunile dorite pentru fereastra logică, iar ca parametri ai funcţiei
SetViewportExtEx dimensiunile reale ale zonei client. Atunci când ajustează aceste extensii, Windows trebuie să încadreze fereastra logică în vizorul
fizic, ceea ce înseamnă că o parte a zonei client poate să rămână în afara ferestrei logice. Pentru folosirea mai eficientă a spaţiului din zona client
trebuie să apelaţi funcţia SetWindowExtEx înainte de apelarea funcţiei SetViewportExtEx.
De exemplu, să presupunem că vreţi să folosiţi un sistem de coordonate virtual, „tradiţional", cu un singur cadran în care punctul (0, 0) este colţul
din stânga-jos al zonei client, iar lăţimea şi înălţimea au valori de la 0 la 32.767. Dacă doriţi ca unităţile logice x şi y să aibă aceleaşi dimensiuni, iată
ce trebuie să faceţi:
SetMapMode (hdc, HH_ISOTROPIC) ;
SetWindowExtEx (hdc, 32767, 32767, NULL) ;
SetViewportExtEx (hdc, cxClient, -cyClient, NULL) ;
Dacă apoi obţineţi extensiile ferestrei şi ale vizorului apelând funcţiile GetWindowExtEx şi GetViewportExtEx veţi vedea că acestea au alte valori decât
cele specificate. Windows ajustează extensiile în funcţie de raportul de afişare (aspect ratio) al dispozitivului, astfel încât unităţile logice de pe cele
două axe să reprezinte aceleaşi dimensiuni fizice.
Dacă zona client este mai mult lată decât înaltă (în dimensiuni fizice), Windows ajustează extensia x astfel încât fereastra logică să fie mai mică
decât vizorul zonei client. Fereastra logică va fi poziţionată în partea stângă a zonei client:
Nu puteţi să afişaţi nimic în partea dreaptă a zonei client dincolo de capătul axei x, deoarece pentru aceasta ar trebui să folosiţi o coordonată logică
x mai mare de 32.767. Dacă zona client este mai mult înaltă decât lată (în dimensiuni fizice), Windows ajustează extensia y. Fereastra logică va fi
poziţionată în partea de jos a zonei client:
Nu puteţi să afişaţi nimic în partea de sus a zonei client dincolo de capătul axei y, deoarece pentru aceasta ar trebui să folosiţi o coordonată logică
y mai mare de 32.767. Dacă preferaţi ca fereastra logică să fie poziţionată întotdeauna în partea stângă şi în partea de sus a zonei client, puteţi să
modificaţi astfel codul precedent:
SetMapMode (hdc, HH_ISOTROPIC) ;
SetWindowOrgEx (hdc, 0, 32767, NULL) ;
În acest fel, prin apelul funcţiei SetWihdowOrgEx precizăm că dorim ca punctul logic (0,32767) să fie mapat la punctul de dispozitiv (0,0). Dacă zona
client este mai mult înaltă decât lată, sistemul de coordonate este poziţionat astfel:
Pentru imaginile de genul celei folosite de programul ANACLOCK puteţi să folosiţi un sistem de coordonate cartezian cu patru cadrane având axe
arbitrar scalate în cele patru direcţii şi cu punctul de coordonate (0, 0) în centrul zonei client. Dacă, de exemplu, vreţi ca fiecare axă să ia valori de la
0 la 1000, folosiţi codul următor:
SetMapMode (hdc, MM_ISOTROPIC) ;
SetWindowExtEx (hdc, 1000, 1000, NULL);
SetViewportExtEx (hdc, cxClient/2, -cyClient/2, NULL) ;
SetViewportOrgEx (hdc, cxClient/2, cyCllent/2, NULL) ;
Dacă zona client este mai mult lată decât înaltă, sistemul logic de coordonate arată astfel:
Sistemul logic de coordonate este centrat şi atunci când zona client este mai mult înaltă decât lată:
Reţineţi faptul că extensiile ferestrei şi ale vizorului nu implică nici o operaţie de decupare. La apelarea funcţiilor GDI puteţi să folosiţi pentru
coordonatele x şi y valori mai mici de -1000 sau mai mari de +1000. În funcţie de forma zonei client, aceste puncte pot să fie sau să nu fie vizibile.
Folosind modul de mapare MM_ISOTROPIC puteţi să faceţi ca unităţile logice să fie mai mari decât pixelii. De exemplu, să presupunem că doriţi să
creaţi un sistem de coordonate în care punctul de coordonate (0, 0) se află în colţul din stânga-sus al ecranului şi valorile de pe axa y cresc de sus în
jos (ca în modul de mapare MM_TEXT) dar cu coordonate logice măsurate în unităţi de 1/16 dintr-un inci. Acest mod de mapare v-ar permite să
desenaţi o riglă având un capăt în colţul din stânga-sus al zonei client, cu diviziuni de şaisprezecimi de inci:
SetMapMode (hdc, MM_ISOTROPIC) ;
SetWindowExtEx(hdc, 160*GetDeviceCaps (hdc, HORZSIZE)/254,160*GetDeviceCaps(hdc, VERTSIZE)/254, NULL);
SetViewportExtEx(hdc, GetDeviceCaps(hdc, HORZRES),GetDeviceCaps(hdc, VERTRES), NULL);
În această secvenţă de cod extensiile vizorului sunt stabilite la dimensiunile în pixeli ale întregului ecran. Extensiile ferestrei trebuie să fie stabilite la
dimensiunile întregului ecran în unităţi de şaisprezecimi de inci. Indicii HORZSIZE şi VERTSIZE ai funcţiei GetDeviceCaps returnează dimensiunile
dispozitivului în milimetri. Dacă lucraţi cu numere în virgulă mobilă, trebuie să transformaţi milimetrii în inci împărţind valorile obţinute la 2,54, şi
apoi să transformaţi incii în şaisprezecimi de inci înmulţind rezultatul operaţiei anterioare cu 16. Deoarece aici lucrăm cu numere întregi, am
înmulţit rezultatul cu 160 şi l-am împărţit la 254.
Pentru majoritatea dispozitivelor, acest cod face ca unităţile logice să fie mult mai mari decât unităţile fizice. Tot ce desenaţi pe dispozitiv va avea
pentru coordonate valori mapate la multipli de 1/16 inci. Nu puteţi să desenaţi două linii orizontale aflate la distanţa de 1/32 de inci, deoarece
pentru aceasta aţi avea nevoie de o coordonată logică fracţionară.
Modul de mapare MM_ANISOTROPIC sau ajustarea imaginii
Atunci când stabiliţi extensiile ferestrei şi pe ale vizorului în modul de mapare MM_ISOTROPIC, Windows ajustează valorile astfel încât unităţile
logice de pe cele două axe să aibă aceleaşi dimensiuni. În modul de mapare MM_ANISOTROPIC, Windows nu face nici o ajustare a valorilor pe care
le stabiliţi. Aceasta înseamnă că în modul de mapare MM_ANISOTROPIC nu este obligatorie păstrarea raportului corect de afişare.
Pentru a folosi modul de mapare MM_ANISOTROPIC, stabiliţi un sistem arbitrar de coordonate pentru zona client, ca şi pentru modul de mapare
MM_ISOTROPIC. Codul de mai jos stabileşte punctul de coordonate (0, 0) în colţul din stânga-jos al zonei client, iar axele de coordonate x şi y pot
lua valori de la 0 la 32.767:
SetMapMode (hdc, MM_ANISOTROPIC) ;
*Twip este un cuvânt fabricat, care înseamnă „a douăzecea parte dintr-un punct" („twentieth of a point"). Un punct - unitate de măsură folosită în
tipografie - este aproximativ egal cu 1/72 dintr-un inci, dar în sistemele grafice precum GDI se consideră de cele mai multe ori că este exact 1/72
dintr-un inci. Un twip este 1/20 dintr-un punct, deci 1/1440 dintr-un inci.
Last modified: Wednesday, 6 May 2020, 12:11 AM
◄ Afișarea textului Jump to... Totul despre tastatură ►
You are logged in as Mihail Curchi (Log out)

PWINDOWS
Data retention summary
Get the mobile app

Elemente de Grafică

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Elemente de Grafică

Încărcat de

Drepturi de autor:

Formate disponibile

Programarea în Windows

Home / My courses / PWINDOWS / Capitolul 4. Noţiuni elementare de grafică / Elemente de grafică

Structura interfeţei GDI

Tipuri de apeluri de funcţii

Obţinerea variabilei handle a contextului de dispozitiv

hdc = BeginPaint (hwnd, &ps);

[alte Unii de program]

EndPaint (hwnd, &ps);

hdc = GetDC (hwnd);

(alte linii de program]

hdc = GetWindowDC (hwnd);

[alte linii de program]

ReleaseDC (hwnd, hdc);

hdc = CreateDC (pszDriver, pszDevice, pszOutput, pData);

[alte linii de program]

hdc = CreateDC ("DISPLAY", NULL, NULL, NULL);

hdclnfo = CreatelC ("DISPLAY", NULL, NULL, NULL);

[alte linii de program]

Nu puteţi să executaţi operaţii de scriere la un dispozitiv folosind această variabilă handle.

hdcMem = CreateCompatibleDC (hdc);

[alte linii de program]

[alte linii de program]

hmf = CloseMetaFile (hdcMeta);

Obţinerea informaţiilor despre contextul de dispozitiv

DEVCAPS1.C -- Device Capabilities Display Program No. 1

(c) Charles Petzold, 1996

#define NUMLINES ((int) (sizeof devcaps / sizeof devcaps [0]))

HORZSIZE, "HORZSIZE", "Width in millimeters:",

VERTSIZE, "VERTSIZE", "Height in millimeters:",

HORZRES, "HORZRES", "Width in pixels:",

VERTRES, "VERTRES", "Height in raster lines:",

BITSPIXEL, "BITSPIXEL", "Color bits per pixel:",

PLANES, "PLANES", "Number of color planes:",

NUMBRUSHES, "NUMBRUSHES", "Number of device brushes:",

NUMPENS, "NUMPENS", "Number of device pens:",

NUMMARKERS, "NUMMARKERS", "Number of device markers:",

NUMFONTS, "NUMFONTS", "Number of device fonts:",

NUMCOLORS, "NUMCOLORS", "Number of device colors:",

PDEVICESIZE, "PDEVICESIZE", "Size of device structure:",

ASPECTX, "ASPECTX", "Relative width of pixel:",

ASPECTY, "ASPECTY", "Relative height of pixel:",

ASPECTXY, "ASPECTXY", "Relative diagonal of pixel:",

LOGPIXELSY, "LOGPIXELSY", "Vertical dots per inch:",

SIZEPALETTE, "SIZEPALETTE", "Number of palette entries:",

NUMRESERVED, "NUMRESERVED", "Reserved palette entries:",

COLORRES, "COLORRES", "Actual color resolution:"

LRESULT CALLBACK WndProc (HWND, UINT, WPARAM, LPARAM);

static char szAppName[] = "DevCaps1" ;

wndclass.cbSize = sizeof (wndclass) ;

wndclass.style = CS_HREDRAW | CS_VREDRAW ;

wndclass.hIcon = LoadIcon (NULL, IDI_APPLICATION) ;

wndclass.hCursor = LoadCursor (NULL, IDC_ARROW) ;

wndclass.hbrBackground = (HBRUSH) GetStockObject (WHITE_BRUSH) ;

wndclass.hIconSm = LoadIcon (NULL, IDI_APPLICATION) ;

hwnd = CreateWindow (szAppName, "Device Capabilities", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT,

ShowWindow (hwnd, iCmdShow) ;

while (GetMessage (&msg, NULL, 0, 0))

static int cxChar, cxCaps, cyChar ;

hdc = GetDC (hwnd) ;

GetTextMetrics (hdc, &tm) ;

cxCaps = (tm.tmPitchAndFamily & 1 ? 3 : 2) * cxChar / 2 ;

cyChar = tm.tmHeight + tm.tmExternalLeading ;

ReleaseDC (hwnd, hdc) ;