Can someone use invokeLater() to call a public method from a JPanel?

[***C.Steamer***]

Basically I want the application to call invokeLater() to update the view of
the gui. This is for a simple card game.I want to call a public method
called updateHand(Hand hand) which I pass in a hand then it clears the items
in the JPanel and adds a Label representing each of the cards to the Jpanel.
For some reason if I call this method from the constructor of the JPanel but
the invoke method doesn't work. This is my code in the application layer.
Any suggestions why this isin't working?

private void updateScreen1()
{
Runnable updateScreen = new Runnable()
{
public void run()
{

Hand handTest = new Hand();
handTest.addCard(new Card(1,1));
handTest.addCard(new Card(2,1));
handTest.addCard(new Card(3,1));
handTest.addCard(new Card(4,1));
handTest.addCard(new Card(5,1));

mainPanel.updateHand(handTest);

}
};

SwingUtilities.invokeLater(updateScreen);
}


And the actual method in my main panel is as follows.Note that handPanel is
just a panel I added in my mainPanel which is an extension of JPanel



public void updateHand(Hand hand)
{
handPanel.removeAll();

for(int i =0;i<hand.getNumCards();i++)
{
CardLabel cardLabel = new CardLabel(hand.getCard(i));
handPanel.add(cardLabel);
cardLabel.addMouseListener(this);
}
handPanel.repaint();

}

 

[Alex Hunsley]

Basically I want the application to call invokeLater() to update the view of
the gui. This is for a simple card game.I want to call a public method
called updateHand(Hand hand) which I pass in a hand then it clears the items
in the JPanel and adds a Label representing each of the cards to the Jpanel.
For some reason if I call this method from the constructor of the JPanel but
the invoke method doesn't work. This is my code in the application layer.
Any suggestions why this isin't working?

For a start, post complete, compilable, working code that demonstrates
the problem. Snippets aren't much use.

Secondly - you are calling something from the constructor of JPanel, you
say? How do you mean? Have you edited/recompiled the JPanel source; or
overridden JPanel, or what? Anyway, sounds like you're suffering
Constructoritis, the disease of doing far too much in constructors.
Constructors should do very little - store passed in values, usually;
constructors should *not* call non-final or non-private methods, and
constructors shouldn't be doing GUI related things. Factor out that
stuff into other method(s) that you call after the Constructor has done
its stuff. Doing this may solve your problems.

alex

 

[***C.Steamer***]

Yeah thanks for nothing dude, If you don't have anything useful to add don't
say anything.

 

[Paul Tomblin]

Yeah thanks for nothing dude, If you don't have anything useful to add don't
say anything.

It looked like a pretty useful answer to me. But if that's not what you
want, don't be surprised if you don't get any answers.

 

[Thomas G. Marshall]

Alex Hunsley coughed up:

....[thwack]...

Anyway, sounds like you're
suffering Constructoritis, the disease of doing far too much in
constructors.

Perhaps. Seen it many times.

Constructors should do very little - store passed in
values, usually; constructors should *not* call non-final or
non-private methods

Overly strict. I cannot /count/ the number of times I've seen horribly
convoluted code set out to avoid putting nearly /anything/ into a
constructor. You need limits of course, but you need to weigh that against
the often /severe/ readability/maintainability/pollution cost of doing it
"the right way".

, and constructors shouldn't be doing GUI related
things.

Constructors of GUI descendents should, and are often best designed when
they do.

Factor out that stuff into other method(s) that you call
after the Constructor has done its stuff. Doing this may solve your
problems.

Possibly true.

 

[Tor Iver Wilhelmsen]

Yeah thanks for nothing dude, If you don't have anything useful to
add don't say anything.

Top-posting a snide remark like that in a follow-up to a post that DID
have something useful is a quick way to be added to people's
kill-files.

 

[Alex Hunsley]

Alex Hunsley coughed up:

...[thwack]...

