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
[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
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.
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.
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.