From: Erik V. <eri...@hc...> - 2006-02-08 22:54:28
|
> The bigger issue that bothers me is that many of these classes have > constructors that are pulling data from other UI objects. > > This strikes me as something that severely breaks model/view > separation. > > For example, the ORWindow shouldn't be passed an OperatingRound, it > should be checking GameManager for what the current round is, and > whether it's an OperatingRound. That is right, or whether there isn't any round at all yet (which I believe is true when the window is created). > I've been looking at cleaning this up and making ORWindow behave a bit > more like StockChart, but it's looking like the changes are going to > be very invasive and require rewriting a bunch of areas of the UI. Talking about StockChart: a while ago I was getting pretty annoyed by double flickering in the StatusWindow after each share Sell or Buy action. This turned out to be just the area where StatusWindow overlapped StockChart. It looks like if StockChart is fully repainted twice after each action in StatusWindow, even if no price has changed at all! On this point I would prefer to have StockChart behave more like the other windows, where only parts are repainted where and when something has changed. That would speed up repainting too. The ORWindow constructor is way too complicated as it is, no doubt it can be simplified. Erik. |