Numeric wares display in warehouses not updating correctly

I see the same thing here. Actually a quicker way to reproduce it is to open HQ, then build military building and watch the number of soldiers remain the same as they leave.

I guess the reason is that the values are not updated often enough to reflect the recent change. I'm sure there was another bugreport mentioning something similar (bug 580073?).

The problem also occurs with the stock window (wares in warehouses)

The reasons is that windows are cached by default. For example, adding "set_cache(false)" in the WareHousesWaresDisplay fixes the problem there.

One solution could be to add this line of code to the constructor of Building_Window, where it would fix such issues in every case of a building window showing varying information, but I am not sure about the performance penalties.

The proper solution would be to call update() on the window when something changes in the building, but I’m not sure what codepath can provide that, given that the UI is somewhat separate from the logic code.

Multiple people have noticed this bug independently now, so I consider it likely players will notice it as well.

Btw, could whoever ends up dealing with this, check whether bug 902464 and bug 952429 are simply duplicates of this?

As discovered in bug 952429, this also affects the ports windows, which I assume are identical with the HQ/warehouse ones.

I’m wondering if it is a good idea to have a very general and very simple signal mechanism from the logic code to the ui code, i.e. a ui object can register with a logic object and then the logic object will call ::update() on the ui object whenever it has changed.

This would allow this bug to be easily fixed and greatly simplify existing code, e.g. in WaresQueueDisplay, which keeps copies of all attributes of the logic object to compare them for changes.

But then I vaguely recall from WiHack that signals were for some reasons not quite welcome – is that true, and what was the reason?

I have pushed a branch that implements this using a boost::signal; the code is very straight forward; the effect though is very nice and slick – when a worker enters the building it updates so fast that I don’t even see the number changing.

I actually have a Observer/Observable class in one of my dangling branches (The one working on the editor), so I agree that it is kinda useful to have.

Your branch renamed build/ which I guess was not intentional. I reverted this before merging. I am also not terribly happy with having the signal being mutable inside the WaresList. It means for one that we can only have one Ui element watching any WaresList and secondly having mutable members is usually not such a good idea and has code smell.

I can see why you wanted to implement the Observer/Observable pattern here. If you feel like it, go ahead. But for now the patch is okay as it stands. Thanks for your work!!

Released in build-18 rc1.