field name for jOptionPane when using Eclipse?

[ted holden]

The standard dialog boxes in swing seem to be called JOptionPanes and they
seem to want a frame variable, which looks like it ought to be the parent
frame (the main frame of the applet in question), and I don't see an
obvious way to get at that in an Eclipse application which uses the Eclipse
guibuilder. I'd appreciate any info anyone might have.

 

[ByteCoder]

The standard dialog boxes in swing seem to be called JOptionPanes and they
seem to want a frame variable, which looks like it ought to be the parent
frame (the main frame of the applet in question), and I don't see an
obvious way to get at that in an Eclipse application which uses the Eclipse
guibuilder. I'd appreciate any info anyone might have.

IIRC you can use 'null' as a parent for an optionpane.

 

[ted holden]

IIRC you can use 'null' as a parent for an optionpane.

Thanks, that does work. I'd still be curious to know how to get a handle on
application variables like the main application frame if there's a way to
do that sort of thing...

 

[ByteCoder]

ByteCoder wrote:




Thanks, that does work. I'd still be curious to know how to get a handle on
application variables like the main application frame if there's a way to
do that sort of thing...

What do you mean with a handle?

You can handle the input the optionpane gives you when the user closes
it. Please check this:
file:///D:/Java/jdk1.5.0/docs/api/javax/swing/JOptionPane.html for more
information.

 

[ByteCoder]

What do you mean with a handle?

You can handle the input the optionpane gives you when the user closes
it. Please check this:
file:///D:/Java/jdk1.5.0/docs/api/javax/swing/JOptionPane.html for more
information.

Oops, forgot I got it on my own disk... here is the right URL:
http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/JOptionPane.html

 

[Andrew Thompson]

Oops, forgot I got it on my own disk... here is the right URL:
http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/JOptionPane.html

Don't you hate that? It just occured to me it'd be handy for the
JDoc pages to each have a 'hard' link back to the original at Sun
(in these particular situations).

 

[Chris Smith]

Thanks, that does work. I'd still be curious to know how to get a handle on
application variables like the main application frame if there's a way to
do that sort of thing...

There is no such thing as "the main application frame" in the general
case. However, if you have a reference to any AWT component, you can
use SwingUtilities.getWindowAncestor to find the top-level Window that
contains it. In some cases (such as applets, for example, when there
may not be a Java object to represent the top-level window), this might
return null. It might also return something that's not a Frame.

JOptionPane doesn't require a Frame, though. It only requires a
Component, which can be anything that's contained within the parent
Frame. It's been mentioned that you can pass null, but it's best to
pass a Component of some kind if you can. Passing null causes awkward
moments where there is no focused window after the JOptionPane is
dismissed.

It's worth mentioning that Eclipse itself uses a non-AWT GUI framework
called SWT. SWT is not a generally good idea to use in new code unless
it happens to meet some very specific requirements that you have. It's
generally an even worse idea, though, to mix SWT and AWT/Swing code if
you can avoid it. Some of the GUI-building plugins for Eclipse design
in SWT instead of AWT or Swing, and if you're doing that you should
avoid JOptionPane. If that's the case, you may not have an AWT
component anywhere. (If you insist on mixing AWT and Swing, then just
pass null for the parent.)

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[ted holden]

Many thanks!

One other thing I notice and which you might want to comment on is the
following. There seem to be several layout models in Java, and the only
one which seems to work or function at all, at least in Eclipse, is the
null layout. The others seem to be intended for use by masochists.
Further, I seem to be able to avoid all such problems by simply using swing
container classes, particularly splitters, in lieue of trying to fool
around with the various layouts. Am I missing anything?



Chris Smith wrote:

 

[Chris Smith]

One other thing I notice and which you might want to comment on is the
following. There seem to be several layout models in Java, and the only
one which seems to work or function at all, at least in Eclipse, is the
null layout. The others seem to be intended for use by masochists.
Further, I seem to be able to avoid all such problems by simply using swing
container classes, particularly splitters, in lieue of trying to fool
around with the various layouts. Am I missing anything?

Yes, you absolutely are missing something. Layout managers are there to
solve a very important and difficult problem. Though it's possible to
properly solve this problem using a null LayoutManager, the chances that
you're doing so are approximately nil. For example:

1. What happens when someone resizes your application window? If you
don't currently allow the user to resize your application window,
wouldn't it be nice if they could?

2. How certain are you that your layout will look presentable on a
different operating system (or Swing look and feel) than the one you
test one, where components may look completely different?

3. How certain are you that you could easily internationalize your
application, replacing all the text in labels, buttons, etc. with text
in a different language that may be much longer or shorter, and still
have the application look presentable? Are you comfortable with the
"make everything too big and hope it fits" technique, or would you like
something better?

