How often have you wanted to display some information that's tabular in nature in a program, and found your choices limited by the available Windows controls? There's the lowly listbox, which is limited to a single column per row. Then there's the more advanced List View, which allows multiple columns but is a horrendous pain in the ass to program.
The answer to the above might be "not very often" or even "never", but supposing it only came up even only once or twice: wouldn't it be nice if there was another choice of control here?
Well, NoC Laboratories, GmbH is pleased to announce the release of our mcLB2 control ("mick-ell-bee"--it's Scottish). It's a multi-column listbox that's easy to program and very flexible.
Here's a sample, using default fonts but custom colors
mcLB1.jpg:
Complete source and a testbed program attached below.
mcLB2 is a display-only control: all interaction with it is through the programming interface (all via SendMessage()). You set the number of columns and then can add and delete rows and set the text for each column in each row. You can select column headers. You have control over the formatting of all elements: the fonts used for each column, the font for the header, the text and background colors for the header and for each column. (This is all set at control creation time and can't be changed dynamically thereafter.)
Here's another sample, with a custom font for the center column:
mcLB2.jpg
Please play around with this, maybe use it in a program of your own, and let me know what you think. It's pretty much finished, but I'm open to suggestions. As I said, it's display-only, and I don't think I see it becoming a responsive control where you can select items by clicking on them. That could be done, and is already incorporated in mcLB2's predecessor, mcLB, which is a horizontal multi-column listbox that allows selection.
It's really intended for tabular info display. And the display can be updated dynamically at any time.
(To use it, just link mcLB2.obj with your code. Be sure to include mcLB2.inc in your code. And you'll need to call InitmcLB2() before creating a control with CreateWindowEx().)
I remember over 20 years ago using ListBox style LBS_USETABSTOPS with message LB_SETTABSTOPS for columns.
A few queries about the include file
mcLB2_COLINFO STRUCT
colWidth DD ?
colFontPtr DD ?
colBgColor DD ? ;-1 for default.
colTextColor DD ? ; " " "
colAlign DD ?
hdrTextPtr DD ?
mcLB2_COLINFO ENDScolFontPtr is this a pointer to a LOGFONT? Or a HFONT?
colBgColor and colTextColor are these RGB? Or HBRUSHes?
And a petty one, to fit in with the naming style InitmcLB2 should be mcLB2_Init
Is it based on a standard ListBox? I remember they used to have a 32K item limit...
Quote from: sinsi on May 19, 2025, 02:11:52 PMA few queries about the include file
mcLB2_COLINFO STRUCT
colWidth DD ?
colFontPtr DD ?
colBgColor DD ? ;-1 for default.
colTextColor DD ? ; " " "
colAlign DD ?
hdrTextPtr DD ?
mcLB2_COLINFO ENDScolFontPtr is this a pointer to a LOGFONT? Or a HFONT?
Handle to a font.
QuotecolBgColor and colTextColor are these RGB? Or HBRUSHes?
RGB colors.
QuoteAnd a petty one, to fit in with the naming style InitmcLB2 should be mcLB2_Init
You're probably right. Whether it'll get changed is anybody's guess ...
QuoteIs it based on a standard ListBox? I remember they used to have a 32K item limit...
Nope. Completely hand-rolled. No item limit that I know of, as I'm doing dynamic memory allocation (you can check the source to see how this works).
Quote from: TimoVJL on May 19, 2025, 01:47:26 PMI remember over 20 years ago using ListBox style LBS_USETABSTOPS with message LB_SETTABSTOPS for columns.
Yeah, you can kinda-sorta make a regular listbox multicolumn. But mine is the real deal.
OK, tried a thrash test by clicking Populate Control over and over until something broke...
First, all OK, then maybe 20 or so clicks later rows were added with no text, later (another 20 clicks?) the column headers' text disappeared, eventually
(5640.62e0): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=00000000 ecx=00000000 edx=000d0000 esi=11011220 edi=0060e9c0
eip=76c7a06e esp=004ff1f8 ebp=004ff29c iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
gdi32full!ScriptStringAnalyse+0x61e:
76c7a06e 0fb783a0000000 movzx eax,word ptr [ebx+0A0h] ds:002b:000000a0=????
Thanks for the stress test. Ugh, now I need to do some debugging.
I'm guessing maybe a memory-allocation problem, but it also might just be some kind of boundary condition.
There's one problem here
; Biggerize the heap:
INVOKE HeapReAlloc, _HeapHandle, HEAP_REALLOC_IN_PLACE_ONLY,
[EBX].$mcs2.itemHeapBase, $itemAllocSize
ADD [EBX].$mcs2.itemHeapAvail, $itemAllocSize
Forgot to do the addition for the new size of the block in HeapReAlloc, so it doesn't ever make the block bigger.
You should also probably check that it succeeds, realloc_in_place will only get so big before the block needs to be moved to expand.
The TextHeap realloc has that failure check which is probably why the text stops appearing after so many lines, the in_place HeapRealloc fails and thus _Text2Heap returns null pointers from then on.
Storing offsets to things in these heaps rather than direct pointers would remove neccesity of IN_PLACE since then it won't matter where the block is, the offset will remain the same,
Quote from: adeyblue on May 20, 2025, 06:35:22 AMThere's one problem here
; Biggerize the heap:
INVOKE HeapReAlloc, _HeapHandle, HEAP_REALLOC_IN_PLACE_ONLY,
[EBX].$mcs2.itemHeapBase, $itemAllocSize
ADD [EBX].$mcs2.itemHeapAvail, $itemAllocSize
Forgot to do the addition for the new size of the block in HeapReAlloc, so it doesn't ever make the block bigger.
Duh. Brain fart there: was thinking that the reallocation would increase the total allocation by that amount. (It don't work that way.) Thanks.
After a grueling nonstop bug-killing session, I've located and fixed all those problems with mcLB2. I think. I'm pretty sure. 95% sure. Well, I guess we'll have to wait until someone else really bashes this thing; I did some and found no problems.
So first of all I'd like to thank those (especially sinsi and adeyblue) who took the time to run this, ran into problems and reported them here. I appreciate what you've done, which of course is what I should have done in the first place. The problems were all in the memory-allocation stuff (HeapAlloc() and HeapReAlloc()), because of the reallocations ending up at different addresses than the original ones, and also because I had ... no error checking at all for those calls. That's no way to make a robust control that people might actually want to use in their programs.
@adeyblue, thanks especially for your suggestion about storing offsets instead of pointers in my heap: that's just what the doctor ordered. The problem, for those not familiar with it, is that when you make an initial allocation with HeapAlloc() and store its address, when you have to enlarge the heap with HeapReAlloc(), the address returned will be different from the original one. Therefore you can't store pointers to what's in the heap since they'll all be wrong after reallocaton. I should have remembered this from a previous project with a similar data scheme: I think I'll make a sign, USE OFFSETS, NOT POINTERS! to hang over my computer desk. (And I got rid of the HEAP_REALLOC_IN_PLACE_ONLY flag for HeapReAlloc(), which as you pointed out isn't reliable.)
So now maybe someone can tell me what they think of the control itself rather than its problems ...
Quote from: NoCforMe on May 21, 2025, 06:59:52 AMSo now maybe someone can tell me what they think of the control itself rather than its problems ...
Not yet...
If I add over 64K items the scrolling doesn't work properly - I scroll to the bottom but when I release the scroll it auto-scrolls to near the top.
The only help I could find in a hurry was this
QuoteNote that the WM_VSCROLL message carries only 16 bits of scroll box position data. Thus, applications that rely solely on WM_VSCROLL (and WM_HSCROLL) for scroll position data have a practical maximum position value of 65,535.
However, because the SetScrollInfo, SetScrollPos, SetScrollRange, GetScrollInfo, GetScrollPos, and GetScrollRange functions support 32-bit scroll bar position data, there is a way to circumvent the 16-bit barrier of the WM_HSCROLL and WM_VSCROLL messages. See GetScrollInfo for a description of the technique.
Yes:
QuoteThe GetScrollInfo function enables applications to use 32-bit scroll positions. Although the messages that indicate scroll bar position, WM_HSCROLL and WM_VSCROLL, provide only 16 bits of position data, the functions SetScrollInfo and GetScrollInfo provide 32 bits of scroll bar position data. Thus, an application can call GetScrollInfo while processing either the WM_HSCROLL or WM_VSCROLL messages to obtain 32-bit scroll bar position data.
To get the 32-bit position of the scroll box (thumb) during a SB_THUMBTRACK request code in a WM_HSCROLL or WM_VSCROLL message, call GetScrollInfo with the SIF_TRACKPOS value in the fMask member of the SCROLLINFO structure. The function returns the tracking position of the scroll box in the nTrackPos member of the SCROLLINFO structure. This allows you to get the position of the scroll box as the user moves it.
Ugh. OK, I'll try this. Shouldn't be too hard I guess.
OK, fixed.
Suggestion in the MS docs was just the thing. Here's all the code I added:
;***** Scroll to thumb: *****
scr_TH:
; Get scroll position from GetScrollInfo():
MOV sbInfo.cbSize, SIZEOF SCROLLINFO
MOV sbInfo.fMask, SIF_TRACKPOS
INVOKE GetScrollInfo, hWin, SB_VERT, ADDR sbInfo
MOV EAX, sbInfo.nTrackPos
Check it out. I didn't include a new version of the testbed. You probably did what I did, bumped up the # of rows created by the "populate" button. Easy peasy.
Nice work!
QuoteQuoteIs it based on a standard ListBox? I remember they used to have a 32K item limit...
Nope. Completely hand-rolled. No item limit that I know of, as I'm doing dynamic memory allocation (you can check the source to see how this works).
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?
Not a big issue IMO, since for really large lists you'll probably rather implement a "virtual" listbox/listview ( that is, something similar to the LVS_OWNERDATA feature in the MS listview.
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.
+1 to the lack of keyboard support, this makes the control unusable for screen readers :(
Quote from: _japheth on May 21, 2025, 08:18:02 PMLooking 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 ...
QuoteHowever, 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.
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.
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.
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.
(http://www.jj2007.eu/pics/MdgData.png)
Quote from: NoCforMe on May 22, 2025, 02:40:30 PM1. 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.
Quote from: NoCforMe on May 22, 2025, 02:40:30 PM2. 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.
Quote from: NoCforMe on May 22, 2025, 02:40:30 PM3. 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
Quote from: NoCforMe on May 22, 2025, 02:40:30 PM4. 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
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.
Quote from: sinsi on May 22, 2025, 11:05:15 PMQuote from: NoCforMe on May 22, 2025, 02:40:30 PM4. 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.
QuoteI 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.
Quote from: sinsi on May 23, 2025, 03:56:30 PMA 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.
QuoteOn 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.
QuoteNo 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.)
Quote from: NoCforMe on May 24, 2025, 05:03:54 AMOne 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.
:biggrin:
I guess that's just a "misunderstanding" on your side - i.e to delete rows 10-12 in a listview of 20 rows, you probably should take into account that after deleting row 10, the former rows 11-12 have become rows 10-11 ( IOW: to delete rows 10-12 you just have to delete row 10 3 times ).
Quote from: NoCforMe on May 24, 2025, 05:03:54 AMYes, except that I need to locate the master control structure for each control.
Why do that, when each control has it's data within?
Let Windows keep track of controls, your code's job is to act on the control.
I use
WM_NCCREATE because there are some things that are needed well before we receive a
WM_CREATE and it's the first message posted.
Same reason for using
WM_NCDESTROY, it's the final one received. I read this tip in a Windows 95 Programming book, I'll see if I can find it and post the reasoning behind it.
If my knowledge is correct, WM_NCCREATE is posted before the window is fully created, but after the call to CreateWindowEx. Pretty sure you're supposed to SetWindowLongPtr(hwnd, GWLP_USERDATA, ...) here if subclassing. You can also veto creation when handling it by returning FALSE.
Quote from: Quin on May 24, 2025, 12:17:33 PMIf my knowledge is correct, WM_NCCREATE is posted before the window is fully created, but after the call to CreateWindowEx. Pretty sure you're supposed to SetWindowLongPtr(hwnd, GWLP_USERDATA, ...) here if subclassing. You can also veto creation when handling it by returning FALSE.
You can veto creation when handling
WM_CREATE as well (though using a different return value, -1 instead of zero). That message is just sent earlier than
WM_CREATE. No subclassing is going on here.
Well, all this is very nice, but pretty much icing on the cake. The control works just fine as it is; changing it to use
WM_NCCREATE would be pretty much six of one, half a dozen of the other. From my point of view there's really nothing to be gained by using the NC version of that message.
What's more of a concern is the apparent lack of interest in people using this control. If I don't get much more feedback soon then I'll just take my toys and go home; no percentage in seeking input on something that nobody wants to use. (No harm, no foul, just a gauge of how much effort I should be putting into this.)
BTW, found this interesting comment in a Stack Overflow thread (https://stackoverflow.com/questions/6289196/window-message-different-between-wm-create-and-wm-nccreate) on these two messages:
QuoteWM_NCCREATE is an example of an arms race in progress. It seems to have been introduced to serve a need where DefWindowProc (or the base window proc of a commonly subclassed window) needed to perform some initialization perhaps before WM_CREATE was processed (or to make up for the fact that many window implementations handle WM_CREATE directly and return TRUE rather than passing it on to DefWindowProc).
WM_NCCREATE therefore is the message you should respond to if you are implementing a default window procedure, that needs to perform initialization before the users window proc handles the WM_CREATE message. WM_NCCREATE also MUST be passed on to the appropriate DefWindowProc, probably before you do your own processing as some lower level aspects of the window are clearly in an uninitialized state before WM_NCCREATE is processed.
If trying to guarantee first-look processing is NOT your consideration, then WM_CREATE is the appropriate place to perform your window initialization: All other layers that might have jist-in-time setup via WM_NCCREATE have been done, and the window is in a stable state wrt things like its non client metrics, screen position etc.
Or: If you don't know why you should use WM_NCCREATE over WM_CREATE, then you should not be using WM_NCCREATE.
Quote from: NoCforMe on May 24, 2025, 12:28:00 PMWhat's more of a concern is the apparent lack of interest in people using this control. If I don't get much more feedback soon then I'll just take my toys and go home; no percentage in seeking input on something that nobody wants to use. (No harm, no foul, just a gauge of how much effort I should be putting into this.)
It seems to have been made for a specific purpose, whereas most controls are more general but more complex because of it.
If I want a simple list then a ListBox is fine, but if I want proper columns I will use a ListView.
Perhaps think of a control that is in other frameworks but not ASM.
For example, dotnet has a DataGridView (very complex) and a Splitter/SplitContainer that I would love to use.
My splitter is sort of working but really low priority. One day...
Quote from: sinsi on May 24, 2025, 12:44:29 PMPerhaps think of a control that is in other frameworks but not ASM.
For example, dotnet has a DataGridView (very complex) and a Splitter/SplitContainer that I would love to use.
DataGridView: tell us more. Sounds like it's at least related to my mcLB.
QuoteMy splitter is sort of working but really low priority. One day...
I started work on a splitter too (not a control, just splittable windows). A bit tricky; still on the "unfinished" pile.
Here are the docs for DataGridView (https://learn.microsoft.com/en-us/dotnet/api/system.Windows.forms.Datagridview?view=windowsdesktop-9.0).
I've used it from C# and VB.NET, it works quite well.
Unfortunately no pictures there, but I was able to find some elsewhere.
So it looks a lot like a ListView, though a whole lot more complex and with much more functionality.
So, to use that famous meaningless tautology, my mcLB2 is what it is.
Which is to say that it is my vanity project. Something I thought was fairly kewl and worth developing. And which did finally did succeed in seeing the light of day in terms of functionality; it worked. Always a good moment for me.
I appreciate the help I got here from members who pointed out the flaws and made suggestions for improvements. I now have a stable, usable Windows control that I can use. (And others as well.)
Trying to pretend that I, a lowly hobby programmer, could somehow outperform the mighty development teams at Redmond devoted to developing controls, would be a massive conceit, one which I do not claim. I do like to create my own homegrown, idiosyncratic Windows controls, as much an exercise in "I can do it!" as anything else.
Still working on The Ultimate Edit Control. We'll see how far that goes ...
Quote from: NoCforMe on May 24, 2025, 02:17:41 PMTrying to pretend that I, a lowly hobby programmer, could somehow outperform the mighty development teams at Redmond devoted to developing controls, would be a massive conceit, one which I do not claim.
Easy enough for them to "outperform" when they have hundreds of programmers building on thousands of programmers prior work from the last 40 years (and they still get it wrong).
Quote from: NoCforMe on May 24, 2025, 02:17:41 PMI do like to create my own homegrown, idiosyncratic Windows controls, as much an exercise in "I can do it!" as anything else.
Exactly the right attitude to have.
Congrats!
Quote from: LordAdef on June 18, 2025, 05:53:44 AMCongrats!
Thanks. Maybe you want to try it sometime?