Nothing works if you open a large file and then a small file

[Robert Leach]

Anastasija found & demonstrated this issue in the meeting on 11/20/2014. She opened a large file using "Open recent" and then opened a small file and after that, none of the menu options would do anything.

[Christopher Keil]

Edit: You can skip the explanation, I seem to have solved it.

This is related to properly resetting the MapContainers when loading a new model. The exception occurs in TextView/ ArrayNameView when TreeView is trying to write the new labels.

It looks at the String array for the labels (#342 in TextView: headerSummary.getSummary(headerInfo, actualGene);) where 'actualGene' is an integer, the index of the label. actualGene's maximum 'end' is defined from the currently set 'usedPixels' in the related MapContainer through map.getUsedPixels(). (globalYmap in case of TextView, globalXmap in case of ArrayNameView).

At the point of setting up the GUI elements for the newly loaded model in the DendroView.makeDendro() the TextView.update() method is called via the implemented Observer pattern (TextView gets notified by HeaderSummary's setIncluded() method). The array of the new (and now smaller) string labels is then set in TextView, as the Observable object in update() is of type HeaderSummary, but the indices to access the array in selectionChanged() are still the old ones because 'updatedPixels' hasn't been updated in MapContainer (the irony...).

So when a smaller file is loaded after a bigger one, selectionChanged() starts throwing ArrayIndexOutOfBoundsExceptions. The new headersummary array might be of length 133, while the previous one was 1000, for example. Accessing the new label array of length 133 with any old index > 132 will then cause the crash to happen.

I haven't figured out a fix yet but this is definitely the problem.

Edit: The problem was map.getUsedPixels() in TextView and map.getMaxIndex() in ArrayNameView. It didn't make any sense to use these map properties at this point anyway, so I substituted the code with the lengths of the matching headerInfo arrays, which are actually being iterated and already updated at that time. According to my (limited) tests everything works as it should now and this 'blocker' seems resolved. I will post a JAR with the fix tonight.

[Christopher Keil]

This blocker bug appears to have been solved in my last commit as Anastasia reported the related test jar to work well.

[Anastasia Baryshnikova]

Tested. Doesn't seem to be an issue anymore.