Listen to a listboxes events without having to subclass it
The long and the short of it, I want to know when the number of rows in a listbox changes. Ideally I want to avoid sub-classing the listbox to get at this info.
I don’t mind patching via AddHandler as long as I can then call the original code in that event?
That would be handy except - there IS no event to listen to
ListCount and the newer RowCount are computed properties, they do not have an associated event to addhandler to listen to when a row is added or removed
So short of subclassing listbox and intercepting the addrow, insert row, remove row method and raising a “RowCountChanged” event you dont have the opportunity to do what you’d like
I like Julians idea of using CellBackgroundPaint to call a method that checks for a change in the row count. This can be done easily with or without subclassing. If I’m not mistaken, CellBackgroundPaint should fire whenever the row count changes. But I could be mistaken…
People have being doing that for the listbox in RS/Xojo for a long time. My MergeableListbox subclass I wrote 10 years ago does that .
I did not answer because I did not think that is what he wanted because he said he did not want to subclass, and it’s an awfully messy thing to do without subclassing IMO.
For those that are curious, I am building a wrapper for the listbox and need to know when the listcount of the listbox changes, I didn’t want to subclass to capture every method and event that affects this.
So it seems like utilizing the cellbackground event might be the easiest way to do this. When the listcount changes then I need to do some updating. The other advantage I can see of doing it in the paint event is that it should be coalesced and shouldn’t fire every time a row is added, only when the user has finished adding rows.
I was hoping someone from Xojo would step in and give me a ptr, but hey.
Maybe easy, but kind of dangerous. The event is not fired only once. Each time you add a new row, this event is fired THE NUMBER OF VISIBLE CELLS.
So, if you have a grid with 10 visible colums by 20 visible rows, Each time you add a new row this event is fired 200 times. (No matter how many total rows the list has)
Plus another 200 times each time the window should call resizing (Even if the table is not resized nor affected by the new window size)
That is why one puts code like this in teh cell paint event:
If me.RowCount <> me.LastRowCount Then
me.LastRowCount = me.RowCount
RaiseEvent NumRowsChanged
End if
even if this code were put into a subclass it would be reusable in any listbox you wanted just by changing their supers
otherwise this code has to be put in each instance
but … maybe there is only one instance to worry about ?
My concern with Subclassing is that I intend to release this code, and in the past when I’ve done things like this, the order in which the user mixes it with their subclasses causes issues.
My ideal situation was to create a delegate of sorts, that receives the message from the super, then it can check some things and do it’s job.
But hey, it is what it is. So it looks like Imma have to do a Subclass, but I’m hoping to only worry about one event.
I understand your concerns and I have contemplated them.
The last point, can be subdued by using Layer-Backed Views, but it’s only one situation.
Each way I go with this is going to cause wasted cycles, as I’m basically chasing whatever it is that Xojo does underneath.
In the past I’ve attempted to make my own ListBox type of control, but most people are just using the default one, and I don’t want to have to re-invent the entire wheel, just so I can apply a patch to the puncture.
Yup… It is so in need of some love, and I’m willing to give it love, but I’m not willing to start from scratch, unless I get paid to re-build it from scratch.
I’ve been thinking more about about my design… Which is good I guess?
I just have to decide if putting in the most amount of work, to save cycles on paint, is more efficient than doing less captures (less points of failure), but inuring more overhead in the paint event.
I mean if I capture listcount adjustment methods and events, I can coalesce the updates, even then it will still add overhead to each time the count is changed.