I need a different approach - suggestions please

[Arne Vajhøj]

markspace wrote:
bilsch wrote:
Many things are because I mimic what I see in other programs... I
hope I can finish this project without understanding threads


Yeah, that's an issue. When teaching someone, is it better to let them
do it the simplest, but wrong, way? Or should you teach them to write
code they don't understand, but promise too "explain it later?"

I'm actually in the latter camp at the moment. I'd rather see you copy
and paste good code, than let you get into the habit of writing bad code
that you feel you understand. It a style of learning thing, more than a
programming thing, but I think it's better to get you into the habit of
looking at correct code now, so it doesn't seem strange when you see the
correct version later.

OTOH, it's not going to adversely effect your small programs. The
chance of you hitting a threading error in such a small program is
virtually nil. Just be aware that: 1. the code really is wrong, and 2.
you'll have to learn threads eventually.

They've already hit a threading error.

How is that "virtually nil" chance?

Usually "hit [by] an error" means actually impacted by the error.

I did not see any case of such.

Have you run the OP's code?

On a multi-processor system?

I had not.

Now I have.

I expect OP to have too.

The chance of actually getting a problem by starting
the GUI in main thread instead of event thread is pretty
small.

Otherwise the wrong way of doing it would not have
been used for so many years.

Arne

 

[Lew]

Lew wrote:
markspace wrote:
bilsch wrote:
Many things are because I mimic what I see in other programs... I
hope I can finish this project without understanding threads


Yeah, that's an issue. When teaching someone, is it better to let them
do it the simplest, but wrong, way? Or should you teach them to write
code they don't understand, but promise too "explain it later?"

I'm actually in the latter camp at the moment. I'd rather see you copy
and paste good code, than let you get into the habit of writing bad code
that you feel you understand. It a style of learning thing, more than a
programming thing, but I think it's better to get you into the habit of
looking at correct code now, so it doesn't seem strange when you see the
correct version later.

OTOH, it's not going to adversely effect your small programs. The
chance of you hitting a threading error in such a small program is
virtually nil. Just be aware that: 1. the code really is wrong, and 2.
you'll have to learn threads eventually.

They've already hit a threading error.

How is that "virtually nil" chance?

Usually "hit [by] an error" means actually impacted by the error.

I did not see any case of such.

Have you run the OP's code?

On a multi-processor system?

I had not.

Now I have.

I expect OP to have too.

The chance of actually getting a problem by starting
the GUI in main thread instead of event thread is pretty
small.

Otherwise the wrong way of doing it would not have
been used for so many years.

Not so. Those many years, Swing programs were running on single-
processor machines for the most part. Cache coherency and such
issues were non-existent. Nowadays many machines are multi-processor
and thread bugs are more likely to be visible.

If it were so safe, then it wouldn't be "the wrong way of doing it".

You are expressing the great bad approach to the concurrency problem:
"I don't see a problem in the last two or three times I ran the program,
therefore there is no problem."

This is the attitude that foments so many concurrency bugs.

Concurrency bugs by nature are intermittent, unpredictable and
inconsistent. Your test proves nothing except that you have fallen into
a classic trap.

OP: Don't learn the wrong way. Learn the right way. The fact you don't
see a bug in the first two or dozen times you run the program means
nothing with concurrency issues.

Rule for Swing: DO GUI ACTIONS ONLY ON THE EDT!

That's that.

 

[Lew]

That is your religion.

Bullshit. That is my observation.

The Java Coding Conventions have been in play since 1999. I have
worked in many Java shops. All had coding standards. Mostly they
adhere to the official conventions, but all accepted or required certain
slight variations, pretty much consistently from one to the next.

Why would you say such a thing?

 

[Arne Vajhøj]

Arne Vajhøj wrote:
Lew wrote:
markspace wrote:
bilsch wrote:
Many things are because I mimic what I see in other programs... I
hope I can finish this project without understanding threads


Yeah, that's an issue. When teaching someone, is it better to let them
do it the simplest, but wrong, way? Or should you teach them to write
code they don't understand, but promise too "explain it later?"

