🚀 go-pugleaf

Does this do what you want -- a value is updated after
closing a message pane?

package repaint_issue;

import java.util.*;

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

/** Shows that you don't have to do anything to update
  * the UI after showing a JOptionPane.showXXXDialog()
   */
public class Frame1
     extends JFrame {


   JLabel jLabel1 = new JLabel();
   JTextField tf = new JTextField();
   GridBagLayout gridBagLayout1 = new GridBagLayout();
   JButton quitButton = new JButton();
   JButton showButton = new JButton();


   public Frame1() {
     try {
       jbInit();
     }
     catch (Exception exception) {
       exception.printStackTrace();
     }
   }

   private void jbInit() throws Exception {
     getContentPane().setLayout(gridBagLayout1);
     jLabel1.setText("Date: ");
     quitButton.addActionListener(new ActionListener() {
       public void actionPerformed(ActionEvent actionEvent) {
         quitButton_actionPerformed(actionEvent);
       }
     });
     showButton.setText("Show message");
     showButton.addActionListener(new ActionListener() {
       public void actionPerformed(ActionEvent actionEvent) {
         showButton_actionPerformed(actionEvent);
       }
     });
     quitButton.setText("Quit");
     this.getContentPane().add(showButton,
                               new GridBagConstraints(0, 2, 2, 1, 0.0, 0.0
         , GridBagConstraints.WEST, GridBagConstraints.NONE,
         new Insets(12, 12, 11, 0), 0, 0));
     this.getContentPane().add(quitButton,
                               new GridBagConstraints(2, 2, 1, 1, 0.0, 0.0
         , GridBagConstraints.EAST, GridBagConstraints.NONE,
         new Insets(12, 0, 11, 11), 0, 0));
     this.getContentPane().add(jLabel1,
                               new GridBagConstraints(0, 1, 1, 1, 0.0, 0.0
         , GridBagConstraints.WEST, GridBagConstraints.NONE,
         new Insets(12, 12, 0, 8), 0, 0));
     this.getContentPane().add(tf, new GridBagConstraints(1, 1, 2, 1, 
1.0, 0.0
         , GridBagConstraints.WEST, GridBagConstraints.HORIZONTAL,
         new Insets(12, 0, 0, 11), 322, 0));
   }

   public static void main(String[] args) {
     Frame1 frame1 = new Frame1();
     frame1.pack();
     frame1.setVisible(true);
   }

   public void quitButton_actionPerformed(ActionEvent actionEvent) {
     System.exit(0);
   }

   public void showButton_actionPerformed(ActionEvent actionEvent) {
     String date = new Date().toString();
     JOptionPane.showMessageDialog(this, "A message" + date);
     tf.setText(date);
   }
}

If so, you don't have to invoke any kind of repaint or update.


Hiroshi Nakata wrote:
> When a Java app calls repaint() after JOptionPane.show***Dialog(),
> the repaint() is ignored because closing the dlg triggers a repaint() from
> the system, and the Java "drawing system" skips the 1st request (from the
> Java app) and executes only the 2nd (from the system).
> 
> This leaves some region unmodified in a panel (to which repaint() is
> triggered)
> because the repaint() from the system repaints only 'dirty' region (ie
> region
> covered  by the dlg). Here is a situation:
> 
> 1)call repaint() to draw into a JPanel, jpnl, ie in jpnl.paintComponent(),
>     g.draw***() are called.
> 2)call JOptionPane.show***Dialog() which is covering jpnl.
> 3)close the dlg, triggering jpnl.repaint() by the system
> 4)set some change (according to the inputs in the dlg) into effects in jpnl
>    when drawn (such as new lines added)
> 5)call jpnl.repaint() to see the change.
> 
> Result is that 5) is not executed by the "drawing system" because of the
> same call, jpnl.repaint(), in 3).
> 
> How can we force the "drawing system" not to skip consecutive repaint()
> calls?
> Or am I missing something?


-- 


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.

Hiroshi Nakata wrote:
> Thank you Paul for replying to my question. I am aware that all Swing/AWT
> components
> (in Container) which are entirely or partially in the dirty region will be
> automatically
> redrawn by super.paintComponent() [which is typically called at the very
> beggining
> of jpnl.paintComponent().] Therefore if no g.draw***()s are needed in jpnl,
> no need to
> call jpnl.repaint(). Your example is exactly that. But when jpnl doesn't
> have any such
> components but needs to be drawn with g.draw***(), things are different
> because
> super.paintComponent() won't draw anything but clear the panel in that case.
> I think  [...]

