🚀 go-pugleaf

Hi Andrew,
your answers have made the issue much clearer (and got me thinking and
experimenting):
A "parent frame" in the context of a Dialog does not have to be the _ancestor_
frame from which that dialog was spawned! That is an important (and ambiguous)
difference. This ominous "parent" can be just _any_ parent, i.e. a new parent
(biology doesn't come into the picture here).
I have created a simple applet that, with the click on it's one button, spawns 5
dialogs in seperate threads, each of which just counts from x to x+999 and
displays the actual count in a dialog window. I fired that 100 times, either
clearing the left-over dialog windows or not clearing them, from whithin the IDE
and from a browser, I created the dialogs on the fly (whithin the actionPerformed
method of the button) and in the class definition of the applet, and no matter how

they were created or how often they were fired, they did not consume memory after
the threads had died.
The only difference was: if I created them on the fly, the names of the threads
were incremented, whereas when I created the dialogs in the applet class
definition, they were not.
So there is no punishment in the way I use the dialog with an empty constructor.
   Cheers,
      Conrad

This is the dialog I used for the tests:


package dlgtest;

import java.awt.*;
import java.awt.event.*;
import borland.jbcl.layout.*;
import borland.jbcl.control.*;

public class TextBox extends Dialog implements Runnable{
  Panel messagePanel = new Panel();
  static Frame frm = new Frame();  // <--------- SIC!
  BorderLayout borderLayout1 = new BorderLayout();
  private int from, to, offx, offy;
  Label label1 = new Label();

  private TextBox(Frame frame, String title, boolean modal) {
    super(frame, title, modal);
    try {
      jbInit();
    }
    catch (Exception e) { e.printStackTrace(); }
  }

  // the constructor
  public TextBox(int from, int to, int offx, int offy) {
    this(frm, "", false);
    this.from = from;
    this.to = to;
    this.offx = offx;
    this.offy = offy;
  }

  public void jbInit() throws Exception {
    label1.setFont(new Font("Dialog", 1, 16));
    label1.setText("This label will display some text");
    this.addWindowListener(new TextBox_this_windowAdapter(this));
    messagePanel.setLayout(borderLayout1);
    this.add(messagePanel, "Center");
    messagePanel.add(label1, BorderLayout.NORTH);
  }

  public void run() {
    setTitle(getName());
    this.pack();
    Dimension d = Toolkit.getDefaultToolkit().getScreenSize();
    this.setLocation((d.width - offx+getPreferredSize().width) / 2,
                     (d.height - offy+getPreferredSize().height) / 2);
    this.show();
    for (int i=from; i<to; i++) {
      label1.setText("The count is "+i);
    }
  }

  void this_windowClosing(WindowEvent e) {
    dispose();
  }

} //*********** End of class TextBox **************************


class TextBox_this_windowAdapter extends WindowAdapter {
  TextBox adaptee;

  TextBox_this_windowAdapter(TextBox adaptee) {
    this.adaptee = adaptee;
  }

  public void windowClosing(WindowEvent e) {
    adaptee.this_windowClosing(e);
  }
}


Andrew Bennett wrote:

> Conrad Hoesle-Kienzlen wrote:
> >
> > Andrew,
> > but that is just the point: *not* to have to look for the parent frame. If I
> > have to look for the parent frame as that example (and others posted by you
> > and Rich)does, then I can't, of course, use a Dialog as a bean, whereas with
> > my version I can. As for the focus, I always add a this.requestFocus() after
> > the .show() of the dialog. Apart from that, I could not make out *any*
> > difference whatsoever (yet) between a dialog that was created with a
> > "parent" frame and one that was created with a new frame, in fact, I do not
> > understand why the "parent" frame (whatever that is supposed to mean) is
> > needed at all. This would mean that an object that does not make use of a
> > frame cannot instantiate a dialog at all. What's more, somewhere in the
> > documentation it says that you can set the parent frame of a dialog in the
> > object inspector. This is not true, at least everytime I tried that, I did
> > not have that choice. The frame-entry in the object inspector is a drop-down
> > list and it always only gave me the choice of <none>.
> > I would be glad if you could clarify this riddle a bit.
>
> Hrm.  I don't know about the inspector issue with setting the parent
> off the top of my head.  I'd need to play around with that.
>
> When you create and pass a new Frame in the constructor, does that new
> Frame stick around?  Say if you popped that dialog up 1000 times.  Might
> you run out of memory because you have all these Frame objects sitting around
> in the VM?
>
> A parent is needed for dialogs so that the dialog can "lock" the parent.
> Such that, say another app is brought to focus, and after a short time,
> the user throws focus back to the app that threw the dialog.  Assuming
> they clicked in the area owned by the parent but not by the dialog, the
> parent would move to the front, and the dialog would be behind it.
>
> Try experimenting with File | Open in any app that throws up a dialog when
> File is clicked.  Move focus to another app, then come back.
>
> Looking at java.awt, Dialog and Frame both descend from Window, which
> descends from Container, which descends from Component.  So, a dialog
> is really a fancy Window, and it needs a Frame (aka, a Window) to parent
> itself off of.
>
> Andrew
> --
>   Andrew Bennett
>   abennett@borland.com
>
>   Due to my workload, personal email more than likely won't get a reply.
>   Support options are detailed at http://www.borland.com/devsupport/
>   I am unable to answer support questions via email at this time.
>
>   Check http://www.borland.com/devsupport/jbuilder/ for FAQs and
>   additional JBuilder support related help.