From: Brett L. <wak...@ea...> - 2006-01-12 23:27:57
|
> >> Yes, it was the NYC. It was attempting to lay the connecting >> tile to New York, but it seems to be any hex location because >> the second message was generated by attempting to lay a tile >> in a different hex. > >I suspect that this is caused by the fact that in OR 3.1 NYC has >shifted down one place in the operation order, below NYNH. >Class OperatingRound correctly thinks that it is NYNH's turn >(I added this expectation to the display), but the View side >is apparently confused and acts as if NYC has the turn, which it has not. > >Previously, with a fresh new JFrame was created for each OR, >with the newest company operating order. >The JPanel in the new composite ORWindow does not seem to be >refreshed between consecutive ORs, leaving >the operating order as it was in the previous OR. > >I will have a detailed look at the code later. > I suspect that this section of code was written before you implemented multiple ORs between each SR. So, I think we'd have this bug regardless of the unified JFrame or not. (I think I've encountered it before.) Either way, I think you're right that the root cause is the view and model are out of sync. > >One other problem is, that during the OR I cannot make the >Stock Chart window visible. Perhaps you can look at that? > Yeah, I just noticed that issue myself. I suspect it has something to do with incorrectly setting the StockMarket window visibility to false. I'll check it out. >To help myself here, I have changed all Price fields to >show both the price and the location on the stock chart >(also in the Log Window). > >I also had a compilation error that GUIHex and HexMap could no >longer access StatusWindow.orWindow, because that field seems >to have been made private. I now use a method to get this object >(the proper way!). > Huh. I'd swear I committed changes with a getter method for orWindow. Apparently I was wrong. ---Brett. |