🚀 go-pugleaf

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.