I'm not sure I understand what or how you are drawing -- a code
snippet of the custom component may have been more helpful.

Is the following, which does repaint correctly, close to what
you are trying to do?

package repaint_issue;

import java.util.*;

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

/** Shows that you don't have to do anything to update
  * the UI after showing a JOptionPane.showXXXDialog()
   */
public class Frame1
     extends JFrame {


   JLabel jLabel1 = new JLabel();
   JTextField tf = new JTextField();
   GridBagLayout gridBagLayout1 = new GridBagLayout();
   JButton quitButton = new JButton();
   JButton showButton = new JButton();
   JPanel specialPanel = new SpecialPanel();
   GridBagLayout gridBagLayout2 = new GridBagLayout();

   public Frame1() {
     try {
       jbInit();
     }
     catch (Exception exception) {
       exception.printStackTrace();
     }
   }

   private void jbInit() throws Exception {
     getContentPane().setLayout(gridBagLayout1);
     jLabel1.setForeground(Color.yellow);
     jLabel1.setText("Date: ");
     quitButton.addActionListener(new ActionListener() {
       public void actionPerformed(ActionEvent actionEvent) {
         quitButton_actionPerformed(actionEvent);
       }
     });
     showButton.setOpaque(false);
     showButton.setText("Show message");
     showButton.addActionListener(new ActionListener() {
       public void actionPerformed(ActionEvent actionEvent) {
         showButton_actionPerformed(actionEvent);
       }
     });
     quitButton.setOpaque(false);
     quitButton.setText("Quit");
     specialPanel.setLayout(gridBagLayout2);
     this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
     specialPanel.add(tf, new GridBagConstraints(1, 2, 2, 1, 1.0, 0.0
         , GridBagConstraints.WEST, GridBagConstraints.HORIZONTAL,
         new Insets(12, 0, 0, 11), 322, 0));
     specialPanel.add(jLabel1,
                               new GridBagConstraints(0, 2, 1, 1, 0.0, 0.0
         , GridBagConstraints.WEST, GridBagConstraints.NONE,
         new Insets(12, 12, 0, 8), 0, 0));
     specialPanel.add(quitButton,
                               new GridBagConstraints(2, 3, 1, 1, 0.0, 0.0
         , GridBagConstraints.EAST, GridBagConstraints.NONE,
         new Insets(12, 0, 11, 11), 0, 0));
     specialPanel.add(showButton,
                               new GridBagConstraints(0, 3, 2, 1, 0.0, 0.0
         , GridBagConstraints.WEST, GridBagConstraints.NONE,
         new Insets(12, 12, 11, 0), 0, 0));
     this.getContentPane().add(specialPanel,
                               new GridBagConstraints(0, 0, 1, 1, 1.0, 1.0
         , GridBagConstraints.NORTHWEST, GridBagConstraints.BOTH,
         new Insets(0, 0, 0, 0), 0, 0));
   }

   public static void main(String[] args) {
     Frame1 frame1 = new Frame1();
     frame1.pack();
     frame1.setVisible(true);
   }

   public void quitButton_actionPerformed(ActionEvent actionEvent) {
     System.exit(0);
   }

   public void showButton_actionPerformed(ActionEvent actionEvent) {
     String date = new Date().toString();
     JOptionPane.showMessageDialog(this, "A message" + date);
     tf.setText(date);
   }


   public class SpecialPanel extends JPanel {

     public SpecialPanel() {
       super();
     }

     protected void paintComponent(Graphics g) {
       super.paintComponent(g);
       Insets insets = getInsets();
       int currentWidth = getWidth() - insets.left - insets.right;
       int currentHeight = getHeight() - insets.top - insets.bottom;
       Graphics2D g2d = (Graphics2D)g.create();
       g2d.fillRect(0, 0, currentWidth, currentHeight);
       g2d.drawRect(2, 2, currentWidth - 2, currentHeight - 2);
       g2d.setColor(Color.RED);

       g2d.drawLine(3,3, currentWidth - 3, currentHeight - 3);
       g2d.drawString("Testing .................", 200, 70);
       g2d.dispose();
}

   }
}

-- 


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.