Anyway, sounds like you're
suffering Constructoritis, the disease of doing far too much in
constructors.

Perhaps. Seen it many times.

Constructors should do very little - store passed in
values, usually; constructors should *not* call non-final or
non-private methods

Overly strict. I cannot /count/ the number of times I've seen horribly
convoluted code set out to avoid putting nearly /anything/ into a
constructor.

"Constructors should *not* call non-final or
non-private methods" is not overly strict - it's actually a very good
idea. Otherwise, you can get into some very strange problems, due to way
the order in which JVM intialises class members and calls super etc. -
I've seen these problems first hand and I've seen people waste *ages* on
them because they didn't know what was happenig. (It's not obvious if
you don't know about the thing I'm talking about above.)

You need limits of course, but you need to weigh that against
the often /severe/ readability/maintainability/pollution cost of doing
it "the right way".

I don't see how "often severe" problems can arise as a result of not
having so much code in the constructor, and having mode code in other
(well named) methods, which makes things more explicit. Do you have any
solid-ish examples of that?

Constructors of GUI descendents should, and are often best designed when
they do.

Obviously, that is a good exception. I thought of that when I posted but
I thought it too obvious to put in.

 

[Alex Hunsley]

Yeah thanks for nothing dude, If you don't have anything useful to add don't
say anything.

Don't top post. It makes threads hard to follow.

Thanks for nothing? How about "thanks for the advice in your post about
how to maybe fix my code"? Did you somehow completely miss the parts of
my post where I gave advice?

Hmm, let's go over my post and examine each bit and see if there is
anything useful there.

For a start, post complete, compilable, working code that demonstrates
the problem. Snippets aren't much use.

This is very useful advice - how to enable to help you more easily. So
you obviously missed this part of my post.

Secondly - you are calling something from the constructor of JPanel,
you say? How do you mean? Have you edited/recompiled the JPanel

source; >or overridden JPanel, or what?

Asking you for more information about something unclear in your original
post, so that we can understand more and help you more easily. Something
else which is useful, to us and to you. So you obviously missed this
part of my post.

Anyway, sounds like you're suffering Constructoritis, the disease of
doing far too much in constructors. Constructors should do very little
- store passed in values, usually; constructors should *not* call
non-final or non-private methods, and constructors shouldn't be doing
GUI related things. Factor out that stuff into other method(s) that

you >call after the Constructor has done its stuff. Doing this may solve

your problems.

And again, more useful info: a suggestion about what may be the problem,
along with hints about how to avoid that problem. So you obviously
missed this part of my post.

So, from your very strange claims of me being no help, it would appear
you missed all of my post. Did you actually read my post, or someone
elses? Perhaps you're having problems with your newsreader software?

Ok, let's turn this on its head, just to see exactly what is your beef:
show me a *single sentence* from my reply that *didn't* contain some
useful advice or information about how we could help you more. (Hint:
you can't.)

One last question: in which way is it smart to alienate the people who
are trying to help you?

alex

 

[Thomas G. Marshall]

Alex Hunsley coughed up:

....[rip]...

"Constructors should *not* call non-final or
non-private methods" is not overly strict

STOP RIGHT THERE.

You meant: should *not* call non-final or non-private methods of that same
object? Sorry, I misunderstood your intent.

Then I totally agree.

Here's something else I see *all the time*: (pseudo-java, ignore scoping
rules):

class A
{
A() { helper(); }

helper() {....};
}

class B extends A
{
helper() {....}; // dangerous: overridden
}


....[rip]...

 

[Thomas G. Marshall]

Alex Hunsley coughed up:

....[rip]...

One last question: in which way is it smart to alienate the people who
are trying to help you?

You were helpful.

However, to the side of your reply, I am sensing a growing sense of rudeness
in the replies in programming ng's. It sometimes takes the following form:

OP: humble question, please, I'm humble
RP: this is a horrible idea, and do your research better
OP: that is rude!

