[Swing] How do I: Multiple JFrames approach to utilize multiple content editors?

Newbie & Debugging Questions
#1

I’m looking at this Stack Overflow question and answer here:

My main goal is to use multiple JFrames for the end users to easily use my level editor to create contents. I know that there exists a common flow saying that multiple JFrames is a bad practice, but I feel as if that’s not entirely the case.

Exhibit A: Warcraft III World Editor (Main Editor + Triggers Editor)

Main Editor:

Triggers Editor:

From these two screenshots (both of which are crappy, by the way…), you can see that they consist of two different windows, which can be run side-by-side. Each window expresses functionality in two different aspects of a custom map, one of which focuses on the terrain and units, while the other is focused on triggers and scripts.

This is something I wanted to do with my level editor, one maintains the tilesets, while the other focuses on the triggers/events/scripting aspects of my game.

I wanted to know how to approach the multiple JFrames system, and what best practices go with this. There are some suggestions such as offering a static method [icode]open()[/icode] that opens up a new JFrame along with the reference to the parent JFrame, or call it when a button is activated (similar veins to Exhibit A’s approach).

Can anyone provide other alternative suggestions? This is so I can consider multiple perspectives as well as different approaches to implement this system. That’ll be appreciated.

#2

Maybe I misunderstood, but I think you want to have 1 JFrame, and multiple JPanels.

If you add a JSplitPane (I think it’s called) to the main window, you can split the window in half - you can then add separate components to each split. You can even add another JSplitPane to one of them to split it in half again, for a total of 3 separations, and so on.

http://docs.oracle.com/javase/7/docs/api/javax/swing/JSplitPane.html

#3

That would make my editor more of 1 window encompassing all functionalities. I would want it to be 1 JFrame parent encompassing multiple independent JFrames for each different functionalities.

In World Editor, there’s this main parent window called the Terrain Editor. When you clicked on the top-most button, where the letter “a” is at, a child window called the Trigger Editor pops out. Closing the Trigger Editor does not close the Terrain Editor. Closing the Terrain Editor, however, closes both the Trigger Editor and the Terrain Editor itself.

When both of the editors are opened, they can be moved around, meaning that they are independent of each other in terms of window components. If 1 JFrame were to have multiple JPanels, it would mean that there’s just 1 window that can be moved around, and not 2 or more windows moving around independently. Hence the multiple JFrames approach. Or maybe it should be multiple JWindows approach?

Don’t worry about it, the more I try to describe it, the more I get confused about it. I’ll continue to search for “multiple JFrames” or “multiple JWindows” on Stack Overflow, to see what answers might be available.

#4

This post is justified (in my opinion) enough to be separated from my post above.

The solution to this problem is:

  1. In the parent JFrame, use [icode]setDefaultCloseOperation(JFrame.DISPOSE_ON_EXIT);[/icode].
  2. In the child JFrame(s), make sure they call [icode]addWindowListener();[/icode]. In the parameters, pass in a [icode]WindowAdapter[/icode] class that overrides [icode]windowClosing(WindowEvent event);[/icode]. In that method, just call on [icode]this.dispose();[/icode] for the child JFrame(s).

That way, the parent JFrame will close every single child JFrames, but the child JFrame(s) will not close the parent JFrame.

#5

ohhhhhhhhhhhh right yeah sorry man, completely missed the point there. Tom hit the nail on the head.

Just make sure to hold a pointer to the new JFrames.

#6

Wouldn’t that make the new JFrames not garbage collectable? From my current testing results, I never had any members holding references to the new child JFrames.

Unless, you mean that these multiple JFrames should be in a [icode]parent <–> parent[/icode] relationship? Interchangeable JFrames seems very close to what Blizzard had done with their World Editors. Hm…

#7

I meant to hold reference whilst they’re still alive. Maybe I suggested something far too obvious:P assuming you set the reference to null, it’ll get garbage collected.

#8

I don’t know. I haven’t thought too far ahead about this.

Currently, I just had “parent closes all, child closes itself” paradigm made, so I’m going to work on this and see.

#9

I totally didn’t realise that you were the same guy who asked the question originally. Probably doesn’t matter, but it would explain why i referenced you as ‘tom’ instead of ‘you’ aha:P

Yeah you’re doing that right (Or that’s how I’d do it anyway), what i was saying is you should probably hold a reference like
JFrame triggerEditor;
within the main frame class that you extended.

then in the window listener set triggerEditor to null when the window is closed.:slight_smile: You were probably gonna do this anyway - I don’t really know why I mentioned it, it shouldn’t have caused this much confusion:D

#10

Why don’t you go and make a JFrame (The ‘Main’-JFrame), and use JDialog’s as additional windows?

So you have:

  • JFrame/TerrainEditor: The editor that you use to edit your scene.
  • JDialog/TriggerEditor: The editor for the currently selected trigger in the scene.
  • JDialog/(Texture/Script/Entity/Model/Prop/Sound/Resource/???)Editor: ???.

Make the main JFrame the ‘parent’ of all of your JDialog’s. That should close them when you close the main JFrame (Unsure if this is correct). When you want to make a dialog go away, just use setVisible(false) to make the JDialog’s invisible when you don’t need them, and use dispose() on the main JFrame to close the entire application.

If the thing with making all the JDialog’s children of the main JFrame doesn’t work, just put them all in a synchronized list, and add/remove them as you open/close them.

#11

This is the reason why I don’t want to use JDialogs over JFrames.

JDialogs can block UI event dispatch threads, which the World Editor in Exhibit A doesn’t do. If using JFrames, users can simply switch to any editors can continue to work simultaneously. Also, because JDialogs do not have minimize/maximize buttons, they aren’t really intuitive to clients.