Thank you Paul for replying to my question. I am aware that all Swing/AWT
components
(in Container) which are entirely or partially in the dirty region will be
automatically
redrawn by super.paintComponent() [which is typically called at the very
beggining
of jpnl.paintComponent().] Therefore if no g.draw***()s are needed in jpnl,
no need to
call jpnl.repaint(). Your example is exactly that. But when jpnl doesn't
have any such
components but needs to be drawn with g.draw***(), things are different
because
super.paintComponent() won't draw anything but clear the panel in that case.
I think
g.draw***()s are still executed, but drawn only inside the dirty region. So
jpnl.repaint()
needs to be called from the app. Then when this 2nd repaint() is skipped by
the drawing
subsystem, such change (as drawing a line longer) by app is not shown in
jpnl.

I remember reading statements about 'amalgamating' drawing events in the
subsystem
for Java efficiency (in terms of speed) in some article long time ago.
Reading ahead
those events and making into 1 event. And I thought, skipping the 2nd
repaint() is one
of those 'so-cleaver' steps taken in the subsystem.

Currently I set 'redraw' button in my app to overcome this difficulty but I
consider it
too awkward and undesirable. Sometimes when a graphic object (=specific to
my
app) is opened and drawn, lines are drawn a couple of lines upper at some
point
(thus forms a y direction step/jump), which is obviously caused by those
'so-cleaver'
steps in the subsytem, I think. So I needed this 'redraw' button for that
reason, too.


"Paul Furbacher [TeamB]" <pfurbacher@mac.com> wrote in message
news:461c6bba$1@newsgroups.borland.com...
> Does this do what you want -- a value is updated after
> closing a message pane?
>
> package repaint_issue;
>
> import java.util.*;
>
> import java.awt.*;
> import java.awt.event.*;
> import javax.swing.*;
>
> /** Shows that you don't have to do anything to update
>   * the UI after showing a JOptionPane.showXXXDialog()
>    */
> public class Frame1
>      extends JFrame {
>
>
>    JLabel jLabel1 = new JLabel();
>    JTextField tf = new JTextField();
>    GridBagLayout gridBagLayout1 = new GridBagLayout();
>    JButton quitButton = new JButton();
>    JButton showButton = new JButton();
>
>
>    public Frame1() {
>      try {
>        jbInit();
>      }
>      catch (Exception exception) {
>        exception.printStackTrace();
>      }
>    }
>
>    private void jbInit() throws Exception {
>      getContentPane().setLayout(gridBagLayout1);
>      jLabel1.setText("Date: ");
>      quitButton.addActionListener(new ActionListener() {
>        public void actionPerformed(ActionEvent actionEvent) {
>          quitButton_actionPerformed(actionEvent);
>        }
>      });
>      showButton.setText("Show message");
>      showButton.addActionListener(new ActionListener() {
>        public void actionPerformed(ActionEvent actionEvent) {
>          showButton_actionPerformed(actionEvent);
>        }
>      });
>      quitButton.setText("Quit");
>      this.getContentPane().add(showButton,
>                                new GridBagConstraints(0, 2, 2, 1, 0.0, 0.0
>          , GridBagConstraints.WEST, GridBagConstraints.NONE,
>          new Insets(12, 12, 11, 0), 0, 0));
>      this.getContentPane().add(quitButton,
>                                new GridBagConstraints(2, 2, 1, 1, 0.0, 0.0
>          , GridBagConstraints.EAST, GridBagConstraints.NONE,
>          new Insets(12, 0, 11, 11), 0, 0));
>      this.getContentPane().add(jLabel1,
>                                new GridBagConstraints(0, 1, 1, 1, 0.0, 0.0
>          , GridBagConstraints.WEST, GridBagConstraints.NONE,
>          new Insets(12, 12, 0, 8), 0, 0));
>      this.getContentPane().add(tf, new GridBagConstraints(1, 1, 2, 1,
> 1.0, 0.0
>          , GridBagConstraints.WEST, GridBagConstraints.HORIZONTAL,
>          new Insets(12, 0, 0, 11), 322, 0));
>    }
>
>    public static void main(String[] args) {
>      Frame1 frame1 = new Frame1();
>      frame1.pack();
>      frame1.setVisible(true);
>    }
>
>    public void quitButton_actionPerformed(ActionEvent actionEvent) {
>      System.exit(0);
>    }
>
>    public void showButton_actionPerformed(ActionEvent actionEvent) {
>      String date = new Date().toString();
>      JOptionPane.showMessageDialog(this, "A message" + date);
>      tf.setText(date);
>    }
> }
>
> If so, you don't have to invoke any kind of repaint or update.
>
>
> Hiroshi Nakata wrote:
> > When a Java app calls repaint() after JOptionPane.show***Dialog(),
> > the repaint() is ignored because closing the dlg triggers a repaint()
from
> > the system, and the Java "drawing system" skips the 1st request (from
the
> > Java app) and executes only the 2nd (from the system).
> >
> > This leaves some region unmodified in a panel (to which repaint() is
> > triggered)
> > because the repaint() from the system repaints only 'dirty' region (ie
> > region
> > covered  by the dlg). Here is a situation:
> >
> > 1)call repaint() to draw into a JPanel, jpnl, ie in
jpnl.paintComponent(),
> >     g.draw***() are called.
> > 2)call JOptionPane.show***Dialog() which is covering jpnl.
> > 3)close the dlg, triggering jpnl.repaint() by the system
> > 4)set some change (according to the inputs in the dlg) into effects in
jpnl
> >    when drawn (such as new lines added)
> > 5)call jpnl.repaint() to see the change.
> >
> > Result is that 5) is not executed by the "drawing system" because of the
> > same call, jpnl.repaint(), in 3).
> >
> > How can we force the "drawing system" not to skip consecutive repaint()
> > calls?
> > Or am I missing something?
>
>
> -- 
>
>
> 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.

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

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.

