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?
i see no event about the change of row count.
but because u add/remove/removeall the rows by methods you could raise a event after this call.
i see 3 options
using extends to add extra methods to the listbox
global modul with methods add(listBox,data)
compare last count / current count with a timer
I’m trying to introduce a system, where I don’t need to make a call from every event, such the various addrow, insertrow, expandrow, collapseRow and deleteRow functions.
It might be possible for an object to grab the method pointers, replace them with a another method pointer, that calls the original method, and then takes a list count.
I was hoping that there might be an undocumented way of capturing when the list count changes, after all the ListBox knows when this happens.
why you avoid this sub-classing? it is so useful.
this example is only based on stored data beside a listbox
Lazy Loading Data with ListBox
i think it fit better into the MVC Design Pattern.
[quote=489873:@Sam Rowlands]I’m trying to introduce a system, where I don’t need to make a call from every event, such the various addrow, insertrow, expandrow, collapseRow and deleteRow functions.
[…]
I was hoping that there might be an undocumented way of capturing when the list count changes, after all the ListBox knows when this happens.[/quote]
What are you really trying to do? Describe the user experience you’re trying to achieve without the technology you think you need. It sounds like you could have each row be responsible for itself. I’m not sure if that will work for your situation without more info.
Feel free to reach out privately and I’d be happy to help dig into specifics.
Without subclassing, one way would be to keep an integer property of the total number of rows next to the listbox (e.g. on the window), then on every CellBackgroundPaint check the current RowCount against that, if its different you have a change in the number of rows.
If Me.RowCount <> previousRowCount Then
system.DebugLog("change in rows")
previousRowCount = Me.rowcount
End If
I think that’s probably going to be the best way, as in theory the paint event should fire when the list changes, I’ll test this out.
I keep telling people to not do any logic processing in the paint event, but this seems like the most sure fire way. I was kind of hoping that a Xojo engineer would chime in and say I can use a certin function or register for an event or listen for a notification.
Using the paint event to detect changes and raise custom events for them is often the only way… It’s an old “trick” that many have used over the years.
I do that extensively in my mergedCell Listbox and for how I use it, I have not seen any issues.
-Karen
Oh I forgot to add, you can keep it all internal to the CellBackgroundPaint by using a Static instead of an external property.
I have gotten bitten using statics a few times by not thinking through all the use cases, which i why i would rather use a private property on a subclass.
If the static is in a listbox subclass, that is true only if there is only one instance of the subclass instantiated at the same time in the entire app and that means not just on that window but any instantiated window that uses an instance of that subclass.
If a static on the window , it’s true if you only have instance of that window open at any time!
In other words if you can have more than one instance of that window open at time, the state can get messed up!
I have written code that worked OK initially but as the app grew, using statics caused those types of issues.
-karen
Aye, I assumed Sam wasn’t going to use it elsewhere because of his request not to sub-class which is why I mentioned it as it keeps things neater.
I appreciate both your suggestions. Ultimately I’m trying to design a solution that can/may be used by others. So one of the goals is to keep it simply to introduce. Ironically I might end up having to subclass, but with your suggestions I only need to capture the one event, instead of several.
There’s still a long way to go; as some other things didn’t work out as simply as I’d hoped.