Programatically initialise subwindows ?

[phantomwhale]

I've been going down a route for the last week on the SWEX combat tracker that may have just hit a clanger of a problem.

The setup is I have a windowlist of "combatantgroups". This class is a windowclass that contains (1) a subwindow, with a class of "combatant" and (2) a windowlist of class "combatant".

The logic behind this changes is each main windowlist entry WILL contain a combatant (this is the subwindow) and MIGHT contain another list of combatants (any "grouped" combatants who act at the same time as the main one). And by using a subwindow, I can re-use the same inner window class in for both main and grouped combatants.

The problem comes with subwindow initialising. I've just found that the subwindows don't get initialised until they are on the screen. Meaning if I add new combatantgroups that appear after the end of the window, they don't get "initialised", and therefore don't get cards dealt to them or anything.

The same problem appears on the mini-tracker - it will show five combatants, but just the first five (properly ordered). When I scroll down to look at other combatants, the subwindow initialises and the combatant suddenly jumps into place on the list (as the applySort() method gets triggered).

The workaround is the GM needs to scroll to the bottom of the combatant lists ONCE, but the players need to scroll to the bottom of the minitracker every round. This... isn't going to work !

What I was wondering is if there is some way of getting all the subwindows to initialise programatically ? Might involve some trickery, as I don't see an API call for it...

[Moon Wizard]

I'm going to have to look at this closer when I return from Gencon to see what is going on. Can you send me a copy or link to what you are working on via email at [email protected]?

Thanks,
JPG

[phantomwhale]

Ah yeah, it's Gencon now. Jealous.

I found a fix, although it has a slightly "flickery" side-effect that I might have to live with. Before the search ordering went "player with cards first, ordered Ace down to two, then players with no card".

The subtle thing here was "having no card" was the same as "actually this window hasn't even had it's subwindow initialised yet" (e.g. both a nil return)

So the trick I used was to change the ordering to "windows that don't appear to even have been initialised yet, then cards from Ace to Two, then windows that have no card yet". In a nutshell, this was done by creating a "no card" object, which is different to a simple nil return.

So when you add a new combatant to an existing combat, it's initially put to the top of the list (as it's not had it's subwindow initialised yet). But the moment it appears at the top of the windowlist, the subwindow is revealed and is forced to initialise. Once this is done, I manually kick off an "applySort()" which notes that the window now has "no card", and puts it to the bottom of the order. All this happens in a few milliseconds, with a noticeable "flicker".

Time will tell if I can live with this flicker. I think it's OK now, but that might be the part of my brain that can't stand to rewrite the combat tracker AGAIN, so I'll let it sit for a while.