Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (492)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (556)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  AWT stuff is not reliable  (Read 8340 times)
0 Members and 1 Guest are viewing this topic.
Offline broumbroum

Junior Member





« Reply #30 - Posted 2008-02-29 22:50:34 »

hard to find but, you may verify WHERE are your components... eventually call validate() at end of the ignition stuff. anyway there above I find that you make conditions about the source of the dispatched event. Hereby this is roughly NOT imaginable to compare the source with a variable since Swing has implemented the ActionListener stack for every JComponent. But I can find that equality is finally INEQUALITY with "==" :
1  
2  
3  
e.getSource()==b_quiz // what is b_quiz ? you should change this condition with some of a more accurate one
if(b_quiz instanceof Component)
     boolean isB_quiz = b_quiz.equals(e.getSource());

Moreover this is quite non-sense in regards to the general stability of Swing above AWT, where AWT should rather stay in the background for such UI events. (I wouldn't say that with the KeyListener that is not as accurate, timing speaking)  Shocked

::::... :..... :::::: ;;;:::™ b23:production 2006 GNU/GPL @ http://b23prodtm.webhop.info
on sf.net: /projects/sf3jswing
Java (1.6u10 plz) Web Start pool
dev' VODcast[/ur
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #31 - Posted 2008-03-01 01:20:32 »

...
Now i know some of the experts here knew this and yet didnt tell me.  Angry

Yeah man, if I were you I'd ask for a refund.  Roll Eyes

I mean seriously, a forum is not a helpdesk.

Offline Noya

Senior Newbie





« Reply #32 - Posted 2008-03-01 03:32:00 »

Sometimes reading this forum is much more fun than the daily wtf. Great Smiley
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Mr_Light

Senior Member




shiny.


« Reply #33 - Posted 2008-03-01 18:27:52 »

As u probably noticed, this is not a complete project. I prefer "coding it out" before dealing with OOP logistics.
It's not just OO if this was FO you couldn't get away with half of that stuff. I'm also wondering where you think your getting speed up from doing it like this, it takes longer to sort out the code then to rewrite it.
Maybe there is a limit on how many components you can have and maybe i have too many...  Undecided 
Thust me even if all your lines of code where about creating components you still wouldn't be there. if you would increase yours a 1000 fold you'd still be ok.
If someone would just tell me that AWT stuff is very buggy, i will use my own components cause i wont have no other choice...
The reason no one is telling you that is because it just isn't true.
If its not too hard, could someone modify the source code so that it works?
I'd be crazy enough to do it. but see above.
Its not a problem its a java bug. Ive seen a share of them (like the same program starting out in different states, etc.) Usually im able to work around those bugs, but not this one.
I occasionally teach at university and other higher education, al these so called 'bugs' freshmen complain about I've been able to debunk. This doesn't mean its bug free and yet the api has some sharp edges, but I'll believe that when I see it.
I have a question then (i asked it before): How could a component not be visible when its state is set on visible? If there are some ambiguous functions (like setEnabledVisibility() or setVisibleWhenSettingVisible() or showComponentOnTheScreen()) that control visibility, its an API flaw, not mine.
Visible is one of a number of requirements that have to be met for a person to actually see it on the screen. So if isVisble is true you need to look at the other ones.
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
import java.awt.Component;

public class Test {

   /**
    * @param args
    */

   public static void main(String[] args) {
      Component component = new Component() {};
      System.out.println(component.isVisible());
   }

}

This prints true here and I assure you nothing is being drawn. setVisible is there for performance reasons and wasn't intended as a diagnostic mechanism. As for those methods that you mention I can't find them, what class are they suppose to belong to?

(like the same program starting out in different states, etc.)
say what?

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline alexxz4

Junior Member


Projects: 1



« Reply #34 - Posted 2008-03-01 18:44:20 »

Quote
This prints true here and I assure you nothing is being drawn. setVisible is there for performance reasons and wasn't intended as a diagnostic mechanism. As for those methods that you mention I can't find them, what class are they suppose to belong to?
What i meant was that how could 10 components be drawn and 5 components not be drawn if all the code related to those 15 components is in the same functions, and those functions perform the same thing. If nothing was drawn, i'd know i made a mistake somewhere.
Quote
Quote
If its not too hard, could someone modify the source code so that it works?
I'd be crazy enough to do it. but see above.
Someone must have known that setLocation() and setSize() must go together.
Quote
It's not just OO if this was FO you couldn't get away with half of that stuff. I'm also wondering where you think your getting speed up from doing it like this, it takes longer to sort out the code then to rewrite it.
Considering performance issues, i dont think OOP (i.e. 1000 classes) will improve it drastically. Plus, i think that a program that runs is better than a program that has a good style but is very buggy. Like i said, when im done im gonna stuff that code into classes, put obnoxious and pointless comments all over the program, and the OOP geezers will be happy... 
Quote
(like the same program starting out in different states, etc.)
say what?
In one game i often have the character falling from the sky when the game loads. More often he is standing on the ground when the game starts.  Roll Eyes

[ Motherload Unlimited looking for programmers ] [ Solitaire ]
Offline Mr_Light

Senior Member




shiny.


« Reply #35 - Posted 2008-03-01 19:29:55 »

What i meant was that how could 10 components be drawn and 5 components not be drawn if all the code related to those 15 components is in the same functions, and those functions perform the same thing. If nothing was drawn, i'd know i made a mistake somewhere.

Your assertion that your code is the same for all components is it based on anything else then air?
Someone must have known that setLocation() and setSize() must go together.
Your assumption is wrong, there are default values for size, where size might be 0,0 making it impossible to spot. your making up stuff here.
Considering performance issues, i dont think OOP (i.e. 1000 classes) will improve it drastically.
Short lived objects might be more efficient in certain cases, the amount of classes that OOP introduce are largely insignificant performance wise.
Plus, i think that a program that runs is better than a program that has a good style but is very buggy.
I wouldn't know, I do know that something that is well ordered is much easier to modify and read.
Like i said, when im done im gonna stuff that code into classes, put obnoxious and pointless comments all over the program, and the OOP geezers will be happy...
A contract or obnoxious comments as you call them avoids all the issues your having for the rest of us.

But even so as I said half of that stuff has absolutly NOTHING to do with OOP. keeping your scopes as short as possible and clear names for variables apply probably to all approaches


It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline alexxz4

Junior Member


Projects: 1



« Reply #36 - Posted 2008-03-01 19:55:01 »

Quote
Your assumption is wrong, there are default values for size, where size might be 0,0 making it impossible to spot. your making up stuff here.
Well, then, if u just add a component, would you be able to see it if it has the default size (i.e. 0,0)? If u have 2 default sizes they are not default anymore are they? Gottcha....
Quote
I wouldn't know, I do know that something that is well ordered is much easier to modify and read.
Im not writing an essay am i? I find it faster to program if i dont adhere to some conventions.
Quote
Short lived objects might be more efficient in certain cases, the amount of classes that OOP introduce are largely insignificant performance wise.
Ummm... i dont think that means "short lived objects improve performance considerably", which was my point...
Quote
A contract or obnoxious comments as you call them avoids all the issues your having for the rest of us.
Plus it bloats up the code considerably. I hate it when i only see one statement on the page with a bunch of spaces and comments.

[ Motherload Unlimited looking for programmers ] [ Solitaire ]
Offline BoBear2681

JGO Coder


Medals: 18



« Reply #37 - Posted 2008-03-02 00:25:06 »

Well, then, if u just add a component, would you be able to see it if it has the default size (i.e. 0,0)?
No, you wouldn't.  That's why you should use layout managers, as was suggested many times before in this thread.  Why do you not like them?  They'll provide you with the following:

1. All components are automagically properly sized and positioned.
2. Automatically handle resizing/repositioning of objects when their properties, such as text, font, etc. change.
3. if you have a resizable window, they'll handle automatically resizing all components to maximize window space usage when the window is resized.
4. They'll handle different dpi, as was stated previously.
5. AWT/Swing layout managers are locale-aware (i.e. they automatically handle RTL interfaces).

Again, what's not to like about layout managers?  Notice everything they do for you is automatic!

If you insist on using null layout as you are, then yes, it makes perfect sense that the programmer is required to set both the size and location of all components.  How else would the AWT know where/how big to display the components?  If you use a layout manager, it'll do this work for you.  If you don't use one, you will have to handle this yourself.  Components don't get automagically sized properly when you add them to a window.  Someone, either you or a layout manager, has to decide what the proper size is for a component, for a given location, font, etc.

Quote
If u have 2 default sizes they are not default anymore are they? Gottcha....

I'm not sure what you mean by this.

Quote
Im not writing an essay am i? I find it faster to program if i dont adhere to some conventions.

If you're going to be the only one to ever look at/modify your code, then this mindset is fine.  But don't say this at a job interview!  And also don't expect to post such code on a forum and expect others to be able to read it and help you with your problems.

Quote
Ummm... i dont think that means "short lived objects improve performance considerably", which was my point...

The idea here is that often, making many short-lived objects is not the bottleneck you think it is.  Memory allocation in Java is fast, it's not like you're doing a C malloc().  If you're having performance problems, you should always profile your code to find out where your real problem lies.  Don't make assumptions such as "Oh, I make many small objects here, this must be it."  Have actual numbers to back your assumption up.  Otherwise you'll be wasting your time, "optimizing" something that wasn't the problem to begin with.

Quote
Plus it bloats up the code considerably.

You consider good OOP design, with several concise, readable classes, each doing a different task, more "bloated" than a 3000+ line mega-class?

Quote
I hate it when i only see one statement on the page with a bunch of spaces and comments.

I would be too.  What's an example of a project that does this?

Anyway, before you start criticizing the AWT, saying things like "it's buggy," think about this:  Developers around the world have been using AWT (and Swing) successfully for YEARS.  Many have written programs much more complex than yours.  They didn't have the problems you're having.  Don't you think this means that the problems you're having aren't with the AWT, but instead with your code (or your understanding of the API?).

Saying things like "Here's my code, it shows AWT is buggy, what should I do?  No, I don't have time to read any documentation or tutorials on the subject, but I just know my code is right.  Why is AWT so buggy?" is very aggressive and is not a good way to get help on a forum. 
Offline SimonH
« Reply #38 - Posted 2008-03-02 01:13:28 »

what's not to like about layout managers?

It was a long time ago so I can't give actual code, but I had to do a huge swing GUI for a transport firm and I had nothing but trouble from LayoutManagers... The worst case I remember was where there were four buttons in a row, you'd localise the button text and the last button would go onto a new line and screw the position of everything else! Nightmare! In the end I had to write my own positional code using setBounds(), setFont() &c to keep things where they should be. Lots of time wasted.

I understand the sense of LayoutManagers and for don't-care-about-looks applications they work, but generally I'd go for a custom solution.

People make games and games make people
Offline BoBear2681

JGO Coder


Medals: 18



« Reply #39 - Posted 2008-03-02 01:39:42 »

The worst case I remember was where there were four buttons in a row, you'd localise the button text and the last button would go onto a new line and screw the position of everything else! Nightmare! In the end I had to write my own positional code using setBounds(), setFont() &c to keep things where they should be. Lots of time wasted.

You just weren't using the right layout manager.  You can handle a row of equally-sized buttons by adding them to a JPanel using GridLayout, then adding that GridLayout panel to another panel that centers it.  I do it all the time (OK/Cancel/Apply type scenarios).

Quote
I understand the sense of LayoutManagers and for don't-care-about-looks applications they work, but generally I'd go for a custom solution.

Layout managers don't inherently make programs look bad.  It's their misuse that does this.  LayoutManagers, especially in Swing, aren't simple.  You simply can't just pick them up and start using them.  It takes some experience using them to understand how they work, their parameters, which one is appropriate for different situations, etc.  But once you get the hang of them, using them is no problem whatsoever.

I actually think the opposite way you do.  I think using null layout may be fine for small, toy code, but the end result is so inflexible and difficult to maintain when compared to using a LayoutManager, it just isn't worth it for any decently-sized GUI.

Using null layout is equivalent to creating your own, hard-coded, inflexible LayoutManager implementation.  Why would you reimplement something that already exists for you, that has more features and is more flexible than your own implementation?

By the way, I don't mean to sound so aggressive in these posts (my first two at that!).  That's not my intent.  I guess I'm just a little too opinionated on the matter.  Smiley
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Mr_Light

Senior Member




shiny.


« Reply #40 - Posted 2008-03-02 01:49:45 »

GroupLayout made life easier.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline SimonH
« Reply #41 - Posted 2008-03-02 03:50:42 »

I'm just a little too opinionated on the matter. 

I'll see you in the carpark, mister! Wink

OK, compromise! - In this particular case layout manager's probably the best way to go...

People make games and games make people
Offline alexxz4

Junior Member


Projects: 1



« Reply #42 - Posted 2008-03-02 18:30:54 »

Quote
Quote from: alexxz4 on March 01, 2008, 11:55:01 am
Well, then, if u just add a component, would you be able to see it if it has the default size (i.e. 0,0)?

No, you wouldn't.  That's why you should use layout managers, as was suggested many times before in this thread.  Why do you not like them?
Ummm.... yes you would. Try adding a button to an applet, you'll see it in the upper-central location. Its size is not 0,0 i can tell you.
So in affect this code:
1  
setLayout(null); button.setLocation(20,20);

all by itself has the same affect as
1  
button.setSize(0,0);

And layout managers position stuff how-ever they like to. You cant tell position of a component when a layout manager is done with it.
Quote
If you insist on using null layout as you are, then yes, it makes perfect sense that the programmer is required to set both the size and location of all components.  How else would the AWT know where/how big to display the components?
It doesnt make sense to me why a programmer must set the size of a checkbox when he doesnt have to.
Quote
Quote
If u have 2 default sizes they are not default anymore are they? Gottcha....
I'm not sure what you mean by this.
Well, the first default size is the smallest size to fit the contents of the component. You get it when you do this:
1  
2  
3  
4  
void init(){
Button button=new Button("Button");
add(button);
}

The "second" default size is (0,0), you get it when u do this:
1  
2  
3  
4  
5  
void init(){
Button button=new Button("Button");
setLayout(null);
add(button);button.setLocation(20,20);
}

Quote
If you're going to be the only one to ever look at/modify your code, then this mindset is fine.  But don't say this at a job interview!
Like i said, im gonna modify it after i finish. First i gotta make sure it works without making my head explode with countless classes.
Quote
You consider good OOP design, with several concise, readable classes, each doing a different task, more "bloated" than a 3000+ line mega-class?
Common, everyone knows that OOP takes more statements to implement than FO. A formal OOP implementation requires the use of declaration, setters and getters, while OF only needs a declaration. OOP doesnt reduce line count by any stretch of imagination.
Quote
They didn't have the problems you're having.  Don't you think this means that the problems you're having aren't with the AWT, but instead with your code (or your understanding of the API?).
Shocked Yeah right, they never had to press Backspace or Delete or refer to a manual or debug or ask for help. Common! No actually, my problems are with AWT cause my code uses them. The AWT may not be buggy, but its a little under-developed, which is what i have a problem with. 
 

[ Motherload Unlimited looking for programmers ] [ Solitaire ]
Offline tom
« Reply #43 - Posted 2008-03-02 18:47:56 »

Ummm.... yes you would. Try adding a button to an applet, you'll see it in the upper-central location. Its size is not 0,0 i can tell you.

The applets default LayoutManager is the FlowLayout. The LayoutManger will use the components minimum/preferred/maximum size to set the location and size of the component. When you use null layout you must do this yourself. Makes sense, don't you think?

Offline BoBear2681

JGO Coder


Medals: 18



« Reply #44 - Posted 2008-03-02 19:40:46 »

Ummm.... yes you would. Try adding a button to an applet, you'll see it in the upper-central location. Its size is not 0,0 i can tell you.

Correct.  As was stated earlier, that's because AWT Containers by default have a LayoutManager installed (FlowLayout as someone else pointed out, I believe).  If you read some documentation or tutorials on AWT/Swing, you would have known this.

Quote
So in affect this code:
1  
setLayout(null); button.setLocation(20,20);

all by itself has the same affect as
1  
button.setSize(0,0);


Again, correct.  Since you explicitly call "setLayout(null)", there is no LayoutManager installed to calculate the appropriate size of the button.  Thus, it defaults to a size of (0,0).  I fail to see what your problem is.  If you spent time reading the documentation on layout managers, you'd know what was going on.

Maybe this will clarify things for you:  If you use a LayoutManager, you're telling your container "use this logic to size and position your child components."  If you say "setLayout(null)", you're essentially telling your container "Don't size or position any child components for me; I'm going to handle all of that myself."

Quote
And layout managers position stuff how-ever they like to.

This is false.  Each LayoutManager has explicit rules it follows to lay out components.  These rules are described in their documentation (Javadoc).  You pick the layout manager that will arrange your components as you want them to be, and it does it.

Quote
You cant tell position of a component when a layout manager is done with it.

Actually, you can, via Component#getLocation(), but that's beside the point.  The idea is that the programmer doesn't actually care what exact pixel location his components are at.  He only cares that they are laid out properly, sized properly, have the proper amount of spacing between them, etc.  Layout managers do this for you.

Quote
It doesnt make sense to me why a programmer must set the size of a checkbox when he doesnt have to.

A programmer doesn't have to.  If he uses a layout manager, it'll set the size for you.  Again, somebody must set the size of your components: either you must do it explicitly, or you can use a LayoutManager to do it for you.  Why is that so difficult to accept?

Quote
Well, the first default size is the smallest size to fit the contents of the component. You get it when you do this:
1  
2  
3  
4  
void init(){
Button button=new Button("Button");
add(button);
}

The "second" default size is (0,0), you get it when u do this:
1  
2  
3  
4  
5  
void init(){
Button button=new Button("Button");
setLayout(null);
add(button);button.setLocation(20,20);
}


This is because in your first init() method, the default layout manager is being used.  This default layout manager is sizing your button for you.  In the second init() method, you're explicitly saying to use null layout.  Since there's no layout manager to size your component for you, it defaulted to a size of (0,0), and so you'll have to set its size (and position) yourself.  I fail to see your point here.

Quote
Like i said, im gonna modify it after i finish. First i gotta make sure it works without making my head explode with countless classes.

If that's how you work, that's fine.  You're not the only person in the world who doesn't like OOP.


Quote
Common, everyone knows that OOP takes more statements to implement than FO. A formal OOP implementation requires the use of declaration, setters and getters, while OF only needs a declaration.

I won't argue that OOP languages with Java-style syntax are concise.  The idea Java's designers were going for is "readability over compactness."  They believed that having source that's easier for programmers to read was worth the extra 50 lines in a source file.  Your opinion may differ, and that's fine; but surely you'd agree that you should never sacrifice code readibility or extendability for the sake of "making it as short as possible?"

Quote
Yeah right, they never had to press Backspace or Delete or refer to a manual or debug or ask for help. Common!

I never said programmers didn't make mistakes.  I said that you can be pretty comfortable that the AWT, as an API, is stable, and any problems you're experiencing are much more likely to be bugs in your code then in the AWT itself.  And I'd be willing to wager that most Java developers have Javadoc open in a web browser while they program (or use a tool such as Eclipse that spoon-feeds your Javadoc to you while you type).

Quote
The AWT may not be buggy, but its a little under-developed, which is what i have a problem with. 
 

Remember, you're the one that implied that AWT was buggy (see what you titled this thread, and your previous posts in this thread).  Then, it turned out that it wasn't the AWT that was your problem, it was that you hadn't spent time to read any documentation to know how to actually use the API.  And could you clarify what you mean by "under-developed?"  If you want something more feature-rich, go with Swing over AWT, as the AWT feature set isn't really being updated anymore (save Desktop support I suppose). 
Offline BoBear2681

JGO Coder


Medals: 18



« Reply #45 - Posted 2008-03-02 19:59:13 »

I'll see you in the carpark, mister! Wink

OK, compromise! - In this particular case layout manager's probably the best way to go...

Compromise is good.  That way, we both win (or lose)!   Smiley
Offline Mr_Light

Senior Member




shiny.


« Reply #46 - Posted 2008-03-02 20:23:40 »

Your overriding a button's size as soon as you set text on it, which most of us do by calling the constructor.

The more I think about null layouts which I ditched ages ago, the more issues popup.

borders spacing, are all differend among L&F, difference in fonts difference in dpi difference in resolution etc, there is no way you get away with fixed sizes unless you have complete controll. We're talking fullscreen exclusive here.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline alexxz4

Junior Member


Projects: 1



« Reply #47 - Posted 2008-03-04 17:20:20 »

The implementation of layout managers is not trivial. Why not just keep the size of a component as if it did have a layout manager when a user decides not use one. Setting a component size to 0 inroduces so much ambiguity. If it just set the size to some number (not 0) then the programmer would know that he needs to resize it. Anyways, lets not argue aout the correct use of layout managers, if there is function that disables a layout manager, then the AWT should fully support this possibility.

[ Motherload Unlimited looking for programmers ] [ Solitaire ]
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #48 - Posted 2008-03-04 18:11:39 »

Quote
Why not just keep the size of a component as if it did have a layout manager when a user decides not use one. Setting a component size to 0 inroduces so much ambiguity. If it just set the size to some number (not 0) then the programmer would know that he needs to resize it. Anyways, lets not argue aout the correct use of layout managers, if there is function that disables a layout manager, then the AWT should fully support this possibility.

To me it makes perfect sense that without any LayoutManager, no layout is being done for you whatsoever, so no sizes are being set.

I think what you're basically suggesting is a new LayoutManager, something like AbsolutePositioningLayout which only does a 'best effort' to size the GUI components. Still, I'd never use it, although it might be useful in some simple cases for some.

Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2
Exp: 14 years


Make it work; make it better.


« Reply #49 - Posted 2008-03-04 18:20:55 »

The implementation of layout managers is not trivial. Why not just keep the size of a component as if it did have a layout manager when a user decides not use one. Setting a component size to 0 inroduces so much ambiguity. If it just set the size to some number (not 0) then the programmer would know that he needs to resize it. Anyways, lets not argue aout the correct use of layout managers, if there is function that disables a layout manager, then the AWT should fully support this possibility.
Also all the documentation tells you to use LayoutManagers with Swing and AWT.  Use of Swing or AWT without LayoutManagers is not recommended, so no documentation exists for that.  You have to figure it out.  But I forgot reading documentation takes too much time, lets just hack around and then blame other peoples code when things don't work.

Offline alexxz4

Junior Member


Projects: 1



« Reply #50 - Posted 2008-03-07 19:30:30 »

Like OMG, guess what happened  Shocked
A friend of mine has to make an  applet for his class where he has to place two textfields in the center and two scrollbars below each texfield using Layout Managers. So we spent a few hours figuring it out and arrived at nowhere. I coulda done all that without layout manager in 2 minutes. Man, i wouldnt wanna be in his place...  Roll Eyes
Turns out im not the only one who does not consider layout managers the easiest thing in the world.

[ Motherload Unlimited looking for programmers ] [ Solitaire ]
Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2
Exp: 14 years


Make it work; make it better.


« Reply #51 - Posted 2008-03-07 20:08:11 »

Like OMG, guess what happened  Shocked
A friend of mine has to make an  applet for his class where he has to place two textfields in the center and two scrollbars below each texfield using Layout Managers. So we spent a few hours figuring it out and arrived at nowhere. I coulda done all that without layout manager in 2 minutes. Man, i wouldnt wanna be in his place...  Roll Eyes
Turns out im not the only one who does not consider layout managers the easiest thing in the world.

Didn't say it would be easy.

Offline alexxz4

Junior Member


Projects: 1



« Reply #52 - Posted 2008-03-07 20:26:46 »

There isnt by any chance a Layout that doesnt resize components?

[ Motherload Unlimited looking for programmers ] [ Solitaire ]
Offline Jackal von ÖRF

Junior Member





« Reply #53 - Posted 2008-03-07 20:49:49 »

Depends on what you mean by resizing. With SpringLayout it's possible to have layouts which do not stretch the components when the window size is changed - it all depends on what constraints you set. The problem is that SpringLayout was not designed for writing layout code by hand, so it's maybe the hardest LayoutManager to use. However, using a null layout is much harder than using SpringLayout, so maybe you'll like it. Roll Eyes At least SpringLayout will use the preferred size of the components.

Offline BoBear2681

JGO Coder


Medals: 18



« Reply #54 - Posted 2008-03-07 22:42:19 »

There isnt by any chance a Layout that doesnt resize components?

There are lots of ways to do this.  One common way is to put the components you don't want resizing in a JPanel at BorderLayout.NORTH (or SOUTH, LINE_START or LINE_END, depending on where you want it anchored).  Read the documentation on BorderLayout for details.

And before I forget, here's one more good reason to go with layout managers over null layout:  Say someone using your program has different display settings than you (say they're using an enlarged default font setting because of poor vision).  If you use null layout, your GUI will look horrible - nothing will be the right size, components may overlap, etc - unless you hard-code a font to use, which is often a bad idea.  If you had used a LayoutManager, it would have taken care of sizing the components for you, and things would be fine.
Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2
Exp: 14 years


