2

When creating an MDI Swing GUI, I have a number of JInternalFrames that are added to a JDesktopPane in a JFrame. I make these internal frames invisible by adding setVisible(false) in the constructor, after the initComponents method (as the GUI builder automatically sets these frames visible in this method).

At runtime, the user can choose to open and close the JInternalFrames by invoking listeners that call setVisible(true) and setVisible(false), depending on the current state of the frames. I like how the previous position and state of an internal frame remains intact using this design. However, something tells me this must be terribly wrong, even though I haven't seen any drawbacks yet.

So, my question is: is this poor design?

  • 1
    If anything, I think it's better design to remember the JInternalFrames' positions. One drawback is that if the user resized the JDesktopPane, a JInternalFrame might be completely out of view (that is, beyond the visible bounds of the JDesktopPane), so you may want to check for that when making a JInternalFrame visible. Or, you could take the easy way out like Windows 3.1 did and provide "tile" and "cascade" menu functions. – VGR May 11 '13 at 22:44

1 Answers1

1

In the context of a Multiple Document Interface (MDI), this approach is quite reasonable. In addition, you can use the JInternalFrame method setSelected() to highlight a particular frame. To ease navigation, this and other methods can be used in Action, as shown here.

Community
  • 1
  • 1
trashgod
  • 203,806
  • 29
  • 246
  • 1,045