Jump to content
  • Advertisement
Sign in to follow this  
brwarner

Creating Control - Variable Storage

This topic is 4526 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello, I am making a custom control in C++ (WinAPI) and what I have done is just made a WndProc for the control and registered it so it can be attached to a window, now my question: Lets say I was making a bitmap control. I create a WNDCLASSEX for the control and a WndProc. I would also use a few #defines to make custom messages. Let's say one message is SetPicture. If I send a SetPicture message the Bitmap control would get the picture from the LPARAM then store it. Where can I store this kind of information? Is the only way making a global array of bitmaps and then just using the next one each time a new bitmap is made?

Share this post


Link to post
Share on other sites
Advertisement
In the WNDCLASSEX struct, there is the "cbWndExtra" member that allows you to specify the extra memory(in bytes) you want to be associated with every window instance. You can then read/write in that memory using GetWindowLong/SetWindowLong. In your case, you can use 4 bytes to store a pointer to the picture.

An alternative is that you can use named properties(by SetProp/GetProp) to store HANDLE values, which can of course being cast to any pointer type you want.

Share this post


Link to post
Share on other sites
If you want to store a pointer you dont need to use cbWndExtra. Enough space for a single pointer is allocated for every window - it is accessible using Set/GetWindowLongPtr() with the GWLP_USERDATA flag.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
as MSDN says, GWL_USERDATA is "...the 32-bit value associated with the window. Each window has a corresponding 32-bit value intended for use by the application that created the window."

don't use userdata for storage by the control itself. it typically gets stepped on all the time by app code, especially when subclassing. do as mikeman suggested instead, as this is what that storage was intended for.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
it's a control. he should get used to following standard practice.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!