«

On 6/26/2012 2:21 PM, Eric Sosman wrote:
> On 6/26/2012 4:04 PM, bilsch wrote:
>> On 6/25/2012 6:10 PM, 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?

TIA Bill S.

bilsch wrote:
> Eric Sosman wrote:
>> bilsch wrote:
>>> 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?

--
Lew

On 6/27/2012 5:44 PM, bilsch wrote:
> On 6/26/2012 2:21 PM, Eric Sosman wrote:
>>[...]
>> 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!

--
Eric Sosman
d

On 27/06/2012 6:21 PM, Patricia Shanahan wrote:
> On 6/27/2012 2:44 PM, bilsch wrote:
> ...
>> 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.
>
> 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.

On 6/26/2012 3:20 PM, Lew wrote:
> Arne Vajhøj wrote:
>> Lew wrote:
>>> markspace wrote:
>>>> bilsch wrote:
>>>>
>>>>> 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.
>>>>
>>>>
>>>> A couple of things. First, even if true, it's better to do something
>>>> like this:
>>>>
>>>> if( btn == "1" || btn == "2" || btn == "3" ... )
>>>> {
>>>> // one single case here...
>>>> }
>>>>
>>>> Than it is to use many different if-blocks. Same action for different
>>>> inputs, you want to use one code block to implement that action.
>>>>
>>>> One other important point I'd like to make is that Java strings don't
>>>> normally compare with ==. You have to use .equals() instead. Your code
>>>> works now because all of the strings are in a single file, but as your
>>>> program grows == will no longer work for you.
>>>>
>>>> This is the normal, and more correct, way to do it:
>>>>
>>>> if( btn.equals( "1" ) || btn.equals( "2" ) || ... )
>>>> {
>>>> strng1 += btn;
>>>> }
>>>
>>> switch (btn)
>>> {
>>> case "1":
>>> case "2":
>>> doCaseOneAndTwo();
>>> break;
>>>
>>> case "3":
>>> doCaseThree();
>>> break;
>>>
>>> default:
>>> doAllOtherCases();
>>> break;
>>> }
>>
>> If Java version>= 7.
>
> Which the OP had better be using.
>
I am using 1.7.0_04

bilsch wrote:
> Lew wrote:
>> Arne Vajhøj wrote:
>>> If Java version>= 7.
>>
>> Which the OP had better be using.
>>
> 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.

--
Lew

On 6/26/2012 11:06 PM, Gene Wirchenko wrote:
> On Tue, 26 Jun 2012 22:18:28 -0400, Arne Vajhøj <>
> wrote:
>> On 6/26/2012 7:26 PM, Gene Wirchenko wrote:
>>> On Tue, 26 Jun 2012 14:34:13 -0700 (PDT), Lew <>
>>> wrote:
>>>> Gene Wirchenko wrote:
>>>>> bilsch wrote:
>>>>>> advise is appreciated and noted. I know my indentation is wrong - it is
>>>>>> something I'll have to work on. I hope I can finish this project without
>>>>>
>>>>> Adopt an indentation style whether it is your own and one that
>>>>> you see that you are comfortable with. Consistent indenting can help
>>>>> you catch errors.
>>>>
>>>> It is best to use the Java Coding Conventions or something very close.
>>>>
>>>> There are a couple of very limited acceptable variations from those
>>>> conventions.
>>>
>>> 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.
>
> 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

On 6/26/2012 10:59 PM, Joshua Cranmer wrote:
> On 6/26/2012 10:18 PM, Arne Vajhøj wrote:
>> On 6/26/2012 7:26 PM, Gene Wirchenko wrote:
>>> On Tue, 26 Jun 2012 14:34:13 -0700 (PDT), Lew <>
>>> wrote:
>>>> Gene Wirchenko wrote:
>>>>> bilsch wrote:
>>>>>> advise is appreciated and noted. I know my indentation is wrong -
>>>>>> it is
>>>>>> something I'll have to work on. I hope I can finish this project
>>>>>> without
>>>>>
>>>>> Adopt an indentation style whether it is your own and one that
>>>>> you see that you are comfortable with. Consistent indenting can help
>>>>> you catch errors.
>>>>
>>>> It is best to use the Java Coding Conventions or something very close.
>>>>
>>>> There are a couple of very limited acceptable variations from those
>>>> conventions.
>>>
>>> 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.
>
> 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

On 6/25/2012 6:36 PM, Lew wrote:
> bilsch wrote:
>> markspace wrote:
>>> bilsch wrote:
>>>> I'm trying to make a program that works like the calculator in Windows
>>>> Accessories - all input is from button clicks. ...
>>>> Everytime the method is called the string is reinitialized
>>>> with the result that my sequence of digits is only ever one digit long.
>>>> My plan would work if I could initialize the string outside the method,
>>>> however variable scope in Java doesn't allow it.
>>>
>>> First, good job on making a very reasonable SSCCE.
>>>
>>> Second, the trick to Java's scoping rules is to change the rules!
>>>
>>> Move the string strng1 from inside the actionPerformed to outside, right
>>> below the CalcGUIQ1 gui; line. Now Java's scoping rules help you rather
>>> than hinder you.
>>>
>>> BTW, this looks like a homework problem, and it looks like you've been
>>> getting help on it. Some if it is a bit sophisticated for someone who
>>> doesn't understand scoping. Please try to talk to your instructor or a
>>> TA, they need to understand when you're having problems with your lessons.
>>>
>> 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.

On 6/27/2012 5:09 PM, Gene Wirchenko wrote:
> On Wed, 27 Jun 2012 11:42:04 -0700 (PDT), Lew <>
> wrote:
>
> [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.

>> 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.

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

Hmmm.

>> 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 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.

>> 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.

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.

>> 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.

No. Because you are not interested in learning.

Your choice.

But do not try to lead other that route.

Arne