I think it may have something to do with the relatively recent rush of
students to the ng's asking for their homework to be completed for them, and
that /that/ is tiring for the frequent contributors to deal with over and
over. But there seems to be something more here, and I haven't yet put my
finger on it.

Again, this is to the side of your post. It's just an observation in
general that I've made.

{shrug} YMMV.

 

[Mark Thornton]

***C.Steamer*** wrote:

overridden JPanel, or what? Anyway, sounds like you're suffering
Constructoritis, the disease of doing far too much in constructors.
Constructors should do very little - store passed in values, usually;
constructors should *not* call non-final or non-private methods, and
constructors shouldn't be doing GUI related things. Factor out that
stuff into other method(s) that you call after the Constructor has done
its stuff.

I agree with Thomas Marshall that your prescription is overly strict.
The style of doing almost nothing in constructors is necessary in C++
where the consequences of throwing an exception during a constructor are
poorly defined. By contrast in Java, this represents no problem, and the
order in in which construction takes place is also well defined. Yes it
is true that some people have been surprised by the fact that if a
constructor uses a method which has been overridden in a child class,
then unlike in C++ it is the child's version which is used.

For me the sign of constructor problems is where you end up with a large
number of constructors with different combinations of arguments. In this
case it is usually better to have a simple constructor followed by
subsequent calls to set all the properties as required (unless of course
you want an immutable object).

Mark Thornton

 

[Thomas G. Marshall]

Mark Thornton coughed up:

I agree with Thomas Marshall that your prescription is overly strict.
The style of doing almost nothing in constructors is necessary in C++
where the consequences of throwing an exception during a constructor
are poorly defined. By contrast in Java, this represents no problem,
and the order in in which construction takes place is also well
defined. Yes it is true that some people have been surprised by the
fact that if a constructor uses a method which has been overridden in
a child class, then unlike in C++ it is the child's version which is
used.

....which is a disaster waiting to happen, because it can allow a superclass
to access something that has not yet been initialized in the subclass.

I personally do not like the fact that java allows a constructor helper
method to be overridden in the first place---I believe that to be a mistake.

For me the sign of constructor problems is where you end up with a
large number of constructors with different combinations of
arguments. In this case it is usually better to have a simple
constructor followed by subsequent calls to set all the properties as
required (unless of course you want an immutable object).

Mark Thornton

Thank you for the agreement. Again, I'm still not sure what he meant by it.
In the case of wanting to avoid public methods of itself, I am up for
veering away from it if you can. But the notion of not allowing a
constructor to call /any/ public methods /anywhere/ is just over the top in
my opinion.

 

[Mark Thornton]

Mark Thornton coughed up:



....which is a disaster waiting to happen, because it can allow a superclass
to access something that has not yet been initialized in the subclass.

Remember of course that Java's default initialisation (to zero/null) has
occurred, so the consequences are well defined.

Mark Thornton

 

[steve]

I suspect it Is working, but that you GUI has not been fully rendered, so you
are updating something that cannot be seen yet,then the changes are being
over written.

For a start, post complete, compilable, working code that demonstrates
the problem. Snippets aren't much use.

Secondly - you are calling something from the constructor of JPanel, you
say? How do you mean? Have you edited/recompiled the JPanel source; or
overridden JPanel, or what? Anyway, sounds like you're suffering
Constructoritis, the disease of doing far too much in constructors.
Constructors should do very little - store passed in values, usually;
constructors should *not* call non-final or non-private methods, and
constructors shouldn't be doing GUI related things. Factor out that
stuff into other method(s) that you call after the Constructor has done
its stuff. Doing this may solve your problems.

alex

so Alex , where should we draw the GUI? , because i am also extending the
JPanel deff, then calling the GUI setup stuff in the constructor.


as in:

public personDet(){
try {
if (!initialized) {
jbInit(); // call the stuff to setup & draw the GUI
}

initialized = true;
} catch (Exception e) {
Error_stuff.handleError(e, EXEPTION_ERROR, -1);
}
}

