Applet frame size

[Matthijs Blaas]

Hi all!

I have some difficulties with poping up a frame from an applet... when I
create the frame and want to resize it to a different size the applet has,
it wont work. I have 3 classes:
-a class which creates the frame with the desired width and height (these
are passed through applet params), this class is called supr.java.
-a class that extends this supr class, this class is called from the html
and will draw a square in the frame called ext.java
-a class which creates and configures the frame called frm.java

I cant seem to popup the frame with my desired size, its always bounded to
the initial applet width/size, I thought an applet frame is able to override
this?

I have put the example sources online:
www.virtual-boy.org/applet/supr.java
www.virtual-boy.org/applet/ext.java
www.virtual-boy.org/applet/frm.java

www.virtual-boy.org/applet/test1.html <- this is what i'd like, have the
applet initially be 1x1 and have the frame popup with the custom
width/height
www.virtual-boy.org/applet/test2.html <- when the applet initially is set to
fx 300x300 the frame will popup with this res too...?

Thanks in advance!

Thijs

 

[Andrew Thompson]

I have some difficulties with poping up a frame from an applet...

I do not know whether to recommend the more
appropriate usenet groups, c.l.j.g or c.l.j.h
(both decribed at the link below*) or the Sun
GUI tutorial..

* <http://www.physci.org/codes/javafaq.jsp#groups>

It seems the size your frame was inheriting was
purely incidental to the Browser/VM you were
using, because the (original) frame pops up
at the size you expected in applet viewer.

In any case, here is an altered version
of parts of the code. There are some
comments along the way..
<sscce>
/* Please use the standard nomenclature used by Java
programmers, class names start with CapitalLetters. */
public class supr extends Applet
{
protected Frame f;
protected int width,height;

public void init()
{
width = Integer.parseInt(getParameter("width"));
height = Integer.parseInt(getParameter("height"));
f = new frm(width,height,this);
// show is deprecated in 1.5, make your apps. future resitant..
f.setVisible(true);
}
}

class frm extends Frame
{
Toolkit tk = Toolkit.getDefaultToolkit();
int thisWidth, thisHeight;

public frm(int width,int height, Applet app)
{
thisWidth = width;
thisHeight = height;

Toolkit tk = Toolkit.getDefaultToolkit();
Dimension screen = tk.getScreenSize();
Insets insets = getInsets();
setBounds((screen.width/2)-(width/2),(screen.height/2)-(height/2),
width+insets.left+insets.right,height+insets.bottom+insets.top);

// deprecated!
// setCursor(Frame.CROSSHAIR_CURSOR);
setResizable(false);

MenuBar menubar = new MenuBar();
Menu m1 = new Menu("Game");
MenuItem newItem = new MenuItem("New Game");

m1.add(newItem);
menubar.add(m1);
setMenuBar(menubar);
add(app);

// always a good idea..
pack();

//redundant (called from applet) and deprecated..
// show();
}

// Java does not seem to give a toss how big a
// component is, or what it's minimum or maximum size is..
// it wants to know the component's *preferred* size..
public Dimension getPreferredSize() {
return new Dimension(thisWidth, thisHeight);
}
}
</sscce>

HTH

 

[Carl Howells]

// Java does not seem to give a toss how big a
// component is, or what it's minimum or maximum size is..
// it wants to know the component's *preferred* size..

That depends entirely on the layout manager. Some layout managers care
about more than the preferred size, others don't. It *should* be
clearly documented by the layout manager which sizes it uses when, but
it rarely is.

 

[Andrew Thompson]

That depends entirely on the layout manager.

I'd need to see an example before I was convinced..

( ..But if it's GBL of which you speak, just say
so, as looking at GBL code makes my head hurt. ;-)

 

[Matthijs Blaas]

On Mon, 6 Sep 2004 23:11:36 +0200, Matthijs Blaasthijs_blaas wrote:
It seems the size your frame was inheriting was
purely incidental to the Browser/VM you were
using, because the (original) frame pops up
at the size you expected in applet viewer.

I found out the problem was caused by the width&height params... it fetched
the width&height params of the applet instead of the ones I entered,
renaming them solved it

// show is deprecated in 1.5, make your apps. future resitant..

I want to use deprecated methods because im aiming at jdk 1.1 compatibility,
including M$ jvm :-(

Anyway, thanks for your time!

 

[Carl Howells]

I'd need to see an example before I was convinced..

At one point, I wrote a layout manager that respected minimum and
maximum widths. So it's clearly possible. I don't know if *any* of the
builtin layout managers do. I can find the source for it (I actually
posted it to either this group or c.l.j.g at some point in the past,
under the name ExpansionLayout), if you want me to.

 

[Andrew Thompson]

setVisible(true);

I want to use deprecated methods because im aiming at jdk 1.1 compatibility,
including M$ jvm :-(

You have not read the JavaDocs carefully..
What does this say under 'Since'?
<http://java.sun.com/j2se/1.4.2/docs/api/java/awt/Component.html#setVisible(boolean)>

 

[Andrew Thompson]

At one point, I wrote a layout manager that respected minimum and
maximum widths. So it's clearly possible.

Won't dispute that, I was referring to
the layouts in the core API.

Thanks for clarifying.

( Actually.. after I wrote that I realised
that there are situations where even
preferredSize is completely ignored,
BorderLayout.CENTER, for instance, my
point was that if the core Java layouts
respected *any* size, it was the preferredSize )

 

[Matthijs Blaas]

You have not read the JavaDocs carefully..

What does this say under 'Since'?

<http://java.sun.com/j2se/1.4.2/docs/api/java/awt/Component.html#setVisible(
boolean)>

Whoops... thanks for pointing that out!
Never really bothered fixing deprecation warnings before... sun wouldn't
drop support for them in future jvm's wont they? As that would break
compatibility... sure must be some reason why they're not recommed to use
;-)

 

[Andrew Thompson]

Never really bothered fixing deprecation warnings before... sun wouldn't
drop support for them in future jvm's wont they?

That is what the 'deprecated' flag actually
indicates.. (removal in future)

..As that would break
compatibility...

Which is why ..
a) They warn us with a big, friendly,
'deprecated' warning on compile.
b) They will leave it a long time before
they actually do remove the method.

..sure must be some reason why they're not recommed to use

See above. You can be much more confident
that setVisible(true)* will still be around
in Java 1.6, ..2.7, 3.4, than show()..

* Which, contrary to something I heard
the other day, has been part of Java
since 1.1.

Think about it, both show() and setVisible(true)
are valid back to 1.1, but Sun is warning us
to stop using show(). So which one makes
more sense?

 

[Andrew Thompson]

* Which, contrary to something I heard
the other day, has been part of Java
since 1.1.

LOL.. Right here in this conversation,
as it happens! No wonder it was still
fresh in my (addled) brain. ;-)