I'm actually in the latter camp at the moment. I'd rather see you copy
and paste good code, than let you get into the habit of writing bad code
that you feel you understand. It a style of learning thing, more than a
programming thing, but I think it's better to get you into the habit of
looking at correct code now, so it doesn't seem strange when you see the
correct version later.

OTOH, it's not going to adversely effect your small programs. The
chance of you hitting a threading error in such a small program is
virtually nil. Just be aware that: 1. the code really is wrong, and 2.
you'll have to learn threads eventually.

They've already hit a threading error.

How is that "virtually nil" chance?

Usually "hit [by] an error" means actually impacted by the error.

I did not see any case of such.

Have you run the OP's code?

On a multi-processor system?

I had not.

Now I have.

I expect OP to have too.

The chance of actually getting a problem by starting
the GUI in main thread instead of event thread is pretty
small.

Otherwise the wrong way of doing it would not have
been used for so many years.

Not so. Those many years, Swing programs were running on single-
processor machines for the most part. Cache coherency and such
issues were non-existent. Nowadays many machines are multi-processor
and thread bugs are more likely to be visible.

If it were so safe, then it wouldn't be "the wrong way of doing it".

You are expressing the great bad approach to the concurrency problem:
"I don't see a problem in the last two or three times I ran the program,
therefore there is no problem."

This is the attitude that foments so many concurrency bugs.

Concurrency bugs by nature are intermittent, unpredictable and
inconsistent. Your test proves nothing except that you have fallen into
a classic trap.

????

I pointed out that you were wrong in claiming that OP had
already been hit by the error.

There were no indication that he had in host post. And
in fact the likelihood of being hit by problem even on multi
core is pretty slim.

I did not suggest that OP should ignore the problem.

I did not suggest that running the code with no problem meant
that the code was OK.

In fact it was you that suggested running the code.

So if there is somebody here that believes running the
code without problems indicates something then it must be you.

Arne

 

[Arne Vajhøj]

That is your religion.

It is the recommendation from the inventors of the language.

And it is by far the most widely used coding convention from Java.

Facts not religion.

Arne

 

[Joshua Cranmer]

It is the recommendation from the inventors of the language.

And it is by far the most widely used coding convention from Java.

Facts not religion.

State-sponsored religion is still religion

All things said and done, though, it's a very good idea to follow those
guidelines unless you have extremely compelling reasons not to.

 

[Gene Wirchenko]

Bullshit. That is my observation.

The Java Coding Conventions have been in play since 1999. I have
worked in many Java shops. All had coding standards. Mostly they
adhere to the official conventions, but all accepted or required certain
slight variations, pretty much consistently from one to the next.

Why would you say such a thing?

Because you keep harping about it. Perish the thought that
someone use something else workable.

Sincerely,

Gene Wirchenko

 

[Gene Wirchenko]

It is the recommendation from the inventors of the language.

And it is by far the most widely used coding convention from Java.

Facts not religion.

So it is the most common religion. Big deal.

My coding conventions are cross-language as much as I can make
them.

Sincerely,

Gene Wirchenko

 

[Lew]

So it is the most common religion. Big deal.

My coding conventions are cross-language as much as I can make
them.

You calling the conventions a "religion" neither invalidates nor diminishes
the value of the official conventions.

Your pitch for unconventional conventions violates the spirit and purpose
of the conventions, which is to provide a common basis for the community
to communicate their source code.

Your overtly anti-social and self-aggrandizing approach is not suitable
for playing nicely with others. Be less snarky about the choice to go with
the industry standards, please. I know it makes you feel all important and
powerful and all, but it doesn't serve those wishing to learn how best to
be *professional* Java programmers.

 

[Gene Wirchenko]

[snip]

You calling the conventions a "religion" neither invalidates nor diminishes
the value of the official conventions.

I do not contest the value of the official conventions. I do say
that they are not the only conventions that can be used.

The official conventions (or any others for that matter) are a
religion when they are shoved on people regardless of the situation.

Your disdain for different conventions "neither invalidates nor
diminishes the value of" different conventions.

Your pitch for unconventional conventions violates the spirit and purpose
of the conventions, which is to provide a common basis for the community
to communicate their source code.

