Thread: Type Of Memory In A Control?

Hello,

I'm busy here designing my first fully-fledged Windows control, as in, it responds to all the different messages and draws properly and stuff. But one question's been sticking in my mind...

The control is a bit like an edit control in that it maintains a buffer of data that it displays. I want developers to be able to change the buffer's pointer so it can display what they've just loaded in from a file, for example. The first thing I did was look at the edit control's EM_GETHANDLE and EM_SETHANDLE messages. These use handles to "local memory objects" rather than pointers from malloc that my classical training implores me to churn out.

This got me thinking: in doing this type of message, I would be enforcing a particular type of memory allocator on the developer. Although LocalAlloc, HeapAlloc, GlobalAlloc, etc. all generally get their handles from the same place these days, malloc and new could be from anywhere, given the smell that comes from the C/C++ runtime libraries on a hot day.

So, should I require a type of Windows memory for my Windows control, or is this a misnomer and they're all the same in the end anyway?

I suggest that you make your control a black box. That is, it should handle its own memory. When the user wants to alter or retrieve the data, it should be copied to/from a user provided buffer. This is the general design of the Windows controls. EM_SETHANDLE is an exception, but it is depreceated and virtually never used.

Some of the common controls (list-view, tree-view comboboxex) allow the user to manage its own data by sending a callback message to their parent window when item data is required. For example see virtual list-view.

If you do allow the user to set a buffer, the user should also be responsible for freeing that buffer. This way the user can use whatever buffer is most appropriate (even a static array).

While LocalAlloc, HeapAlloc, GlobalAlloc are similar, the correct free function must still be used.

Hmm, I see your point. I suppose the control is best described as a hex editor, which draws a big buffer full of goop (and is careful to replace nonprintables with ".").

I want to allow developers flexibility in its use, so they could just read a file into memory and get the control to display its contents, specify a memory address and it will read memory, or with larger files use file mapping and the control will let the developer know when its scrolling towards its current limit (Given that I'm drawing all this to a bitmap and BitBlting to display when necessary, I'm trying to avoid the need for massive bitmaps! ). I'm thinking this might require a "chain" of buffers perhaps...

I can see a decent argument in favour of just creating the buffers in the control and copying the data from the host program, but I'm also thinking that I don't wanna copy megs and megs of the same thing, just seems wasteful.

Do you see the pains I'm going through here just to make a useful control?!?

The first control I ever made is similar to what you are doing. It was an IRC window display which supported colored text, word wrapping, and text selection. It took me about 2 months to complete, so I have a good idea of the problems you are going through

I agree with anonytmouse on the memory issues. The user of your control should have no idea what the memory implementation looks like. Memory should be copied when it is transferred to the user, or from the user to the control. Even if the memory is a couple megabytes.

The best advice I can give you is to plan out everything in advance. Decide what features you are going to support beforehand, becuase it is tough to add new features in at the end if your design doesn't support them. Features like word wrapping especially need to be planned out well in advance.