mcLB2, a new Windows control

[NoCforMe]

Looking at the source I see that _SETTEXT and _SETDATA use HIWORD( LParam ) to select the row. So I guess there's currently a 64k limit for rows, at least in 32-bit Windoze?

I completely missed that. Easily fixed: I can have the user pass a structure of 2 DWORDs for row & col., since I guess we're aiming at supporting >64K rows.

But really: how realistic is that? How many programs are going to have more than a few dozen rows at most? What applications can you think of where we'd need to have that many rows? I can't think of any, so I'm wondering just what ridiculous lengths I should go to in order to achieve that notional capability ...

However, what I really miss is some visual response for the user so he/she can see what item is currently selected. The MS listview even allows multiple rows to be selected. Another side note: your control doesn't handle keyboard input - AFAICS the only way to scroll is using the mouse.

Noted. Both selection and keyboard input could be added (my other mcLB control has them). Let me see what other kinds of input I get here.

[NoCforMe]

BTW, two things that definitely need fixed:

1. Destroying controls and creating new ones:
Currently I'm using the next available slot in the "master control table" for the next control created, with no regard for controls that get destroyed.

Easily fixed, though: I'll use the ctrlHandle member to see if a "slot" is available when creating a new control: either zero, meaning a control was never created there, or -1, meaning a control was destroyed and the slot is available.

2. Text heap:
Currently there's one text heap for all controls. No good, as no text heap memory can be released when a control is destroyed, so each control will have its own text heap.

[NoCforMe]

Looking for input on this project. If interested, maybe you can respond to this informal questionnaire:

1. Should this control be responsive? IOW, should you be able to click on rows to select them, and have them highlighted? (Or use the keyboard.)
And should you be able to select certain columns in the row, or should the entire row be highlighted?

(If selection is implemented, then that implies that the control will issue notifications for both single and double clicks, using WM_NOTIFY.)

2. Is it important that the control be able to handle > 64K rows? (Kind of a moot point, as it now does with my most recent changes. But I'm just wondering who in the world would need this kind of capacity.)

3. Should this control be usable from C (or other non-assembly language) programs? This would only require creating a .h file for it.

4. Should the user be able to change column characteristics (font, text & background colors) on the fly? Currently these are set at control-creation time and can't be changed thereafter.

5. Any other features you think this control really really needs?

I'm open to suggestions--to a point. I'm not sure about making this a "common controls" class control; it was just kind of a groovy idea that I followed through on. But I'm listening.

[jj2007]

Over 64k rows is a lot, but not unrealistic, see below one from the UN that approaches that limit. Re selections, yes, it is very important to know what you selected.

[sinsi]

1. Should this control be responsive? IOW, should you be able to click on rows to select them, and have them highlighted? (Or use the keyboard.)
And should you be able to select certain columns in the row, or should the entire row be highlighted?

It's good to know where in a list you are, and I would expect the full row to be selected.

2. Is it important that the control be able to handle > 64K rows? (Kind of a moot point, as it now does with my most recent changes. But I'm just wondering who in the world would need this kind of capacity.)

Not really, but you can guarantee that one person will want it, and bitch and moan that it's limited. However, it's so trivial to implement that you night as well.

3. Should this control be usable from C (or other non-assembly language) programs? This would only require creating a .h file for it.

Don't care

4. Should the user be able to change column characteristics (font, text & background colors) on the fly? Currently these are set at control-creation time and can't be changed thereafter.

Yes to all three, what is legible to you may just be blobs to another.

I would't personally use it as I think a ListView is easier

[sinsi]

OK, you have piqued my interest in custom controls. My thoughts:


A control should be self-contained, so use a structure for per-instance data (per control).
When you register the class, add 4 bytes (SIZEOF PTR) to WNDCLASSEX.cbWndExtra. This would be a pointer
to any private data, stored in a structure.

On WM_NCCREATE you would allocate memory for the structure and initialise it, using
SetWindowLong to save it to that control.

On WM_NCDESTROY you get the structure with GetWindowLong then free any memory in the
structure then free the structure itself.


No need to keep track of created controls, the HWND takes care of finding the data.

[NoCforMe]

4. Should the user be able to change column characteristics (font, text & background colors) on the fly? Currently these are set at control-creation time and can't be changed thereafter.

Yes to all three, what is legible to you may just be blobs to another.

Yes, but all of these can be set when the control is created; are you suggesting being able to change them after creation? Could be done, with a bit of complexity.

I would't personally use it as I think a ListView is easier

Now that's an interesting data point, so noted: I haven't seen much interest in using this yet here, so it might just end up being another one of my private custom controls.

But really, is it easier for you to use a ListView? I'm surprised, as I find that control's interface to be a hot mess. But maybe you've figured it out and have a set of routines to handle it. One thing I found annoying was that in order to delete rows in a ListView you have to start at the end and work your way backwards.

A control should be self-contained, so use a structure for per-instance data (per control).
When you register the class, add 4 bytes (SIZEOF PTR) to WNDCLASSEX.cbWndExtra. This would be a pointer to any private data, stored in a structure.

Good suggestion (and easy to implement) on the private data, always a handy thing.
The control is that way now, with a "master control structure" ($mcs2) for each instance.

On WM_NCCREATE you would allocate memory for the structure and initialise it, using SetWindowLong to save it to that control.

I do this, but on WM_CREATE instead. No need to use SetWindowLong(), as all that is done internally. But yeah, basically the same scheme.

No need to keep track of created controls, the HWND takes care of finding the data.

Yes, except that I need to locate the master control structure for each control. I suppose you could use GWL_USERDATA as a pointer to that structure. (I have a routine, FindControl()) which locates the structure using the handle passed into the control's proc.)