Make it work; make it better.


« Reply #55 - Posted 2008-03-07 22:46:14 »

What you need to do is nest layouts.  If you want to say put a button at the bottom of your screen, then you use BorderLayout.  The problem is that the button is sctretched out as wide as the display.  To counteract that you add a JPanel to the bottom(SOUTH) of your BorderLayout and then set that JPanel to use FlowLayout.  Then add the button to that JPanel.  It will be at the bottom, but will stay at the proper size.

There is a short tutorial just on LayoutManagers.  It will help you understand them better.

http://java.sun.com/developer/onlineTraining/GUI/AWTLayoutMgr/shortcourse.html

Offline Mr_Light

Senior Member




shiny.


« Reply #56 - Posted 2008-03-08 00:33:45 »

Netbeans  WYSIWYG gui profides pretty clean code. (using group layout.) and is backported you can download a separate jar from spring labs for <1.6.

SpringLayout is just crap imo

GroupLayout replaced all Layout managers appart from the rare occasional borderlayout.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #57 - Posted 2008-03-10 10:13:55 »

Like OMG, guess what happened  Shocked
A friend of mine has to make an  applet for his class where he has to place two textfields in the center and two scrollbars below each texfield using Layout Managers. So we spent a few hours figuring it out and arrived at nowhere. I coulda done all that without layout manager in 2 minutes. Man, i wouldnt wanna be in his place...  Roll Eyes
Turns out im not the only one who does not consider layout managers the easiest thing in the world.

LayoutManagers will start to make things easier than absolute positioning as soon as you start making GUI's that go beyond 2 textfields.
But most importantly, LayoutManagers make your GUI's *better*.

Really, they're not difficult or time consuming to use at all.
If you'd spent your time learning to use them rather than argueing about them, you would've been an expert by now. And probably a LayoutManager evangelist too  Smiley

Pages: 1 [2]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Nickropheliac (16 views)
2014-08-31 22:59:12

TehJavaDev (23 views)
2014-08-28 18:26:30

CopyableCougar4 (33 views)
2014-08-22 19:31:30

atombrot (42 views)
2014-08-19 09:29:53

Tekkerue (41 views)
2014-08-16 06:45:27

Tekkerue (35 views)
2014-08-16 06:22:17

Tekkerue (26 views)
2014-08-16 06:20:21

Tekkerue (37 views)
2014-08-16 06:12:11

Rayexar (73 views)
2014-08-11 02:49:23

BurntPizza (49 views)
2014-08-09 21:09:32
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!