0

I am persisting a JFrame size / state information.

I can get the height, width and extended state number; however, this information is simply not enough. For example, if a window is maximized, the height and width returned are not what it would be after returning to a normal size.

Is there a helpful way of persisting and restoring this state data, or do I simply have to switch the window to JFrame.NORMAL before reading state? Is this even sufficient for all the possible fringe cases?

Obviously, in normal, we restore to normal with the size.

When maximize_both, we want to restore the normal size then maximize_both.

When maximize_horiz or maximize_vert, I am guessing we want to restore the normal size then maximize_horiz or maximize_vert respectively. I'm not sure. Will this address the vertical and horizontal sizes appropriately? Probably.

When iconified, we want to restore the normal size then iconify -- or maybe not iconify... Not sure.

To clarify, the issue is less about the persistence mechanism and more about what to persist and how to get it from the JFrame.

Jonathan Seng
  • 1,219
  • 7
  • 20
  • 1
    See also this [answer](http://stackoverflow.com/a/11114200/230513) mentioning `java.util.Preferences` or `javax.jnlp.BasicService`. – trashgod Mar 09 '13 at 01:53

1 Answers1

2

Rather then persisting just the width and height of the frame, try also to persist the preferred size information as well.

This way, if the extended state isn't equal to MAXIMIZED_BOTH (or a variation of the two), you can set the size to the preferred size.

Of course, you could simply call pack ...

MadProgrammer
  • 343,457
  • 22
  • 230
  • 366
  • See also [this answer](http://stackoverflow.com/a/7778332/418556) with tweak.. *"If the frame is maximized at time of close, it is restored before getting the bounds"* – Andrew Thompson Mar 09 '13 at 03:14
  • @AndrewThompson That link seems well received and was what I guessed above. It had a comment about a needed wait (probably for the event loop) which is good to know. – Jonathan Seng Mar 09 '13 at 04:06
  • @JonathanSeng Did you try the example in the linked answer? It never touches (or queries) preferred size but uses the last (non-maximized) size & location as determined by the user. Leave `pack()` and the preferred size out of it completely, since they have nothing to do with ***user*** preferences (and can be entirely handled by the toolkit at run-time). – Andrew Thompson Mar 09 '13 at 04:14
  • @AndrewThompson Not yet. Its similar to what I was thinking, but I'm updating the question to see what more comes out. Also, that answer doesn't thoroughly address all the details in explanation, though as I started exploring out the details in the question, it may have the right result. And I agree with you about preferred size not being relevant. – Jonathan Seng Mar 09 '13 at 04:19
  • pack() will not recreate user-adjusted settings. Setting preferred size when the app relies on widgets to create their own will blow the user experience. I am down voting this answer because I don't think it addresses the question. Though it made a good place holder for @AndrewThompson to get a good link in. – Jonathan Seng Mar 09 '13 at 04:25