Missing pieces of components (JFileChooser, JButtons, etc) help?

The normal window in the GUI i'm working on, works fine. When i bring up a new NetFrame (e.g. preferences) the components aren't drawn completely. None of the 3 buttons show up, a few check boxes in a tabbed pane show up (not all of them), etc. When i click where a button should be, it appears. When i switch to the other tab in the pane, its contents appear (except for a small missing bottom right corner of the border for a jtextarea), and when i switch back to the first tab, all of its contents appear. When i resize the panel, everything shows up.
I've tried calling validate, revalidate, validateTree, repaint, show, pack, none of them do anything (pack rearranges things, but nothing new appears).

I'm completely out of ideas!

A previous version of the program works fine, so it is something wrong with my code (i.e. not my computer / packages etc).

The thing that really stumps me, is that a JFileChooser appears incomplete -- only showing the file browser section, and the okay button (missing cancel button, and borders etc).

I'm sorry i don't have any sample code to show, there too much to put it all, and i have no idea where the problem is.
I'd appreciate any help or direction you have. THANKS!

It's hard to say without seeing the relevant code, or how you tried to use validate, repaint, etc., or knowing what "NetFrame (e.g. preferences)" is. NetFrame isn't a Java SDK class.

Programming is an explanatory activity...
R. Harper

Yeah, sorry for this being an especially annoying-to-help-with post. Especially when i'm just dumb (when i said NetFrame, i meant JFrame... the instance of which i call netframe... anyway).

I tried putting validate/repaint etc. in essentially every place. Inside the constructor of every component, etc. Perhaps the most illustrative ex. is that i put validate() and repaint() in a timer (in the JFrame constructor), to make sure everything had a chance to load before calling them.

I have this question on another thread where someone suggested posting pics of the problems, sounded like a good idea - maybe that will help.

I've seen repaint problems where a frame is displayed and the program continues on to do further processing then eventually waits for user input in another frame. The original frame repainting never gets finished because the events that control it are pre-empted on the queue by events elsewhere, and are eventually lost.

One solution is to use a SwingUtilities.invokeLater(..) call to continue the processing after the problem frame is displayed. This waits until all events on the Swing event dispatch thread have been processed before continuing. This kind of problem is often a symptom of doing heavy or lengthy processing on the Swing event thread when it should be done using a SwingWorker thread.

A process cannot be understood by stopping it. Understanding must move with the flow of the process, must join and flow with it...
F. Herbert

Thanks for your response. I tried placing the invokeLater method (with validate and repaint calls in it), both inside the troubled JFrame, and also in the object that calls it, neither had any effect.

As for threads, i've never used them (rookie--clearly), should that be the next thing i try?

Thanks for you help!

Quote:

---

Originally Posted by jlobe

I tried placing the invokeLater method (with validate and repaint calls in it), both inside the troubled JFrame, and also in the object that calls it, neither had any effect.

---

That's not really what I meant at all - the invokeLater wraps the code to be run - this is the kind of thing I was talking about:

Code:

---

// Display initial frame:
  JFrame frame1 = new MyFrame1("Frame 1");
  ...
  frame1.setVisible(true);
  ...
  SwingUtilities.invokeLater(new Runnable() {
      void run() {
        // Run the rest of the application once frame1 has displayed
        doRestOfApplication(..);
      }
  });
}

---

This is a crude example, and I'm not recommending it in general, but if frame1 doesn't get finished painting, this is an example of how you can delay the rest of the application until the painting is finished - though, of course, it's really better to identify the cause of the problem in the first place.

I don't know how much you know about Swing - you might find it helpful to read the Swing Tutorial.

I'm already assuming you are running your GUI application on the Swing event dispatch thread (EDT) inside an invokeLater or invokeAndWait as standard practice. If not, see Initial Threads.

You can learn about how to use threads in the rest of that tutorial - Java 5 made general threading easier with the Concurrency classes, and Java 6 has made Swing thread interaction simpler with the SwingWorker class. If you need threads, you'll need to understand these classes and how to use them.

If you're going to use facilities like invokeLater, you should be sure you understand what they are doing and why, so you can use them rationally. Just throwing them in at random isn't particularly helpful - if they work you won't know why, if the don't work, you won't know why...

The purpose of computing is insight, not numbers...
R. Hamming