My conventions are intended for me. Since I do not use only one
language, I want conventions that work across many languages. If I
work in a different environment, I will code according to what
conventions there are insofar as it does not endanger the quality of
my code.

Anyone who has difficulty reading my code is invited to learn
programming.

Your overtly anti-social and self-aggrandizing approach is not suitable
for playing nicely with others. Be less snarky about the choice to go with

No, *your* overtly anti-social and self-aggrandising approach is
not suitable. I gave up on Java, partly because the language making
certain things that I need awkward to do and partly because of the
snarking.

I remember posting one example of code that I was having trouble
with. It was short and simple and I detailed what I was having
trouble with. One of you Java religion twits responded that I was not
using the standard variable-naming convention and did not reply at all
to my problem. This sort of abuse happened too many times for me to
care much about the Java community or its standards.

I follow this newsgroup still because there are some good
technical discussions. I hope to never have to code in Java again.

the industry standards, please. I know it makes you feel all important and

I state that I have my preferences. If you want to use the
official conventions, go ahead. I have never snarked anyone for doing
so.

powerful and all, but it doesn't serve those wishing to learn how best to
be *professional* Java programmers.

It does nothing of the sort for me. Making up things about me
may help you snark me yet again, but it does little for your point. If
learning how to best use Java depends so heavily on the official
conventions, Java is in horrible danger. An example of this is the
official documentation which is very poor and rates a D for its
incompleteness.

Sincerely,

Gene Wirchenko

 

[bilsch]

[...]
BTW, another way to improve you code is to watch the big cascades of
if-else statements. For example this:

if (btn == ".") {strng1 += btn;}
else if (btn == "0") {strng1 += btn;}
else if (btn == "1") {strng1 += btn;}
else if (btn == "2") {strng1 += btn;}
else if (btn == "3") {strng1 += btn;}
else if (btn == "4") {strng1 += btn;}
else if (btn == "5") {strng1 += btn;}
else if (btn == "6") {strng1 += btn;}
else if (btn == "7") {strng1 += btn;}
else if (btn == "8") {strng1 += btn;}
else if (btn == "9") {strng1 += btn;}

could all just be

strng1 += btn;

because you don't do anything different for the different cases.
Copy-paste statement like this should be avoid, because it creates
relatively low value redundancy. Try to combine common cases into one
block. It's easier to go back and modify later.

Now that you mention it I see how that would work. However the actual
program has many non-numeric buttons I don't want in the string - I
better leave that alone for the present.

You needn't use the same listener for the 7 key as for
the Backspace key ...

The listeners all call a statement in the second file:

public void actionPerformed(ActionEvent event)

so I don't understand how a button listener can be different from
another button listener.

Could you explain please?

TIA Bill S.

 

[Lew]

markspace wrote:
[...]
BTW, another way to improve you code is to watch the big cascades of
if-else statements. For example this:

if (btn == ".") {strng1 += btn;}
else if (btn == "0") {strng1 += btn;}
else if (btn == "1") {strng1 += btn;}
else if (btn == "2") {strng1 += btn;}
else if (btn == "3") {strng1 += btn;}
else if (btn == "4") {strng1 += btn;}
else if (btn == "5") {strng1 += btn;}
else if (btn == "6") {strng1 += btn;}
else if (btn == "7") {strng1 += btn;}
else if (btn == "8") {strng1 += btn;}
else if (btn == "9") {strng1 += btn;}

could all just be

strng1 += btn;

because you don't do anything different for the different cases.
Copy-paste statement like this should be avoid, because it creates
relatively low value redundancy. Try to combine common cases into one
block. It's easier to go back and modify later.

Now that you mention it I see how that would work. However the actual
program has many non-numeric buttons I don't want in the string - I
better leave that alone for the present.

You needn't use the same listener for the 7 key as for
the Backspace key ...

The listeners all call a statement in the second file:

public void actionPerformed(ActionEvent event)

so I don't understand how a button listener can be different from
another button listener.

Could you explain please?

Do the Backspace and "7" keys perform the same steps in response to the
action?