4. How certain are you that your application would even be usable by
someone with serious vision problems who has set a default font size of
24 point, and can't see the screen with anything smaller?

Layout managers, in short, are critical to writing a well-designed GUI
application in Java. They are also not much harder to use than
explicitly specifying a position and size for each component; you just
have to work at a higher level. Some of the most important are
BorderLayout and FlowLayout, but GridBagLayout (the infamously difficult
layout manager) also has its uses. Some people would prefer that I say
BoxLayout instead of FlowLayout, but I'm not one of those people.

As for the difficulties in using them, you haven't given enough
information to help very much. You mentioned that you're using a GUI
builder with Eclipse; which one? It may be that the GUI builder (like
many of them do) is making layout managers more difficult than they need
to be.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Sudsy]

ted holden wrote:

Like I say, given the setup described and trying to use AWT, the layout
managers other than null simply do not appear to work or do anything
terribly useful. In fact, I would describe the behavior of the gui tool
while trying to use AWT and the flowlayout for instance, as pathalogical.
Widgets and/or panels which I try to place on the framework go to the
center top in minimized form and changing the "preferred size" produces
pathological results.

I suppose that I just don't understand your problem with layout
managers. I don't eve find GridBagLayout too onerous to use, for
example. Then again, I used to develop applications using X11/Motif
so it's not a huge leap for me...
But if you come from a M$ world were everything is drag-and-drop
in a GUI builder then I imagine that it would take time to obtain
familiarity with the various layout manager. But just out of
curiousity, how are different screen resolutions handled by the
M$ tools?

 

[Chris Smith]

I'm assuming that the server for this app will run under linux and that
99.999% of all clients will be running windows. Based on what I've seen,
I'd rather deal with any problems which come up than try to deal with java
layouts.

Do what you like. You should know, though, that use of layout managers
for Java applications is universally considered a bare minimum
requirement for writing professional quality code. Should you ever end
up writing code for someone else, they are almost certain to insist upon
it (unless they just aren't technical, in which case you could get away
with a shoddy job, I suppose).

In fact I've stitched Tcl/Tk guis together by hand using the
layout system Tk provides and I don't remember there being any unholy level
of grief doing so.

Speaking of coding stuff by hand, it's worth mentioning that a fair
number of people (myself included, actually) hold the belief that it's
actually easier to build Java GUIs by hand rather than use a visual GUI
designer. The reason is that layout managers actually give you a much
higher-level view of the GUI layout. So while a GUI builder is
necessary, for example, in Visual Basic to prevent specifying pixel
coordinates for everything, they can just get in the way in Java.

Before that's true, though, you'd need to learn how all the major layout
managers actually work. I don't know, at this point, if your problems
are with Ecplise VE, or with the layout managers you're trying to use.
I can tell you that I tried to use Eclipse VE once about six months ago.
After an extremely frustrating afternoon, I went back to coding GUIs by
hand. I might wait until the project is more mature, and then try
again.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Sudsy]

Chris Smith wrote:

Speaking of coding stuff by hand, it's worth mentioning that a fair
number of people (myself included, actually) hold the belief that it's
actually easier to build Java GUIs by hand rather than use a visual GUI
designer. The reason is that layout managers actually give you a much
higher-level view of the GUI layout. So while a GUI builder is
necessary, for example, in Visual Basic to prevent specifying pixel
coordinates for everything, they can just get in the way in Java.

Before that's true, though, you'd need to learn how all the major layout
managers actually work. I don't know, at this point, if your problems
are with Ecplise VE, or with the layout managers you're trying to use.

<snip>

I'm in complete agreement with Chris on this one. I often sketch the
layout on a piece of paper (!) first so that I can immediately see
how the pieces fit together. Then it's just a matter of coding. You
can also see whether FlowLayout will do or if you require CardLayout
or something even more sophisticated. It makes actual development go
quite quickly...
YMMV

 

[ted holden]

At this point I can't tell whether the problems with the layout managers or
with the way Eclipse and its visual editor try to use them. Nonetheless
the problems are real and the idea of trying to write java guis by hand is
a non-starter for a number of reasons. Aside from that, as I noted, the
swing components work fairly nicely and eliminate the problem, at least for
the time being.

 

[ByteCoder]

At this point I can't tell whether the problems with the layout managers or
with the way Eclipse and its visual editor try to use them. Nonetheless
the problems are real and the idea of trying to write java guis by hand is
a non-starter for a number of reasons. Aside from that, as I noted, the
swing components work fairly nicely and eliminate the problem, at least for
the time being.

I use netBeans as a GUI editor. Works very fine.