Java Help

Author

OOP

A.Tamboer

2005-11-18, 7:57 am

Hi from a newbe.

I have read some articles over Java and that took my interest. I have bought
a number of books and works out the samples. My ages is 73 and I have
experience with macros etc in spread sheets and have done some work in
Clipper in the good old DOS days. (Train your brains)

In Java I have a (small?) problem. In an Applet I have two buttons. When I
push button 1 the background color of the button changes. No problem. When I
after that push button 2, button 1 must go back to the original background
color. I try to save the original background color on the following way;

<button1.getBackground()> this gives a color object. From this color object
I will save the colors Red, Green and Blue so these can be used to set back
the old background color, on the next way;

<int x = (button1.getBackground()).getRed()> for Red, but this don't works.
I get a null pointer exception (InvocationTargetExption) and I don't
understand this. I have used a debugger, looked a number of books but it
doesn't help me.

Maybe there are better solutions and I have interest in these, but for me is
important to understand why I not get the <int x>.

Thanks for help Arie Tamboer

a.tamboer@home.nl

Andrew Thompson

2005-11-18, 7:57 am

A.Tamboer wrote:

> Hi from a newbe.
...
> In Java I have a (small?) problem. In an Applet ..

Applets (or GUI'd applications) are not the best things for
Java newbe to start with.
<http://www.physci.org/codes/javafaq.jsp#appfirst>

> Maybe there are better solutions and I have interest in these, but for me is
> important to understand why I not get the <int x>.

To understand why you are not getting the int, I would need
to see the SSCCE* and applet web page (URL).
* <http://www.physci.org/codes/sscce.jsp>

--
Andrew Thompson
physci, javasaver, 1point1c, lensescapes - athompson.info/andrew
Currently accepting short and long term contracts - on Earth.

Roedy Green

2005-11-18, 7:57 am

On Fri, 18 Nov 2005 11:37:00 +0100, "A.Tamboer" <a.tamboer@home.nl>
wrote, quoted or indirectly quoted someone who said :

><button1.getBackground()> this gives a color object. From this color object
>I will save the colors Red, Green and Blue so these can be used to set back
>the old background color, on the next way;

It would be simpler to do it this way:

Color oldBackground = button1.getBackground();

It may be you are trying to get these inherited values before they
have been defined by realisation.

Don't call this until addNotify has been called. You might put this
code in addNotify. see http://mindprod.com/jgloss/addnotify.html

But an easier way to do it would be like this:

private static final Color DEFAULT_BACKGROUND = new Color(0x999999);
private static final Color SPECIAL_BACKGROUND = new Color (0xaaaaaa);

Then you can say either:

button1.setBackground( DEFAULT_BACKGROUND );

or

button1.setBackground( SPECIAL_BACKGROUND );

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Roedy Green

2005-11-18, 7:03 pm

On Fri, 18 Nov 2005 11:57:23 GMT, Roedy Green
<my_email_is_posted_on_my_website@munged.invalid> wrote, quoted or
indirectly quoted someone who said :

>Color oldBackground = button1.getBackground();

and restore with button1.setBackground( oldBackground );

There is no need to split the Color object up into rgb.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Thomas G. Marshall

2005-11-20, 7:01 pm

Roedy Green said something like:

....[rip]...

> Don't call this until addNotify has been called. You might put this
> code in addNotify. see http://mindprod.com/jgloss/addnotify.html

[OP, perhaps ignore this:]

I'm not sure that your explanation of addNotify() on that page is clear
enough.

The useful point to newbies of addNotify() is that it is called (both in the
AWT and Swing case) once the component is added to some parent object. Your
explanation from the AWT Component():

Makes this Component displayable by
connecting it to a native screen resource.
This method is called internally by the
toolkit and should not be called directly
by programs.

Doesn't IMHO make it clear how it is useful, that you can override it to add
code that is only safe once the component is added properly. That this is
the point at which the connection is made to the peer (in the AWT case) is
more of a gritty detail. Just a suggestion, but perhaps you should lead off
with the JComponent explanation:

Notifies this component that it now has
a parent component. [...]

{shrug}, Whatever.

....[rip]...

--
Enough is enough. It is /not/ a requirement that someone must google
relentlessly for an answer before posting in usenet. Newsgroups are for
discussions. Discussions do /not/ necessitate prior research. If you are
bothered by someone asking a question without taking time to look something
up, simply do not respond.

Roedy Green

2005-11-20, 7:01 pm

On Sun, 20 Nov 2005 17:15:03 GMT, "Thomas G. Marshall"
< tgm2tothe10thpower@replacetextwithnumber
.hotmail.com> wrote, quoted
or indirectly quoted someone who said :

>
>The useful point to newbies of addNotify() is that it is called (both in the
>AWT and Swing case) once the component is added to some parent object. Your
>explanation from the AWT Component():
>
> Makes this Component displayable by
> connecting it to a native screen resource.
> This method is called internally by the
> toolkit and should not be called directly
> by programs.
>
>Doesn't IMHO make it clear how it is useful, that you can override it to add
>code that is only safe once the component is added properly. That this is
>the point at which the connection is made to the peer (in the AWT case) is
>more of a gritty detail. Just a suggestion, but perhaps you should lead off
>with the JComponent explanation:
>
> Notifies this component that it now has
> a parent component. [...]

That is not what addNotify means. I will try again to see if I can
make the explanation clearer.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Roedy Green

2005-11-20, 7:01 pm

Thomas G. Marshall

2005-11-21, 3:59 am

Roedy Green said something like:
> On Sun, 20 Nov 2005 17:15:03 GMT, "Thomas G. Marshall"
> < tgm2tothe10thpower@replacetextwithnumber
.hotmail.com> wrote, quoted
> or indirectly quoted someone who said :
>
>
> addNotify does not get called as a side effect of add.

I didn't say it was a "side effect", but it certainly is a consequence of
having a parent. See below.

> It happens
> later when you call pack or setVisible(true) for the first time.
>
> See my new explanation. See if that makes it any clearer.
>
> http://mindprod.com/jgloss/addnotify.html

We're still in disagreement. This new explanation of yours here:

Some initialisation code requires the Component
to be realised/displayable before it will work. Realised,
sometimes called displayable, means that there exists
a corresponding native peer GUI object created and
hooked up to your Component. In other words, your
Component is either already visible or all set to be
displayed. It does not mean "has a parent" or "is visible".

Does better, but it /does/ mean "has a parent". You cannot have a component
displayable if it is not inside a parent. Can't be done. You /cannot/, for
example, have a button floating in space.

Overriding addNotify() gives you the perfect spot to be able to introduce
code that needs to rely on the fact that the component has already been
added to a parent and is ready.

This explanation of yours here:

The AWT/Swing toolkit calls addNotify to create/hook
up the peer object. You can thus override the addNotify
method, so that when super. addNotify returns, you know
your peer is ready to go.

This IMO is /still/ misleading. Swing does not call addNotify to hook up a
peer object, /only/ the AWT understands the notion of peers. From swing's
point of view, it's again, a perfect place for code that needs to happen
after it has a parent. It is a detail that from some high level component
in swing that it's parent's parent ('s parent's parent?) needs to hook up to
a peer. Here's the code for JComponet's addNotify(). Note the comment.

--------[1.5 (JComponent).addNotify()]--------
/**
* Notifies this component that it now has a parent component.
* When this method is invoked, the chain of parent components is
* set up with <code>KeyboardAction</code> event listeners.
*
* @see #registerKeyboardAction
*/
public void addNotify() {
super.addNotify();
firePropertyChange("ancestor", null, getParent());

registerWithKeyboardManager(false);
registerNextFocusableComponent();
}

Now that I think about it, I think our disagreement might stem from what we
each hear in the phrase "has a parent".

--
"Realtor" and "realty" are pronounced "reel'-tor" and
"reel'-tee", *not* "reel'-a-tor" and "reel'-i-tee" !!!!
If you pronounce them with the extra syllable, you will
sound like a complete idiot.

Roedy Green

2005-11-21, 3:59 am

On Mon, 21 Nov 2005 04:14:31 GMT, "Thomas G. Marshall"
< tgm2tothe10thpower@replacetextwithnumber
.hotmail.com> wrote, quoted
or indirectly quoted someone who said :

>Does better, but it /does/ mean "has a parent". You cannot have a component
>displayable if it is not inside a parent. Can't be done. You /cannot/, for
>example, have a button floating in space.

Consider Frame.addNotify defined as "Makes this Frame displayable by
connecting it to a native screen resource.".
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Thomas G. Marshall

2005-11-21, 7:58 am

Roedy Green said something like:
> On Mon, 21 Nov 2005 04:14:31 GMT, "Thomas G. Marshall"
> < tgm2tothe10thpower@replacetextwithnumber
.hotmail.com> wrote, quoted
> or indirectly quoted someone who said :
>
>
> Consider Frame.addNotify defined as "Makes this Frame displayable by
> connecting it to a native screen resource.".

Frame is /not/ a component. It is /always/ in need of a peer even in swing.
I'm not saying that addNotify() doesn't do what you say it does. Peer
connectivity /is/ the name of the game there in the AWT. I'm saying is that
you missed the point of being able to override it in both AWT and swing, and
/particularly/ in swing.

I do have to admit though, that it has been a number of years since I was in
the awt source.

This is best handled in c.l.j.gui. I'll see you there if you like. Start a
new thread, or I will (do not cross post this one, it is too misdirected
already). I'd like to see what those who are emmersed in nothing but the
java gui source have to say. Ought to be interesting, one way or another.
:)

