Limit on cbWndExtra Bytes?

[Frederick J. Harris]

I recall reading several years back in a tutorial Chris Boss wrote that Windows 95 may have had a 40 byte limit to the number of cbWndExtra bytes one could allocate in the WNDCLASSEX structure, but I seem to recall him mentioning that there was no such limit with the newer operating systems.  Does anyone have any further info on this?  So far in my coding I've respected these numbers and never allocated more than 10 four byte 'slots' to store things; if I needed more I used Window Properties.  However, I really don't like Window Properties that much.  And if one uses structures & pointers it gets messy and one has to take extra time thinking through pointer notation.  I'd really prefer to just be able to allocate a few more four byte slots.

[José Roca]

Because extra memory is allocated from the system's local heap, an application should use extra window memory sparingly. With system version 4.0 or later, the RegisterClassEx function fails if the amount of extra window memory requested is greater than 40 bytes. If an application requires more than 40 bytes, it should allocate its own memory and store a pointer to the memory in the extra window memory.

http://msdn.microsoft.com/en-us/library/ms633574(VS.85).aspx#extra_window_memory

[Frederick J. Harris]

Thanks Jose.  It sounds like that 40 byte number is real then.

[Patrice Terrier]

I have no problem with VISTA and XP allocating 14 * 4 = 56 bytes.

[Patrice Terrier]

Dixit MSDN:

Windows 95/98/Me: RegisterClass fails if the cbWndExtra or cbClsExtra member of the WNDCLASS structure contains more than 40 bytes.

This limit doesn't seem to apply to NT based OS.

[Frederick J. Harris]

Well then, what I seemed to recall from Chris was right.  If 56 works that would give me four more pointers I could store there.  Its just neater than convoluted pointer notation with structures full of pointers!  I do recall somewhere you've mentioned Patrice that you like to store things in a non-visible listbox.  That too is a novel idea.

[Edwin Knoppert]

These 'bytes' are not so handy to use since every user of the class can accidently overwrite the contents.
Also.. when a control is superclassed they may forget to reserve the extra bytes.
I always use SetProp() GetProp() API since they allow unique names.
Side effect is that you'll need to remove them on destroy.
But then.. having extra memory declared and placed as pointer in the extra bytes as well.

[Patrice Terrier]

The createDialog API already uses 30 bytes for the #32770 class.

However if you use CreateWindowEx with your own class then you can safely use it and assume that nobody else will use it.

You have a good example showing you how to use it, in the BassBox, MovieBox, and GDImage SkinEngine

' DO NOT use or alter these properties!
%FORM_TopLeft     = 1  ' Skin top left corner
%FORM_TopMid      = 2  ' Skin stretched top mid
%FORM_TopRight    = 3  ' Skin top right corner
%FORM_SideLeft    = 4  ' Skin stretched left side
%FORM_Center      = 5  ' Skin center
%FORM_SideRight   = 6  ' Skin stretched right side
%FORM_BottomLeft  = 7  ' Skin bottom left corner
%FORM_BottomMid   = 8  ' Skin stretched bottom side
%FORM_BottomRight = 9  ' Skin bottom right corner
%FORM_PaintDC     = 10 ' Internal DC
%FORM_PaintBitmap = 11 ' Memory Bitmap
%BACK_PaintBitmap = 12 ' Memory Bitmap

%EXTEND_EXTRA = %BACK_PaintBitmap ' %FORM_PaintBitmap ' MAXIMUM 40 bytes on 95/98/ME

...

[Patrice Terrier]

Ed,

Yes a hidden listbox is a very valuable to store pointers and all sort of things,
but you can also use SetWindowText/GeWindowText to store informations in a hidden child window.

Most people have a sort of mental blockage to what they can do with generic window classes, but indeed there is no limitation on how you can use them when doing low level programming

...

[José Roca]

 
4 bytes are enough to me. I can store in it a pointer to a class and have in that class all kind of data and methods and properties to manipulate it.

[Patrice Terrier]

About mental blockage,

here is an example of technic being used very often inside of a screen designer to embed hidden resources:



in this screen shot, there are several bitmaps being used to change the icon inside of a popup menu that are stored outside of the view port in distinct picture box containers.

There are also several hidden buttons that are being used to fire specific events, but they are protected from the user because they are also located out of the main window frame.

To fire those events, i am using something like that:

Code Select Expand


API("USER32", "PostMessageA", nObjectHandle, 513, 0, 0) // WM_LBUTTONDOWN
API("USER32", "PostMessageA", nObjectHandle, 514, 0, 0) // WM_LBUTTONUP

...