🚀 go-pugleaf

Thanks Paul again. Yes I agree with you that we must not invoke
JOptionPane.show***
from within paintComponent(). I can't explain why anomalies (showing Ok
button and
some others from the show*** method) are in the moved dlg, either. But that
may be
the price we have to pay when we do something not supposed to do...

Yes I could avoid invoking JOptionPane.show*** in paintComponent() or in a
method
which originates from it. I could invoke it in the main thread instead. In
the main thread,
I simply set a flag and let the method (which originates from paintCompo)
invoke the
show*** to let the method ask for the user choice to the effect. That was
the way I
chose without realizing of such mess. In several places. Other places seem
to work
without the mess.

So I am going to move those 'set a flag' functions to the main thread.

I also invoked 'doClick()' from within itemStateChanged(). It appears that
this doClick
seems Ok to be invoked from within the event handling method. (Perhaps
because of
the fact that the state change due to doClick occurs in other component?)
But I had
better move it out of the method and put it in the main thread.

I can't understand why the 2nd paintCompo is not called in my case (I mean
in my
project, not the code I included in this emal). If we can rely on the fact
that System.
out.println() is always done, the call is missed as long as I can tell in my
case. Maybe
such anomaly is one of those prices to pay from doing something not to do, I
guess.

Thanks again Paul.


"Paul Furbacher [TeamB]" <pfurbacher@mac.com> wrote in message
news:462306c0$1@newsgroups.borland.com...
> Hiroshi Nakata wrote:
>
> > Thanks again. Ok, I tried your code and visually confirmed that
> > g.draw***() in your code are indeed executed when the message
> > dlg is closed. [However I didn't confirm that all pieces are
> > redrawn (by the closure) because the frame is too small and
> > black background (including 2 buttons.)]
>
> But the frame in my demo is resizable, and the fact that
> the background is black hardly makes a difference.  If you
> resize, you see that all components redraw, including the
> custom panel component.  The text area updates the date
> to show what was shown in the message dialog.
>
> So I'm a bit mystified why you claim that it's not painting
> correctly.
>
>
> > I realized that your case calls JOptionPane.show*** from within
> > ActionEvent handling (in the event thread). My case was that it
> > was called from within paintComponent (though not directly in
> > paintCompo but in some method initiated from paintCompo). Ie
> > before the paint/drawing handling (in the event thread) is
> > completed, another paint/drawing request is queued in my case.
>
> I'm not sure why you would ever want to do this -- that is,
> pop open a dialog box in a paint method.  Typically, a dialog
> box is shown to respond to some user action, or as an alert
> created by a listener to some process (usually long-running).
> In your case, unless I'm missing some fine distinction, it
> makes no sense to be opening the message dialog in the
> paintComponent, except as a learning exercise.  (There are
> better ways to get info than by doing this though.)
>
>
> > To simulate my case, I changed your code a bit in mechanics and
> > executed. [...]
> >
> > I included the code below. As you run, you can confirm that the
> > result or effect from calling (and closing) JOption.show*** at
> > ActionEvent and paint handling are indeed different.
>
> It appears to me that your code shows
> some anomalies if I move the message pane around, but it's
> not clear to me why some portions of the special panel repaint
> and others don't.
>
>
> > To call JOptionPane.show*** within paintCompo, you move the
> > main frame (so that the system triggers JPanel.repaint(). Well
> > to be more precise, JFrame.repaint() first then, JFrame calls
> > repaint(), or update(), of its child compos in it.)
>
> I found that I first had to press the "Set" button, and then
> *resize* the window in order to provoke the event.
>
>
> > Your way seems better. Your way, however, is
> > not quite right because the (diagonal) line is drawn in 2
> > colors; one with intended another with unintended because of
> > the fact that the pnl.repaint() call from the dlg closure is
> > queued and the actual paintCompo from it occurs afterward, not
> > within the paintCompo (because otherwise doomed to stack
> > overflow) and the actual drawing is limited to the dirty
> > region. This is why I needed to call pnl.repaint() again after
> > JOption.show*** so that this new drawing draws everything,
> > inside and outside the dirty region. But this 2nd repaint() is
> > not executed...
> >
> > As a conclusion, I am still in the woods...
>
> Me, too.  There seems to be something which you have not
> described about the actual goal of showing a message dialog
> and what your intention is with the "Set" button.  You are
> expecting some kind of painting behavior in response to
> some set of conditions, the latter not at all clear to me.
>
> For a start, I'd completely abandon the approach which puts
> the message dialog in the paint method.  What is supposed
> to trigger this message dialog, and why do you need it?
>
>
> -- 
>
>
> Paul Furbacher (TeamB)
>
>    Save time, search the archives:
>         http://info.borland.com/newsgroups/ngsearch.html
>
>    Is it in Joi Ellis's Faq-O-Matic?
>         http://www.visi.com/~gyles19/fom-serve/cache/1.html
>
>    Finally, please send responses to the newsgroup only.
>    That means, do not send email directly to me.
>    Thank you.