I have a question.
I just started with Java and may have some small basic things. Now I wonder how a kind of pages (sections) in a program makes.
I do not mean some kind of tabbed panel, or if you click on a button that a text is visible.
I mean that for example all over the screen a separate part of the program looks. As the main menu of a game.
There is nothing else than the main menu visible at that time. If you for example a button from that menu click. The game is loading.
(I'm using the building of a standard game as an example)
If you for example the main menu click on another button (eg "Settings")
Then wort settings "page" is visible, and there is nothing else that the program is really doing.
I do not know how this type of navigation is called. But almost every program does have something.
How can I do this too? What should I do for example, as a new file, import the classes of a particular page, or something?
You seem to be searching for CardLayout. As shown here.
I think you should look for "state machines", which is a way for structuring your code, and implement your menu changing swing components (like JPanel, for example) in a JFrame. If I understand what you want, I think this can be an option.
There is no short answer, but based on your question, you need to read alot. I would suggest the swing tutorial It explains use of Panels, Frames, Layout managers and other containers.
You can also use the Matisse builder in netbeans (relevant plugin in eclipse)
Related
In Adobe After Effects there is something called a "pick whip". It allows you to click on a dot on one object and drag a line from that dot to another element, making a connection between the two. I would like to duplicate this feature in my Java program using swing. I honestly have no idea where to start.
If I've done a bad job explaining what I mean, please comment so I can improve it. If there is some way outside of Swing to do this, I'm willing to try it.
Here are some examples of what I am trying to achieve:
LinePanel illustrates how to animate the line as it is rendered, but you'll have to paint on the glass pane or among JLayeredPane instances to see the line above existing components.
When using a screenreader, like NVDA, I want to be able to hear the text of the menu when I hover my mouse over it. I am able to hear the text when I push the buttons in the menubar, but not when I hover over them (the screenreader does reads the menu's of other programs when only hovering over the buttons).
I have set the AccessibleContext like below:
JMenu.getAccessibleContext().setAccessibleName("text");
JMenu.getAccessibleContext().setAccessibleDescription("more text");
I can set listeners to the objects that detects when a mouse hovers over them, but I do not know if/how I can cast a text to the screenreader to read. I tried ToolTipText, but that text is not read by the screenreader either. RequestFocus on the JMenu works, but setting the focus to an object just by hovering over it with the mouse provides other problems.
Does anyone knows how I can let a screenreader reads the JMenu-text when hovering with the mouse over the menubar?
I am using Java6 EE and the Java AccesBridge (version 2.02) on a Windows machine (XP and w7).
Swing is the weaker of the GUI technologies relating to accessibility in Java, compared to SWT at any rate. There's a few things you can try.
First is to make sure any accessibility fields are set (which you've started on). I can't remember if Java has an AccessibleRole field, but you can try setting that to menu and menuitem for your menu items.
Another thing you can try is the AccessibleMenu JMenu.AccessibleJMenu component. This one's the product of further reading, so I can't verify it from experience. But it and its surrounding classes may suit your needs.
If those don't work, you could try the option of talking to people's screen readers directly. Quentin C has a good library to do this, Universal Speech. I'm new to this library myself, but it does have a Java implementation in there that should show you how to use it in a Java program. Normally I wouldn't recommend this approach unless making the UI accessible really isn't working.
The last option would be to use the SWT components instead of the Swing ones, even if just for your menu bar. I wasn't sure how keen you'd be on this one, but it is an option and should resolve it.
I hope one of these suggestions helps you solve your problem.
I am working on an application that uses Swing. I have successfully created a main GUI for the user to work from. However, I would like to allow the user to change his/her settings. How should I go about creating the settings window? Would using a new JFrame called 'Settings' be the best way to handle this, or is there something better to use than a second JFrame?
(Note: The settings JFrame, on exit, will not close the main GUI, it will use the DISPOSE method)
I would like to handle this in a way that consumes the least amount of memory, but maintaining a professionalized look to the application.
Have you considered a CardLayout? http://docs.oracle.com/javase/tutorial/uiswing/layout/card.html
Personally, I find the use of a separate dialogue to be a bit dated for configuration settings. I prefer tabbed layouts, which are card layouts decorated with a tab bar across the top.
You could easily wrap your application in a near-top-level card layout and add a menu action to switch to the configuration card, with the "acknowledgement" or "cancel" buttons switching back to the main application card.
In the end, it is really about what your users prefer, but remember a lot of them might prefer what they know, even if it is not a better solution. You have to find a balance, and if your implementation rocks, then eventually they will want your approach to the problem to be used in other applications.
A perfect example of this is tabbed browsing, as opposed to multiple windows. Personally, I can't imagine going back to multiple-window browsing now that I have become accustomed to browsing tabs, but at one point in time, multiple windows was the only game in town.
In the end, if you find out you made the wrong choice, keep you code clean enough to easily implement with either solution. As long as your configuration screen is just a plain JPanel (or wrapped in just a JPanel), it shouldn't be very hard to do.
here is a class that does just this kind of thing:
http://tus.svn.sourceforge.net/viewvc/tus/tjacobs/ui/dialogs/ParamDialog.java?view=log
you have to look at the ApplicationListener interface, especially at the 'handlePreferences' method of that interface.
I am currently writing an application where the user has, at some point, to click a button which have been generated at run time. I know how to do it when writing all my swing code from scratch, but I'd like to take advantage of Netbeans' visual editor.
The generated UI code goes into an initComponents() method I can't modify since it is regenerated automatically from the visual form.
I'd like to have a panel I place at design time using the visual editor in which I could add the buttons at run time so that they fit nicely in the layout, but I don't know how to access the panel in a convenient way. Besides, there may be another method than using a panel.
So basically :
How do I locate a Swing component at run time ?
Is there a better way of integrating components created at run time in a generated Swing UI ?
Thanks for your help.
NetBeans-generated GUI classes store all the components in private variables. You can add a method into the generated class that returns the panel, and it will remain even as you do additional design.
If you're going to use a generated UI, then it's probably best to use a JPanel within that UI to "carve out" space for your own components. Otherwise, you'll have to worry about how your components affect the layout of the components placed by the UI.
Just because you are using NetBeans generated GUI classes doesn't mean that you have to use the Group layout for the panels. I find that switching it to a BorderLayout helps especially in cases where I want to add some dynamic user interface code.
It is possible to change private to protected/public by either right clicking on a component in the GUI-Designer, choosing properties and hitting the Source-tab or right clicking on a component and choosing "Modify Source" (or something like that) and setting the appropriate access modifier.
Or just export them via a getXYZComponent() method.
Locating the component should provide as being too difficult, as you built it with the designer and thus know each component.
For example, if you had a JTabbedPane and wanted to add tabs to it when the user hits a button or something like that, you would simply issue myJTabbedPane.add(myCustomComponent); et voila, a new tab appears.
It is also possible to modify the auto-generated code and/or the code used for auto-generation by using the "Modify source" dialog mentioned above, which can be really useful.
I try to build a gui (Swing) for a simple java application. The application should have a start window like a menu. From there I would like to navigate to several other windows.
My question is what is the best-practice to achieve such a navigation? Should I build several JFrames and switch the visibility of them on/off when navigating OR should I better have one JFrame and add/remove JPanels in this single frame to navigate between the windows?
Thanks.
I recommend
Do not do a MDI application with sub-frames like those found in the old Windows days. They suck as they make the matter confusing.
Do design a tabbed interface. The welcome page/menu will be displayed on a first tab that is always created on the start.
All cool kids do that nowadays:
Visual Studio
Eclipse
Firefox
If each of your windows correspond to different task (possibly nested), you could present your application as a SDI, with on the left a task panel like:
Each of the task would display one JFrame with the associated window.
Other solution: a table of content like this picture on the left side
(note: it actually also displays a task panel in this example on the bottom right)
Multiple JFrames sounds like a better idea to me. Much more OO.
You must find a balance between these goals:
Not too many things in one "window"
The user must quickly be able to find the correct window to do the next step of work
All relevant information must be visible at any time
Eclipse solves this by creating many small editors where each editor shows some specific information and allows to modify it. Editors are then arranged within one OS window in tabs and "views". A view is always completely visible and they can be arranged. Think of a view as a way to cut an existing editor in half (horizontal or vertical) and then being able to replace one of the halves with another editor. Between each half, you have a splitter so you can adjust the sizes.
Arrangements of views are then saved in "perspectives".
This allows every user to create a perspective which contains all the necessary editors at the same time, arrange them as they need it and work effectively.