I was doing:

public void addNotify() {
super.addNotify();

try {
if (!initialized) {
jbInit(); // call the stuff to setup & draw the GUI
}

initialized = true;
} catch (Exception e) {
Error_stuff.handleError(e, EXEPTION_ERROR, -1);
}
}

but that "addNotify() " created the strangest bug i had ever seen!!.
That one took days to find.

 

[Thomas G. Marshall]

Mark Thornton coughed up:

Remember of course that Java's default initialisation (to zero/null)
has occurred, so the consequences are well defined.

Still a disaster. It has to do with whether or not your code can actually
/use/ a member variable or not as you see it initialized. You're right in
that it sure is gonna be zero/null. But that can be a huge source of a
fairly opaque bug.

You know this, but here's the example:

Output:
---> run experiments.simple.BadIdea
B.helper()
B.y=0

package experiments.simple;

class A
{
A()
{
helper();
}

void helper()
{
System.out.println("A.helper()");
System.out.println("A.x="+x);
}

int x=5;
}


class B extends A
{
void helper()
{
System.out.println("B.helper()");
System.out.println("B.y="+y); // ain't gonna see 6.
}

int y=6;
}


public class BadIdea
{
public static void main (String[] args)
{
B b = new B();
}
}

 

[Andrew Thompson]

...because i am also extending the
JPanel deff, then calling the GUI setup stuff in the constructor.


as in:

public personDet(){

I will expand upon something mentioned in this conversation.

A compileable example (is much more useful than descriptions and snippets)
<http://www.physci.org/codes/sscce.jsp>

 

[Alex Hunsley]

I suspect it Is working, but that you GUI has not been fully rendered, so you
are updating something that cannot be seen yet,then the changes are being
over written.





so Alex , where should we draw the GUI? , because i am also extending the
JPanel deff, then calling the GUI setup stuff in the constructor.

Btw, it's not good style to extend JPanel in most cases. If you
genuinely *are* extending JPanel (I mean in the design of your
software), then have a class extend JPanel; if, however, your
application just *has* a JPanel and wants to use it, don't extend: just
use a JPanel.
Think of it as the difference between "is a" and "uses a".
Another way of thinking about it: if you want to make a single String,
you don't override the String class, do you? You just make a new string
using existing methods/constructors.

alex

 

[Alex Hunsley]

Remember of course that Java's default initialisation (to zero/null) has
occurred, so the consequences are well defined.

Consequences are irrelevent here; I'm concerned with well-written
understandable code that doesn't rely of knowledge of surprising aspects
of the system. And no matter how well *you* might understand, and cope
with, oddities of the compiler/runtime, someone else may some day be
looking at your code, and be less well versed in the ins and outs of the
compiler/runtime.

 

[Alex Hunsley]

Alex Hunsley coughed up:

...[rip]...

"Constructors should *not* call non-final or
non-private methods" is not overly strict

STOP RIGHT THERE.

Please don't shout, it's considered rude.

You meant: should *not* call non-final or non-private methods of that same
object? Sorry, I misunderstood your intent.

well, if I didn't mean that, then I would be talking about calling
private methods of *other classes* which wouldn't make any sense. So
yes, I meant of that same object, sorry if I wasn't clear on that.

Then I totally agree.

Here's something else I see *all the time*: (pseudo-java, ignore scoping
rules):

class A
{
A() { helper(); }

helper() {....};
}

class B extends A
{
helper() {....}; // dangerous: overridden
}

Yup, I see that too. I see dead people.

 

[Alex Hunsley]

I agree with Thomas Marshall that your prescription is overly strict.
The style of doing almost nothing in constructors is necessary in C++
where the consequences of throwing an exception during a constructor are
poorly defined.

I think my erring on the side of not putting a lot in constructors stems
from the amount of times I have seen too much in constructors, and the
problems created therein. I am just very wary of what can happen.