--
http://www.allexperts.com is a nifty way to get an answer to just about
/anything/.

Roedy Green

2005-11-21, 7:02 pm

On Mon, 21 Nov 2005 13:45:47 GMT, "Thomas G. Marshall"
< tgm2tothe10thpower@replacetextwithnumber
.hotmail.com> wrote, quoted
or indirectly quoted someone who said :

>Frame is /not/ a component.

the class hierarchy is:

java.lang.Object
java.awt.Component
java.awt.Container
java.awt.Window
java.awt.Frame

see http://java.sun.com/j2se/1.5.0/docs.../awt/Frame.html
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Thomas G. Marshall

2005-11-21, 7:02 pm

Roedy Green said something like:
> On Mon, 21 Nov 2005 13:45:47 GMT, "Thomas G. Marshall"
> < tgm2tothe10thpower@replacetextwithnumber
.hotmail.com> wrote, quoted
> or indirectly quoted someone who said :
>
>
> the class hierarchy is:
>
> java.lang.Object
> java.awt.Component
> java.awt.Container
> java.awt.Window
> java.awt.Frame
>
> see http://java.sun.com/j2se/1.5.0/docs.../awt/Frame.html

No no no no no no no. DAMMIT, I /should/ not have used that word.

The word component is with a lower case c. It is meant in the general
definition case, which would mean "addable component" here. Frame (while a
Component) is not a component (a "thing") that you can add to other
containers. Frame cannot be an [english] component of anything: it is at
the top.

