[win32 c++] control maken

[Krooswijk.com]

ben al een tijdje op zoek naar informatie over het maken van een eigen win32 control in c++. echter kan er praktisch niks (zelfs niet op msdn) over vinden.

de bedoeling is dus dat ik een component ga maken, denk bv aan een static control binnen binnen win32, die dmv messages kan worden aangestuurd.

weet iemand waar ik hier meer info over kan vinden. bvd.

[hobbit_be]

subclass een window en dat is alles wat je nodig hebt ... dus een search on 'subclassing'

[johnwoo]

Bij subclassing pak je een reeds bestaand control, waar je een eigen windowproc aan vast maakt om de functionaliteit aan te passen. Wil je een geheel nieuwe control maken, dan moet je een WNDCLASSEX structuurtje vullen (o.a. met een pointer naar de bij de window class behorende windowproc) en doorgeven aan RegisterClassEx. Vervolgens kun je de controls aanmaken met CreateWindow, zoals je dat ook met Windows' built-in controls doet, en kun je er messages naar sturen enz. Aangezien je zelf de windowproc voor je window class maakt, kun je zelf bepalen op welke messages hij reageert.

Meestal wordt de USERDATA window long (op te vragen/in te stellen met GetWindowLong/SetWindowLong) gebruikt om aan een control instance een pointer naar een data structuurtje te hangen. Hierin sla je dan alle data voor het control op.

Alle benodigde informatie is te vinden in MSDN

[Krooswijk.com]

ja bovenstaande is inderdaad gangbaar voor bestaande built in controls, er is me nog steeds niet helemaal duidelijk, hoe ik dit nu zelf kan aanpakken, ik moet dus iets met die WNDCLASSEX gaan doen, zal vanuit hier effe verder gaan zoeken...

[Verwijderd]

Kijk eens op deze webpagina:

http://www.relisoft.com/win32/

[hobbit_be]

ja ok - maar subclassing heeft wel 1 enorm voordeel : het meeste standaard spul is al voor je gedaan (ik spreek maar over clipping regions etc). Je krijgt ook al de messages door en degene die hetzelfde stuur je door. Why do things twice? MFC maakt ook voordurend gebruik ervan... maar een echte nieuwe control is zoals johnwoo al zegt een nieuwe class..
(ik waarschuw je alvast voor de oneindig vele details die een component moet doen en die zoveel tijd in beslag nemen dat je snel zult zien dat dit niet de ideale solution is: ik heb het namelijk ook allemaal gedaan en uiteindelijk gind ik van +-1200 code naar 100 en deed net hetzelfde...)

[curry684]

hobbit_be schreef op 06 February 2003 @ 14:04:
ja ok - maar subclassing heeft wel 1 enorm voordeel : het meeste standaard spul is al voor je gedaan (ik spreek maar over clipping regions etc)

Je noemt precies het onderdeel waar het niet boeit De DC die je uit BeginPaint(...) krijgt is al geclipped tot de oppervlakte van het window.

Subclasses is redelijk onpraktisch en alleen nuttig als je echt bestaande functionaliteit wil uitbreiden, bijv. een edit control die alleen integers kan bevatten kun je maken door een Edit te subclassen en alleen de WM_KEYDOWN's te vangen. In de exotischer gevallen kun je net zo makkelijk zelf een window definieren via RegisterClassEx: DefWindowProc doet die standaardmeuk ook leuk

[hobbit_be]

een BeginPaint? nou dan ben je wel niet goed bezig... probeer dat maar eens te doen in een setTitle message - niks geclipt en doet niets - het UI tekent niet alleen in een WM_PAINT hoor - en net buiten die dingen ligt het punt om volledig eigen controle's te maken (non-client ie).

[.oisyn]

je weet tegen wie je het hebt?

anyway, tekenen doe je in principe alleen bij de messages WM_PAINT en WM_NCPAINT, waarbij die laatste in de meeste gevallen gewoon naar DefWindowProc () gestuurd wordt. Bij WM_PAINT kun je fijn BeginPaint () gebruiken, en bij een WM_NCPAINT krijg je een update region mee, die je kunt gebruiken bij GetDCEx, zodat je een goed geclipte HDC terug krijgt.

Een WM_NCPAINT wordt trouwens ook automatisch verstuurd bij een call naar BeginPaint () als er ook een stuk van de non-client area geupdate moet worden.

En SetTitle Da's zeker zo'n vieze MFC functie

[hobbit_be]

sorry dat moest SetText zijn die de naam van de window zet - ook deze 'tekent' zonder de door jouw genoemde messages. Deze wordt in sommige gevallen ook aangeroepen als je een window (of control ==) resized. Ik weet dit omdat enige tijd terug een UI wenste opbouwen zonder ook maar 1 ding van Windows maar wel met het supersnelle region systeem. Dit bleek onmogelijk zonder subclassing (dat het wel kan spreekt vanzelf maar ik zou maar alsgraag de source-code zien van DefWindowProc . MFC is zoals je zelf weet 'viez' Dat mijn requirements iets meer zijn dan een aanmaken van een control geef ik toe maar houdt ook niet tegen dat je zo'n dingen tegenkomt. al wat ik zeg staat netjes in de MSDN. Geloof me was zeer frustrerend om een nieuwe 'look' te geven en dan komt er plotseling zo'n rotte window title over m'n design ... uiteindelijk heb ik het opgeven - niet omdat het niet werkte maar gewoon omdat het ineens cross-platform moest en ik dus gewoon mijn eigen windowing systeem schreef (die ik grif toegeef een pak trager was dan windows . Om de UI hel nog te vergroten hebben ze me nu met Java Swing neergezet...

[curry684]

.oisyn schreef op 07 februari 2003 @ 14:22:
je weet tegen wie je het hebt?

*rawr*

Ennuh hobbit_be: als je het goed doet teken je nooit buiten de WM_PAINT, dat is alleen nodig bij hele unieke gevallen (dragselects om er een te noemen). In ALLE andere gevallen kun je volstaan met het invalidaten van het window. Direct painten gaat tegen de hele messagebus-structuur van windows in en neemt onnodige performance-leaks voor z'n rekening.

Ook SetText invalidate het window waar het op wordt uitgevoerd en gaat dus bij de volgende WM_PAINT vanzelf mee. Mocht je echt een directe paint nodig hebben (bijv. tijdens een lange operatie) dan gebruik je UpdateWindow.