If not, why are they calling the same method?

If so, huh?

 

[Eric Sosman]

[...]
You needn't use the same listener for the 7 key as for
the Backspace key ...

The listeners all call a statement in the second file:

public void actionPerformed(ActionEvent event)

so I don't understand how a button listener can be different from
another button listener.

Could you explain please?

In your code there's a class called CrunchQ1, and because it
implements the ActionListener interface you can (and do) tell
your buttons to use an instance of that class as their action
listeners:

CrunchQ1 crunchNu = new CrunchQ1(this);
...
dot.addActionListener(crunchNu);
zro.addActionListener(crunchNu);
one.addActionListener(crunchNu);
...

What I'm suggesting is that you could perfectly have another
class, maybe CrunchQ2, that also implements ActionListener but does
something different in its ActionPerformed method. Then you could
make yourself an instance of the CrunchQ2 class, and use it instead
of the CrunchQ1 instance for some of your buttons:

CrunchQ1 crunchNu = new CrunchQ1(this);
CrunchQ2 dotty = new CrunchQ2(...whatever...);
...
dot.addActionListener(dotty);
zro.addActionListener(crunchNu);
one.addActionListener(crunchNu);
...

If you have other buttons with idiosyncratic behaviors, you
could give them their own ActionListener implementations, too.
There is no reason in the world why every button in your program
should share the same listener!

 

[Jail Bush Cronies]

On 6/27/2012 2:44 PM, bilsch wrote:
...

You can write several different implementing classes for an interface
such as ActionListener. You can then create different instances of the
same implementing class.

For example, you could have a NumberKeyListener class that implements
ActionListener, and takes a constructor parameter that tells it the
value associated with its button. On the other hand, I would have a
different class for dealing with backspace.

Code like:

one.addActionListener(new NumberKeyListener(1));
two.addActionListener(new NumberKeyListener(2));

would get rid of a lot of checking which button was pressed.

Another option uses the ActionEvent the listener gets passed, a
parameter that's frequently ignored:

public void actionPerformed (ActionEvent e) {
JButton btn = (JButton)(e.getSource());
String btnTxt = btn.getText();
// btnTxt should be "0", "1", ..., or "9".
// Do something with it.
}

Of course, this action listener will blow up if used on something other
than a JButton. You also might not like the results if you later
localize the button labels using a ResourceBundle or something. In
the event that that sort of thing is likely, the numeric-parameter
approach Patricia suggested is more robust. Another possibility is:

private static Map<JButton,Integer> buttonMap;

....

for (int i = 0; i < 10; i++) {
JButton btn = new JButton("" + i);
btn.addActionListener(new NumberKeyListener());
buttonMap.add(btn,i);
}

....

public void actionPerformed (ActionEvent e) {
int btnNum = buttonMap.get(e.getSource());
}

Note: will throw NPE if attached to something other than a button that's
in buttonMap. Also, for buttonMap to be visible in actionPerformed,
NumberKeyListener needs to be a nested class of the class with the rest
of this code.

 

[bilsch]

Which the OP had better be using.

I am using 1.7.0_04

 

[Lew]

I am using 1.7.0_04

It is best for now to stick with the latest Java version, which is Java 7
as you have (although you should upgrade to Java 7u5 - minor version
numbers represent bug and security fixes, things you don't want to
miss).

Out in the wild you'll be asked to use all kinds of old or funky (or both)
Java versions. Many of us have had to work on Java 1.4 projects, even
recently. But while you're learning, stay with the current version.

This is in line with mimicking good code even for areas you haven't
studied yet, such as starting your GUI on the EDT.

As they said in Star Trek (the original series) (paraphrased):
It is easier for a civilized person to pass as a barbarian
than for a barbarian to pass as a civilized person.

 

[Arne Vajhøj]

So it is the most common religion. Big deal.

The most common religion is obvious widely accepted.

But that does not make something widely accepted the most
common religion or a religion at all.

The idea of coding convention has good scientific basis.

My coding conventions are cross-language as much as I can make
them.

But since the rest of the world does not then that is a bad
choice.

Arne

 

