Thus spake Gary Krockover: > Joel, > > Are those dialog boxes controllable on a case by case basis? In otherwords, > when you go to launch a new module, you get the Java version of the file open > window, but when you go to select a saved game, you get the OS native versio > n.
I've fixed this in the launcher in my development branch---the same file chooser will show up (almost) everywhere now. Thanks for pointing out the discrepancy. > The one advantage of the Java based window is that it not only remembers the > last folder that was browsed but the position in that folder. So, if you're > adding a bunch of new pieces and have the images in an alpha-numeric list, yo > u then just pick the next image from the file chooser when you open that wind > ow. I tend to name my pieces something like: > > Ger-Inf-32div.gif > > So, after adding the German 32nd Division, it's easy to then pick > > Ger-Inf-33div.gif next. > > I agree with Michel that the OS Native window is better for the saved game/lo > g file selection. > > That is all *if* you can control which of the dialog boxes open with which ve > rsion. > > GJK > I checked into this, both on Linux and Windows, and it seems that this behavior---having the previous file selected in the dialog---isn't possible given the API that Java provides for native dialogs. (If anyone sees a way to do this that I don't, let me know.) All that setFile() seems to do is put the filename in the filename text field, without selecting anything--- an aggravating state of affairs, given that all of the file choosers that Sun considers native have that capability. I'm still pondering what exactly to do about the file chooser situation... Here's a recommendation for anyone who designs an API which permits access to a bunch of disparate underlying GUI widgets: Instead of restricting the API to the lowest common denominator, why not expose the sum of all of the underlying functionality, and make inapplicable functions no-ops or return false or something? -- J.
