Link to home
Start Free TrialLog in
Avatar of CatDevlp00
CatDevlp00

asked on

JDialog - Netscape 4.5 probelm

We're developing an applet with swing components which uses a JProgressBar inside of a JDialog to display the progress of loading data from
our server to the screen.  All of this is running on the event thread.  The JDialog pops up, but the problem is that it doesn't paint any of its components (the JProgressBar and a JLabel) and thus remains blank.  This only occurs under Netscape, the JDialog paints fine under Visual Age and Marimba.  

My question is what causes this problem under netscape and is there any way I can force the JDialog to paint its components (JProgressBar and JLabel) so that they display?
Avatar of diakov
diakov

Describe in which thread you're downloading data and in which you update the dialog.

I suggest a separate thread that updates the progress bar during the data processing. You have to be carefull though, better use invokeLater() for the gialog updates as Swing components in general is not thread safe.

For example,

//run of the data thread
public void run()
{
  while (true)
  {
    //load some data
    ...
    //update gui
    SwingUtilities.invokeLater(new Runnable()
    {
      //this run will be called in the event thread      
      public void run()
      {
        dialog.label.setText("new text");
      }
    }
    );

    //is end? --> break;
  }
}

Cheers,
  Nik
ASKER CERTIFIED SOLUTION
Avatar of kollegov
kollegov

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
I forgot to tell, this is common problem for
any subclass of  dialogs which is MODAL
I have used MODAL Dialogs (not JDialog) for quite a long time - without a single problem wiht IE / NN (Windows versions)

so I don't think that this is a modal problem :), but it would be nice to see some example code that blocks NN.
HeyHey, today I was fixing this problem again in some product :)

The problem is that if modal dialog have much nested components and requires significant time to repaint
you have chance (in NN4 winNT, Solaris) that thread will be blocked before dialog will be completely repainted.
This is stable reporoducable problem.

I fixed it quite easy way..

I made listener which shows dialog
Runnable and instead of direct showing window from ActionPerformed method
I started new thread (th) there.
Than run() method of the listener
had the following code
public void run(){
   Thread.currentThread().setPriority(Thread.MIN_PRIORITY);
th.yield();
myDialog d=new MyDialog(...);
myDialog.show();
}

This completely solved problem..

Guess here the problem is the same..






HeyHey, today I was fixing this problem again in some product :)

The problem is that if modal dialog have much nested components and requires significant time to repaint
you have chance (in NN4 winNT, Solaris) that thread will be blocked before dialog will be completely repainted.
This is stable reporoducable problem.

I fixed it quite easy way..

I made listener which shows dialog
Runnable and instead of direct showing window from ActionPerformed method
I started new thread (th) there.
Than run() method of the listener
had the following code
public void run(){
   Thread.currentThread().setPriority(Thread.MIN_PRIORITY);
th.yield();
myDialog d=new MyDialog(...);
d.show();
}

This completely solved problem..

Guess here the problem is the same..






I agree that slow paint() code may ruin a lot of things (not even the modal dialogs :), isn't it better to optimize that code :) - double buffering etc.

of course if there is a lot of Swing UI, you can't control it.
HeyHey...  The problem isn't in slow drawing itself, but in unguranteed event delivery time and order.
Slow code or processor load with other tasks only increase the probability..
Optimizing will decrease it, but probability always is.
to Kolleqov:

Event order is always guaranteed. The order of execution of the code that puts this events in the event queue is not. You can order most of your GUI related code (provided you run several threads) using invokeLater, however this is quite tricky.

Cheers,
  Nik
Avatar of CatDevlp00

ASKER

to kollegov:

  Sorry, I don't quite understand your suggestion.  Are you saying that I should create the new JDialog with the JProgressBar under a new thread (separate) from the event thread

or

are you saying that I should update my JDialog from a separate thread?

to diakov:

  Are you suggesting a separate thread which creates my JDialog or do you mean to make my JDialog implement runnable and then try to update it through the required run method?

Sorry I wasn't quite clear what you two are getting at.  I would post the code but it's far too lengthy to be pasted here (it's a rather complex program).
No, I suggest you instantiate your dialog as usual, but move the data handling in a separate thread. Then you do the dialog update by using invokeLater() together with an anonymous runnable instance.

Cheers,
  Nik
I used something like this:

class AL implements
ActionListener,Runnable{
   Thread th=null;
   public void actionPerformed(...){
   
   Thread th=new Thread(this);
   if(th==null) th.start();
  }
 
  public void run(){
   Thread.currentThread().yield();
   //do whatever you did in actionPerformed here
   JDialog jd = ....;
   
   
  }
}

and this works :)