AWT stuff is not reliable

Newbie & Debugging Questions
#21

Hmmm… i thought what i had in update() method was supposed to take care of double-buffering. Anyways, its not really important, im not gonna use optionpanes in this project.
Ok, to elaborate on some of my code, here is a piece of it from actionPerformed(ActionEvent e):

else if(e.getSource()==b_quiz){
			function=3;                        // this sets it to quiz mode
			map_index=-1;
			b_atlas.setVisible(false);	b_quiz.setVisible(false);     // this hides quiz and atlas buttons so that they dont show
			loadAsia();                   // this loads all the graphical stuff and flags of the continent
			question_mode=1;    // this mode is multiple choice question 
			newQuestion(question_mode);   // this generates new question
			hideAWT(false);                // this shows all the components on the screen
			positionAWT();       // this positions and resizes buttons and checkboxes
			showComponents(question_mode);        // this hides some of the components that are not needed.
		}

This is a piece of code from showComponents() that sets visible those components that need to be shown. Notice that if mode=1, then the 4 checkboxes should be visible.

if(mode==1 || mode==4 || mode==6 || mode==9 || mode==11 || mode==13 || mode==16
			 || mode==17){
			checkbox1.setVisible(true);	checkbox2.setVisible(true);
			checkbox3.setVisible(true);	checkbox4.setVisible(true);
			textfield.setVisible(false);
		}

Maybe those buttons that are named “submit” are never shown by java (same goes for the checkboxes). But then again, i tried renaming them and still doesnt work, so its not it. Maybe there is a limit on how many components you can have and maybe i have too many… :-\
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…

#22

if you change the UI you may be asked to call for a repaint() of the whole contents. Swing or AWT, when a child component is modified the repaintManager is not necessarily notified, depending on the implementation of the components.
e.g. for an Animation component I built myself :

 /*the player is a Swing Timer that validates the new animation frame index and THEN REPAINTS THE PARENT IF EXISTING */
new ActionListener() { public void actionPerformed(ActionEvent e) {
      validate(); // animation time ms is updated and the frame is loaded and made visible, in some way.
     if(Animation.this.getParent() instanceof Container)
              Animation.this.getParent().repaint();
     else
            repaint();
}}

This scheme must work for all Component or JComponent implementations. ::slight_smile:

#23

No, like i said, repaint()'ing doesnt help. :stuck_out_tongue:

If its not too hard, could someone modify the source code so that it works?

#24

Us writing down the/any solution won’t get you anywhere. When the next problem occurs, you’ll find yourself running back to us.

One of the problems you found yourself into, is that your problem grew too big, and thus cannot be easily fixed.

When you find yourself running into any coding problem, narrow it down until you understand what is happening. At this point, it’s easy to fix the bugs.

In your case, programming is not just knowing the language, it’s about knowing the APIs and proper coding styles. You have to understand what your code does, and how it handles the APIs, because when you don’t, you’ll never know whether your code, or the API caused that bug you’re seeing. It’s pretty safe to assume the bug is in your code most of the time, though. When in doubt, insert lots of System.out’s, to see what state your application is in, as your assumptions can be very wrong.

To be a bit more specific: either Google your way out, read a book about AWT, or keep finding yourself getting stuck all the time. Build test-cases of a few dozen lines, where you test functionality (like: what happens when I remove a button from a panel, should I repaint/invalidate/revalidate?)

Good luck!

#25

[quote]In your case, programming is not just knowing the language, it’s about knowing the APIs and proper coding styles. You have to understand what your code does, and how it handles the APIs, because when you don’t, you’ll never know whether your code, or the API caused that bug you’re seeing. It’s pretty safe to assume the bug is in your code most of the time, though. When in doubt, insert lots of System.out’s, to see what state your application is in, as your assumptions can be very wrong.
[/quote]
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 would never touch AWT if this project was only for myself, but im “supposed to” use java API.
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.

#26

OMG, i shouldve known it. When setting location of a component, you need to set its size too, otherwise it would not show. So all components, including checkboxes need to have their size set (setting a size of a checkbox has no effect by default, but u need to set its size when u change its position). :o That makes hole lotta sence, no brainer. Works out pretty nice when you need to change a button’s text, you would have to guess the buttons required length or use FontMetrics class. I love java OMG.
Now i know some of the experts here knew this and yet didnt tell me. >:(

#27

sigh

This what LayoutManagers do.

#28

How about READ THE TUTORIAL. You are not using AWT properly and this is causing ALL of your problems. This is not a bug in Java. The first sign of an inexperience programmer is one who blames other code before their own. If you learn how to use AWT properly your problems will disappear. You spend all this time trying to figure out what is wrong when you could have been half way through the tutorial by now.

#29

[quote]You spend all this time trying to figure out what is wrong when you could have been half way through the tutorial by now.
[/quote]
Well, considering that stuff about positioning is at the end, i saved some time.
Still, normal assumption is that if you want to change position of a button only (and keep its size to default) you would only need to use setLocation() without using setBounds() and changing its size. The same goes for checkboxes, i dont see any reason why anyone would change its size. Lets use common sense, people. If everyone referred to java tutorial without making assumptions we would not get anywhere.
Anyways, its easy to blame it all on me since i was the one who found the answer. OMG.

#30

You are so great.

#31

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 “==” :

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) :o

#32

Yeah man, if I were you I’d ask for a refund. ::slight_smile:

I mean seriously, a forum is not a helpdesk.

#33

Sometimes reading this forum is much more fun than the daily wtf. Great :slight_smile:

#34

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.

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.

[quote=“alexxz4,post:21,topic:31439”]
The reason no one is telling you that is because it just isn’t true.

I’d be crazy enough to do it. but see above.

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.

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.

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?

say what?

#35

[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?
[/quote]
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?
[/quote]
I’d be crazy enough to do it. but see above.
[/quote]
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.
[/quote]
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?
[/quote]
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. ::slight_smile:

#36

Your assertion that your code is the same for all components is it based on anything else then air?

[quote=“alexxz4,post:35,topic:31439”]
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.

[quote=“alexxz4,post:35,topic:31439”]
Short lived objects might be more efficient in certain cases, the amount of classes that OOP introduce are largely insignificant performance wise.

I wouldn’t know, I do know that something that is well ordered is much easier to modify and read.

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

#37

[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.
[/quote]
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.
[/quote]
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.
[/quote]
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.
[/quote]
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.

#38

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.

I’m not sure what you mean by this.

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.

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.

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

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.

#39

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.

#40

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).

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. :slight_smile: