Ok, like with everything I find it easier to learn when jumping into the deep end (Java, PHP, Air Traffic Controlling) I just try not to kill anybody in the process; however, I cannot find any information of how to specifically position a slider (JSlider)... I want to add it to my JPanel and at the stage I am at, setBounds would be the most logical but it doesn't like it!
I have set up the slider as follows
sensitivitySlider = new JSlider (sensitivitySlider.HORIZONTAL, 1, 1000, 500);
and initiated the variable at the beginning of the program, no problems compiling and too much of a brief (easy to most) question to find a definitive answer from googling.
Sorry if this is a little bit dumb
Essentially the problem was that I was not placing it on a panel, I was trying to position it directly on the main frame however I was calling for it to be placed on the mainPanel which didnt exist. Sorry for wasting server space without properly checking for the errors myself...
Related
I haven't been able to find a solution to this problem so far through research and may in fact be a problem with JFrame as a whole.
Like any desktop application, most times the clicking of a button or "object" presents an action of changing what is currently being displayed. So for example, if I currently have an "input form" on the display frame and then the user clicks a button labeled "submit," the screen changes to a congratulations screen saying "your form has correctly been submitted," where all previous elements of the form are no longer showing.
Now in most cases, we set up a JFrame like so:
frame.getContentPane().add(panel);
frame.pack();
frame.setVisible(true);
Where panel is a JPanel that contains all the primary display objects and layouts at the current time.
Alright this is great, but if we want to change the content pane to introduce a new screen we would do something of the following:
frame.getContentPane().removeAll();
frame.getContentPane().add(newPanel);
frame.pack();
Where newPanel contains different objects and layouts when compared to the original panel.
But a design problem occurs here. The refresh rate becomes clunky and choppy. Take a look at this gif below at my current program:
You can clearly see the choppy refresh rate between the transition of the original panel and to the newPanel.
I got to thinking, maybe it was because I didn't disable the viewing of the frame before packing it. So I then tried:
frame.setVisible(false);
frame.getContentPane().removeAll();
frame.getContentPane().add(newPanel);
frame.pack();
frame.setVisible(true);
This, however, just yielded the same result as what is presented in the gif. I then began googling and found many StackOverflow answers saying to either revalidate() or repaint() the frame before packing. So I tried adding this first in the code right above:
frame.revalidate();
This didn't work either, whether placed before or after the pack() method, yielding the same result. So I tried removing that and tried this in the above code:
frame.repaint();
That didn't work either, whether placed before or after the pack() method, again yielding the same result. So I tried both of them together (before and after just like before) and yet again nothing changed.
I then saw some people recommending this line of code:
frame.update(frame.getGraphics());
But, again the same result is still presented. I began wondering if it was a problem with JFrame and its own internals. So I did an experiment with sleeping the current thread right after calling pack() but before turning the visibility of the frame to true.
This yielded the same outcome. No matter how long I waited, re-displaying the frame to the screen created the same clunky and messy redraw between components as what is presented in the gif. Now this is leading me to two possible conclusions, either the pack() method is more of a hack than a clean solution or the drawing of the frame to the screen is just buggy in nature with Java.
I have tried every method placement I can find. I have experimented many times over again with reorganizing the method calls and I have tried introducing other method calls in hopes of solving this problem.
Has anyone experienced this same result, as every application I have written is subject to this annoyed and ugly design bug. And I just cannot seem to get rid of it.
Is there a solution or do I have to reinvent the wheel with awt.Panel?
-Versions-
Java:
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
(This problem has occurred in previous versions of Java for me too)
MacOS:
OS X Yosemite
Version 10.10.3
MacBook Pro (Retina, 13 inch, Late 2013)
Here is my output:
As you can see, I still suffer the same problem as before. In the code I do use GridBagLayout but that is not the problem. In the past I have used layouts from BoxLayout to FlowLayout and I still got the same clunky, messy "refresh" result.
I just tested commenting out portions of the refresh code in my example program like how I did above and again the same result is given. I just provided everything uncommented because no matter what I do with that code, my result is unchanged.
In addition, I can understand downloading a file for some is a problem (e.g. lack of trust in the user) so here is the text:
http://freetexthost.com/rjldye21ix
On a final note, I can post edits with more gifs if any new solutions appear.
I have a project due in about an hour and I need to figure out the problem in my code before submitting.
In essence, there are two classes: one is a game and the other is a gui that should contain that game, some useless buttons, and a picture.
I'm having trouble making it all fit. I think I have a problem with the JPanels. (There might be some useless looking methods, but I had plans for them and I'll see if I have enough time for them to come into fruition)
This is life and death for my grade. I'd be eternally grateful if you could fix this code for me.
I'm positive the problem is not in the nitty gritty of the second link. It's been tested on its own and works.
Here's the code
http://pastebay.net/1236108
http://pastebay.net/1236109
Here's what I get when I run the code:
Get rid of the window in the Hangman constructor. Hangman is already frame.
Use pack instead of setSize
Git rid of game1 and game2 panels, they are adding nothing and causing you all the problems.
You will also find that if you override the getPreferredSize methods of DrawingDemoPanel and SubKillerPanel and return an appropriate size, that they will layout better.
Alternativly, you could create a single game panel and use a GridLayout to add the DrawingDemoPanel and SubKillerPanel to it, then add this to the CENTER position of the main window it will allow out better...
Right now, I have a full screen application which spawns several full screen JFrames based on a configuration file (so I can never predict exactly how many frames I will have). These JFrames are in full-screen mode, like this:
setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);
setUndecorated(true);
Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
setBounds(0,0,screenSize.width, screenSize.height);
The problem is, these JFrames are misbehaving in a Linux environment. I struggled a whole lot with requestFocus, requestFocusInWindow, toFront, setVisible, etc. But nothing seems to get it to work properly in Linux. The issue lies in the fact that I have several frames and I need to be able to switch between them when I click on a button (it's basically a menu).
So I'm starting to think a JFrame isn't the best object to use. Would it be easier to manager multiple frames if they were, say optionPanes? Or something similar? Whatever the solution, I need to be able to DO_NOTHING_ON_CLOSE and setUndecorated (or something similar).
Note: If you don't see a reason I need to change my JFrame and would know how I can switch focus/view easily, please let me know. This would also be an answer to my problem.
i dont see your call to set the screen to fullscreen ?
http://download.oracle.com/javase/tutorial/extra/fullscreen/exclusivemode.html
I have decided to use the cardLayout and changing my code around a little bit.
i'm new to Java programming, but I've done C++ for a while now. the whole GUI thing is new to me. i created two JPanels and added them to JFrame using FlowLayout. When I run the program, i get http://imageshack.us/photo/my-images/43/36213853.jpg/ as opposed to http://imageshack.us/photo/my-images/88/86682510.jpg/ only SOME of the times. the other times, the content appears just fine
for some reason, when i resize the window when the window is blank, the contents appear fine.
i'm not sure what the problem is that gives me this inconsistency!
any help would be appreciated. thanks!
It's hard to answer without code, but by chance are you calling setVisible(true) before packing your GUI and before adding components to the GUI? Do the components show up if you resize your GUI?
If so, you'll want to make this call only after your GUI has been fully populated with components, and usually after it has been packed (so that your layout managers can lay out all components and size the GUI correctly).
If this advice doesn't help, then you'll likely need to post some of the offending code. How much to post -- it's hard to say -- enough so that we can identify the problem ;) but not to much as to be drowned in code not related to your problem. The best code to post is an SSCCE if you have the ability to create one.
I've created a small gui app in Netbeans. As I was adding in some buttons and text areas the mainPanel resized itself. Now it is really wide [probably 4x as wide as I want] but when I try to drag the edge in it won't resize back down. If I drag it out, making it bigger, it takes that change. I would just like to return the mainPanel back to a reasonable size. Not sure what I'm doing wrong here. I've tried to change the min size, max size, and preferred size settings for the mainPanel with no success. I've even tried to change the menuBar & statusPanel settings at the same time as the mainPanel [thinking that one of them was making the others too big] without success.
Any ideas?
Netbeans does do really stupid things like that sometimes, and I generally get around them using either of these two methods:
First thing to try is to change the layout used. Try the Grid Bag Layout, or any of the others and see if you get better results.
If that doesn't work, then probably the easiest thing to do is to change stuff in the code. You will notice that Netbeans automatically adds a call to initComponents(); in the constructor (you have to switch to Code view from Design view). And if you look at initComponents, it will have a whole heap of auto-generated code to create the GUI. Do NOT edit this, because it's just a matter of time before Netbeans overwrites your changes. What I do is to create a new method initComponentsFix, and call that immeidtaely after initComponents in the constructor. In initComponentsFix, I would add the code to resize the component to the preferred size, and any other things you you want to fix.
BTW I empathise with you - Netbeans' GUI editor is still in need of much work. However, it's code auto-generation is still very useful, so I wouldn't recommend coding the GUI the good ol' fashioned way. That's why I'm advocating using it up until you start felling its limitations, after which you "take control".
There is also a third way, which I would not recommend, is to edit the file that Netbeans stores the Design view in, which is basically shares the same file name as your frame's class' source code, except with a .form extension.
This file is XML, and is pretty easy to edit. I don't recommend this because it is sorta going around the back door, but as a last resort, you can still try it.