To simulate my case, I changed your code a bit in mechanics and executed. (I
trimmed
all un-related stuff such as GridBagLayout, and Graphis2D and employed short
variable
names. In spite of 1000 times improvement in all computing features in such
a short time,
display realestate remains almost the same; we don't have 5 screens of 100
lines each,
requiring us to scroll up and down so many times... This was the reason for
the trim.)

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.

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

My stuff is ready to switch to yours or back to mine by // ing a couple of
lines. 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...

Anyway here is my stuff converted from yours.

package repainttest;
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
public class test extends JFrame {
  JButton qBtn=new JButton("Quit"),sBtn=new JButton("Set");
  JPanel  pnl=new NoCompoPanel();
  boolean set=false;
  Color   colr=Color.black;
  public test() {
    Container cp=getContentPane();
    qBtn.addActionListener(new ActionListener() {
      public void actionPerformed(ActionEvent e) {qBtn_acted(e);}});
    sBtn.addActionListener(new ActionListener() {
      public void actionPerformed(ActionEvent e) {sBtn_acted(e);}});
    pnl.setPreferredSize(new Dimension(100,200));
    cp.add(sBtn,BorderLayout.WEST);
    cp.add(qBtn,BorderLayout.EAST);
    cp.add(pnl,BorderLayout.NORTH);
  }
  public static void main(String[] args) {
    test test1=new test();
    test1.setSize(new Dimension(200,250));
    test1.setVisible(true);
  }
  public void qBtn_acted(ActionEvent e) {System.exit(0);}
  public void sBtn_acted(ActionEvent e) {
    colr=Color.blue;
    set=true; //my version - remark this to set to Paul's version
  //JOptionPane.showMessageDialog(this,"Message"); //Paul's version
  }
  public class NoCompoPanel extends JPanel {
    public NoCompoPanel() {}
    protected void paintComponent(Graphics g) {
      super.paintComponent(g);
      if (set)   //my version - remark this to set to Paul's version
        JOptionPane.showMessageDialog(this,"Message");
      g.setColor(colr);
      g.drawLine(0,0,200,200);
      set=false; //my version - remark this to set to Paul's version
      colr=Color.red;
      g.dispose();
    }

"Paul Furbacher [TeamB]" <pfurbacher@mac.com> wrote in message
news:461f0375$1@newsgroups.borland.com...
> Hiroshi Nakata wrote:
> > Thank you Paul for replying to my question. I am aware that all
Swing/AWT
> > components
> > (in Container) which are entirely or partially in the dirty region will
be
> > automatically
> > redrawn by super.paintComponent() [which is typically called at the very
> > beggining
> > of jpnl.paintComponent().] Therefore if no g.draw***()s are needed in
jpnl,
> > no need to
> > call jpnl.repaint(). Your example is exactly that. But when jpnl doesn't
> > have any such
> > components but needs to be drawn with g.draw***(), things are different
> > because
> > super.paintComponent() won't draw anything but clear the panel in that
case.
> > I think  [...]
>
> I'm not sure I understand what or how you are drawing -- a code
> snippet of the custom component may have been more helpful.
>
> Is the following, which does repaint correctly, close to what
> you are trying to do?
>
> package repaint_issue;
>
> import java.util.*;
>
> import java.awt.*;
> import java.awt.event.*;
> import javax.swing.*;
>
> /** Shows that you don't have to do anything to update
>   * the UI after showing a JOptionPane.showXXXDialog()
>    */
> public class Frame1
>      extends JFrame {
>
>
>    JLabel jLabel1 = new JLabel();
>    JTextField tf = new JTextField();
>    GridBagLayout gridBagLayout1 = new GridBagLayout();
>    JButton quitButton = new JButton();
>    JButton showButton = new JButton();
>    JPanel specialPanel = new SpecialPanel();
>    GridBagLayout gridBagLayout2 = new GridBagLayout();
>
>    public Frame1() {
>      try {
>        jbInit();
>      }
>      catch (Exception exception) {
>        exception.printStackTrace();
>      }
>    }
>
>    private void jbInit() throws Exception {
>      getContentPane().setLayout(gridBagLayout1);
>      jLabel1.setForeground(Color.yellow);
>      jLabel1.setText("Date: ");
>      quitButton.addActionListener(new ActionListener() {
>        public void actionPerformed(ActionEvent actionEvent) {
>          quitButton_actionPerformed(actionEvent);
>        }
>      });
>      showButton.setOpaque(false);
>      showButton.setText("Show message");
>      showButton.addActionListener(new ActionListener() {
>        public void actionPerformed(ActionEvent actionEvent) {
>          showButton_actionPerformed(actionEvent);
>        }
>      });
>      quitButton.setOpaque(false);
>      quitButton.setText("Quit");
>      specialPanel.setLayout(gridBagLayout2);
>      this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>      specialPanel.add(tf, new GridBagConstraints(1, 2, 2, 1, 1.0, 0.0
>          , GridBagConstraints.WEST, GridBagConstraints.HORIZONTAL,
>          new Insets(12, 0, 0, 11), 322, 0));
>      specialPanel.add(jLabel1,
>                                new GridBagConstraints(0, 2, 1, 1, 0.0, 0.0
>          , GridBagConstraints.WEST, GridBagConstraints.NONE,
>          new Insets(12, 12, 0, 8), 0, 0));
>      specialPanel.add(quitButton,
>                                new GridBagConstraints(2, 3, 1, 1, 0.0, 0.0
>          , GridBagConstraints.EAST, GridBagConstraints.NONE,
>          new Insets(12, 0, 11, 11), 0, 0));
>      specialPanel.add(showButton,
>                                new GridBagConstraints(0, 3, 2, 1, 0.0, 0.0
>          , GridBagConstraints.WEST, GridBagConstraints.NONE,
>          new Insets(12, 12, 11, 0), 0, 0));
>      this.getContentPane().add(specialPanel,
>                                new GridBagConstraints(0, 0, 1, 1, 1.0, 1.0
>          , GridBagConstraints.NORTHWEST, GridBagConstraints.BOTH,
>          new Insets(0, 0, 0, 0), 0, 0));
>    }
>
>    public static void main(String[] args) {
>      Frame1 frame1 = new Frame1();
>      frame1.pack();
>      frame1.setVisible(true);
>    }
>
>    public void quitButton_actionPerformed(ActionEvent actionEvent) {
>      System.exit(0);
>    }
>
>    public void showButton_actionPerformed(ActionEvent actionEvent) {
>      String date = new Date().toString();
>      JOptionPane.showMessageDialog(this, "A message" + date);
>      tf.setText(date);
>    }
>
>
>    public class SpecialPanel extends JPanel {
>
>      public SpecialPanel() {
>        super();
>      }
>
>      protected void paintComponent(Graphics g) {
>        super.paintComponent(g);
>        Insets insets = getInsets();
>        int currentWidth = getWidth() - insets.left - insets.right;
>        int currentHeight = getHeight() - insets.top - insets.bottom;
>        Graphics2D g2d = (Graphics2D)g.create();
>        g2d.fillRect(0, 0, currentWidth, currentHeight);
>        g2d.drawRect(2, 2, currentWidth - 2, currentHeight - 2);
>        g2d.setColor(Color.RED);
>
>        g2d.drawLine(3,3, currentWidth - 3, currentHeight - 3);
>        g2d.drawString("Testing .................", 200, 70);
>        g2d.dispose();
> }
>
>    }
> }
>
> -- 
>
>
> 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.

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.

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.