[Arne Vajhøj]

State-sponsored religion is still religion

Yes.

But for coding conventions there are a good logical
scientific reason why it is better to use the same
convention as other.

In fact that is the main purpose of a coding convention.

Religion is a bit more let us call it "fuzzy".

All things said and done, though, it's a very good idea to follow those
guidelines unless you have extremely compelling reasons not to.

Yes.

Arne

 

[bilsch]

Thanks for the help. I could swear I tried that first but got error
messages about static and non-static conflict problem. i will be taking
Java in fall quarter. Right now I'm working from "Learn Java in 24
Hours" I thought up the calculator project myself. Thanks again.

There are a few mistakes in your code.

You don't need to call 'super()' in the constructor explicitly.
That's what happens by default anyway.

You called the constructor directly from the 'main()' routine. That means
you called it from the primary thread of the program. You don't know this
yet, probably, unless you've already studied concurrency in Java a little bit.

The problem is that the GUI won't work right if you do that. You have to
move GUI actions onto the "Event Dispatch Thread" (EDT), a background
thread that the system creates to handle all GUI actions.

Also, you start all the action from the constructor. That's bad. As its name
implies, a constructor's purpose is to _construct_ an object, not run its logic.
Run the logic after construction completes and the instance is no longer in a
partially-built state.

And make your indentation consistent with the Java coding conventions (available
on line).

So all together, you'd do something like:

public static void main(String[] arguments) {
java.awt.EventQueue.invokeAndWait( new Runnable() {
@Override public void run() {
CalcGUIQ1 calculator = new CalcGUIQ1();
calculator.setVisible(true);
}
});
}

Hello Lew,

With help I've gotten some errors out of the program but I have reached
a point where something just won't work how it should. Your comments
here lead me to believe the reason is the basic way I have things laid
out. But I don't know how to:

move GUI actions onto the "Event Dispatch Thread" (EDT), further I

dont know how to write an EDT, or what specifically are 'GUI actions' as
opposed to other lines that relate to the GUI.

Also, I thought the stuff I have in the constructor belonged there.

I dont know where to call the constructor from if not from 'main'.

I did some reading about threads being unsafe.

It would be very helpful to me if you could show how to rearrange the
code like you say would be better. If you have the time, it would be
very helpful. Thanks.

Bill S.

 

[Arne Vajhøj]

[snip]

You calling the conventions a "religion" neither invalidates nor diminishes
the value of the official conventions.

I do not contest the value of the official conventions. I do say
that they are not the only conventions that can be used.

The official conventions (or any others for that matter) are a
religion when they are shoved on people regardless of the situation.

Your disdain for different conventions "neither invalidates nor
diminishes the value of" different conventions.

I think you have misunderstood the purpose of a coding convention.

It is not about what is the best way to write certain things.

It is about having everybody writing things the same way to
make it easier to read other peoples code.

That automatically gives the standard convention more points
than the alternatives.

So unless one has specific knowledge about the OP's context,
then the only plausible advice is to go for the standard.

My conventions are intended for me.

So you use the concept invented to make code more readable for other
for yourself.

Hmmm.

No, *your* overtly anti-social and self-aggrandising approach is
not suitable. I gave up on Java, partly because the language making
certain things that I need awkward to do and partly because of the
snarking.

I remember posting one example of code that I was having trouble
with. It was short and simple and I detailed what I was having
trouble with. One of you Java religion twits responded that I was not
using the standard variable-naming convention and did not reply at all
to my problem. This sort of abuse happened too many times for me to
care much about the Java community or its standards.

I follow this newsgroup still because there are some good
technical discussions. I hope to never have to code in Java again.

The assumption is that people that post here are interested in learning.

That includes naming convention.

If they are not, then I don't know why they are here.

I state that I have my preferences. If you want to use the
official conventions, go ahead. I have never snarked anyone for doing
so.

Nobody care how you write your code.

If you want to write the entire class in a single line then do it.

But do not try to tell other that it is an acceptable way to write code.

It does nothing of the sort for me.

No. Because you are not interested in learning.

Your choice.

But do not try to lead other that route.

Arne