I’m new to DF (as mentioned before) and am surprised how fast you can adopt a running application to DF. To keep it short, I’m working on an Management Cockpit for financials.
I started to do a test-application (common based!!) for trying out the possibilities of DF, all from scratch. And I fell over some points, I got stuck. I read all the docs, looked at all the source and looked through the stuff here to get a hint. (Sorry, I’m a NewBe to DF AND to Java).
In the (common-) Doc of DF 1.07 (Paragraph 7.8 Menus) there is a menu example shown (Figure 6). How was that set up with the MenuPiece-Framework. I get the Menues running as separate RootMenuPiece but can’t fugure out, how to set the CThemeMenuPiece, CLookAndFeelMenuPiece and CLayoutChoiceMenuPiece into separate submenues of one RootMenuPiece.
What must I take care of to setup the whole DF-Content properly, so that e.g. externalizing a CDockable maximizes over the full screen, maximizing of CDockables from normalized stay in ContentArea and so on. Mine sometimes flip around?? So I’m doing something wrong!
Is there a way to have a CenterArea (prefereble CGridArea) and one CMinimizeArea in the south?
Use a SubmenuPiece, like in the example at the end of this post.
Currently “maximizing” always means first to “normalize” a Dockable, then search the next CGridArea which has the “maximize-area”-property set to true. I’d like to change that for 1.0.8p5 and allow “real” full-screen, but from the clients side its currently almost impossible to change the behavior. (I was planing to make real full-screen possible in the current version, but was distracted).
Or did I misunderstand your question?
CControl offers a method “createGridArea” and “createMinimizeArea” which create these two objects. Additionally these “create” methods register the new areas at the proper places. Just make sure not to call “getContentArea”, because this method does create a CContentArea (if not already present) and your application will have a really weird behavior if there is an invisible CContentArea floating around…
import javax.swing.JMenuBar;
import javax.swing.JMenuItem;
import bibliothek.gui.dock.common.CControl;
import bibliothek.gui.dock.common.menu.CLayoutChoiceMenuPiece;
import bibliothek.gui.dock.common.menu.CLookAndFeelMenuPiece;
import bibliothek.gui.dock.common.menu.CThemeMenuPiece;
import bibliothek.gui.dock.facile.menu.FreeMenuPiece;
import bibliothek.gui.dock.facile.menu.RootMenuPiece;
import bibliothek.gui.dock.facile.menu.SubmenuPiece;
public class Menu {
public static void main(String[] args) {
JFrame frame = new JFrame();
CControl control = new CControl(frame);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setBounds(20, 20, 500, 400);
JMenuBar bar = new JMenuBar();
frame.setJMenuBar(bar);
RootMenuPiece menu = new RootMenuPiece("Root", false );
FreeMenuPiece part1 = new FreeMenuPiece();
part1.add(new JMenuItem("free 1"));
part1.add(new JMenuItem("free 2"));
menu.add(part1);
SubmenuPiece part2 = new SubmenuPiece("Theme", false, new CThemeMenuPiece(control));
menu.add(part2);
SubmenuPiece part3 = new SubmenuPiece("Look And Feel", false, new CLookAndFeelMenuPiece(control));
menu.add(part3);
SubmenuPiece part4 = new SubmenuPiece("Layout", false, new CLayoutChoiceMenuPiece(control, false));
menu.add(part4);
bar.add(menu.getMenu());
frame.setVisible(true);
}
}```
to 1.
Oh, I’m such an idiot! That’s more or less basic java.swing! GoingRedInFace But thanks a lot, that is the perfect solution I was looking for. I’ll build my Menues on that.
to 2.
Well, I ment externalizing a CDockable. T’was late yesterday! When e.g. having 4 CDockables in a ContentArea, all normalized (like in the Common-Demo on your Help-Page) and externalize one Dockable, I would like to see that Dockable like a JDialog in maximum screen-width and height of the operating system (overlaying the Frame and ContentArea). The reason for that is to have a „super-zoom“ for business graphics. In my demo-test-app I can externalize a dockable but it won’t show up as a JDialog (e.g missing titlebar) and is difficult to handle size, as the maximize-button puts it back to the contentarea. Difficult to describe.
EDIT: ==> RTFM: The answer is in the documentation (8.1)!
to 3.
I’m in the office at present, but I think, that I leftover a line of code with the „getContentArea“. Sounds logical, what you wrote. I’ll give feedback this evening.
Btw, allthough DF saves me a lot of time of coding, I therefor spend a lot of time playing with the Dockables. A fascinating framework!!!