As such, Frame is the oddity of the term displayable in that it is at the
top of the containment hierarchy. It can be made displayable without any
hierarchy around it at all because it is by definition displayable.

Let's move to a description within Component (isDisplayable()). It's likely
partly what you used to describe displayable for addNotify(). I'll
intersperse:

<quote>
public boolean isDisplayable()
Determines whether this component is displayable.
A component is displayable when it is connected to
a native screen resource.
</quote>

The above is your statement. I find it incomplete, only in that it lacks
the greater point I've been describing.

<continuing quote>
A component is made displayable either when it is
added to a displayable containment hierarchy or
when its containment hierarchy is made displayable.
</continuing>

The above is the rub! addNotify() allows you to assume this:

that 1. it has been added to something already
displayable, (that it has a valid parent)

or 2. it was previously has been added to a hierarchy
that was not displayable and has just been made
displayable. (that it has a valid parent)

<continuing quote>
A containment hierarchy is made displayable when
its ancestor window is either packed or made visible.
[...]
</continuing---quote done>

The above is what you've made clear also.

Ok, here's what I think happened. When I use the term /parent/, I am not
using it to mean just a container that something was added to. I am using
it to mean something added to, but that is ready to go, *JUST LIKE*
JComponent.addNotify() does (in it's comment). I have to concede that the
term parent simply means thing contained regardless of displayable status,
so it explains why would think I (and JComponent) are using the wrong term
when I (we) say parent.

getParent() for example, returns the container regardless of displayability.
So perhaps I should have made that more clear. In any case, IMO it is what
is useful about overriding addNotify().

Does this cover why we're talking past each other?

--
Onedoctortoanother:" Ifthisismyrectalthermometer,wherethehell
'smypen???"

Roedy Green

2005-11-21, 7:02 pm

On Mon, 21 Nov 2005 21:33:56 GMT, "Thomas G. Marshall"
< tgm2tothe10thpower@replacetextwithnumber
.hotmail.com> wrote, quoted
or indirectly quoted someone who said :

>
>that 1. it has been added to something already
> displayable, (that it has a valid parent)

consider this code for Component.isDisplayable:

public boolean isDisplayable() {
return getPeer() != null;
}

Displayable means quite literally "has been assigned a peer" --
possibly a "LightweightPeer". It has nothing to do with adding and
only indirectly to having a parent. It may have been associated with
adding in the dark past, hence the name addNotify, but it no longer
has any association with adding to Containers.

See Component.addNotify for how the peer gets created.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Thomas G. Marshall

2005-11-21, 7:02 pm

Roedy Green said something like:
> On Mon, 21 Nov 2005 21:33:56 GMT, "Thomas G. Marshall"
> < tgm2tothe10thpower@replacetextwithnumber
.hotmail.com> wrote, quoted
> or indirectly quoted someone who said :
>
>
> consider this code for Component.isDisplayable:
>
> public boolean isDisplayable() {
> return getPeer() != null;
> }
>
>
> Displayable means quite literally "has been assigned a peer" --

But I'm not disputing that. You just entirely snipped away the comment
description of *how* a component is *made* displayable. It is there that
the discussion of container hierarchy matters. It is the notion of that
hierarchy that you can depend upon when you override addNotify().

> possibly a "LightweightPeer". It has nothing to do with adding and
> only indirectly to having a parent. It may have been associated with
> adding in the dark past, hence the name addNotify, but it no longer
> has any association with adding to Containers.

If it even *indirectly* has to do with having a parent then it has an
association with adding to containers.

> See Component.addNotify for how the peer gets created.

I know that code already. I'm sorry that I cannot explain this better.
Either way, from my point of view, we're done.

--
"It's easier to be terrified by an enemy you admire."
-Thufir Hawat, Mentat and Master of Assassins to House Atreides

Sponsored Links