Editable issues

[K]

I made a java program and can't figure out why my uneditable text can still be edited. I have 2 classes in this program here's the secondary class:
import java.awt.FlowLayout;
import java.awt.event.ActionListener;
import java.awt.event.ActionEvent;
import javax.swing.JTextField;
import javax.swing.JPasswordField;
import javax.swing.JOptionPane;
import javax.swing.JFrame;
import javax.swing.JButton;
import javax.swing.Icon;
import javax.swing.ImageIcon;
import javax.swing.JLabel;

public class GUI_two extends JFrame{

private JTextField item2;
private JTextField item3;
private JTextField item4;
private JPasswordField itempass;
ImageIcon image = new ImageIcon("star.png");
public GUI_two(){
super("Kale");
setLayout(new FlowLayout());
item2 = new JTextField(10);
add(item2);
item3 = new JTextField("Enter text here");
item3.setEditable(false);
add(item3);
item4 = new JTextField("Can't edit", 20);
item3.setEditable(false);
add(item4);
itempass = new JPasswordField ("Password");
add(itempass);
reg = new JButton("Button");
add(reg);
Icon b = new ImageIcon(getClass().getResource("Button 2.png"));
Icon a = new ImageIcon(getClass().getResource("Button.png"));
custom = new JButton("Custom", a);
custom.setRolloverIcon(b);
add(custom);

thehandler handler = new thehandler();
item2.addActionListener(handler);
item3.addActionListener(handler);
item4.addActionListener(handler);
itempass.addActionListener(handler);
reg.addActionListener(handler);
custom.addActionListener(handler);

}

private JButton reg;
private JButton custom;

private class thehandler implements ActionListener{
public void actionPerformed(ActionEvent event){
String string = "";
if(event.getSource()==item2){
string=String.format("field 2: %s", event.getActionCommand());}
else if (event.getSource()==item3)
string=String.format("field 3: %s", event.getActionCommand());
else if (event.getSource()==item4)
string=String.format("field 4: %s", event.getActionCommand());
else if (event.getSource()==itempass)
string=String.format("itempass is : %s", event.getActionCommand());


//JOptionPane.showMessageDialog(null, String.format("%s, event.getActionCommand()"));
JOptionPane.showMessageDialog(null, string);
}
}


}

here's the main class:
import javax.swing.JOptionPane;
import javax.swing.JFrame;

public class Kale_GUI {


public static void main(String[] args) {
String fn = JOptionPane.showInputDialog("Enter first number");
String sn = JOptionPane.showInputDialog("Enter second number");
int num1 = Integer.parseInt(fn) ;
int num2 = Integer.parseInt(sn) ;
int sum = num1 + num2;
JOptionPane.showMessageDialog(null, "The answer is "+sum, "The title", JOptionPane.PLAIN_MESSAGE);

GUI_two kale = new GUI_two();

kale.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
kale.setSize(500,500);
kale.setVisible(true);
}

}

 

[Mikhail Vladimirov]

item3 = new JTextField("Enter text here");

item3.setEditable(false);
add(item3);
item4 = new JTextField("Can't edit", 20);
item3.setEditable(false);
add(item4);

Probably because you did setEditable (false) on item3 twice, and didn't do it on item4?

 

[Arved Sandstrom]

Copy/paste rears its ugly head again. A helper method would have prevented
the mistake:

[ SNIP ]

Helper method probably best. I'd also name variables better, and
declare/define and do everything with them in one spot demarcated by WS,
if possible, e.g.:

private JTextField nameTextFld;
nameTextFld = new JTextField("Enter name");
nameTextFld.setEditable(false);
add(nameTextFld);
MyActionListener aLsnr = new MyActionListener();
nameTextFld.addActionListener(aLsnr);

We've had this discussion before, blocks also ensure that erroneous copy
& paste (for situations like this) also fails.

I barely ever use Swing, so I won't comment on the ActionListener
implementation. I do know it's fairly wrong-looking and just plain ugly.
I'm myself not going to have a spaghetti event handler that looks to see
who fired it out of many possibilities.

Main problem here is that in 2013 we still have people hand-cranking
Swing code. It's ugly, tedious, unedifying, error-prone code. It's worse
than JSF boilerplate and that's saying quite a lot.

..NET tooling has Java beat in this regard.

AHS

 

[Roedy Green]

I made a java program and can't figure out why my uneditable text can still be edited

see sample code at http://mindprod.com/jgloss/jpasswordfield.html

it works fine with setEditable( false )

You made an error that would not likely have happened with more
meaningful names for your variables:

item3 = new JTextField("Enter text here");
item3.setEditable(false); <-- you meant true
item4 = new JTextField("Can't edit", 20);
item3.setEditable(false); <-- you meant item4

let me rename the vars:

canEnter= new JTextField("Enter text here");
canEnter.setEditable(false); <-- you meant true
cantEnter= new JTextField("Can't edit", 20);
canEnter.setEditable(false); <-- you meant cantEnter
--
Roedy Green Canadian Mind Products http://mindprod.com
The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development
time.
~ Tom Cargill Ninety-ninety Law

 

[Arne Vajhøj]

Main problem here is that in 2013 we still have people hand-cranking
Swing code. It's ugly, tedious, unedifying, error-prone code. It's worse
than JSF boilerplate and that's saying quite a lot.

.NET tooling has Java beat in this regard.

I strongly suspect that it is not:

lack of GUI builder tools => desire to hand write Swing code

but instead:

desire to hand write Swing code => lack of GUI builder tools

Arne

 

[Arved Sandstrom]

I strongly suspect that it is not:

lack of GUI builder tools => desire to hand write Swing code

but instead:

desire to hand write Swing code => lack of GUI builder tools

Arne

If I parse your English correctly, Arne, you're suggesting that folks
*prefer* to code Swing directly rather than make use of GUI builder
interfaces?

Man, I'm not sure I buy that. I've suffered through writing Swing code
from scratch a few times, I don't see how it's any more useful to do
that than hand-coding JSF Facelets .xhtml and backing bean boilerplate.
Which is to say, not useful at all. You gain nothing over using GUI
builder tools, and you lose time better spent on real logic.

AHS

 

[Lew]

If I parse your English correctly, Arne, you're suggesting that folks
*prefer* to code Swing directly rather than make use of GUI builder
interfaces?

No, he's suggesting that in this particular case the person might be deliberately
doing it by hand. I guess programmers do that when they want to learn what they're
actually doing.

Man, I'm not sure I buy that. I've suffered through writing Swing code
from scratch a few times, I don't see how it's any more useful to do
that than hand-coding JSF Facelets .xhtml and backing bean boilerplate.
Which is to say, not useful at all. You gain nothing over using GUI
builder tools, and you lose time better spent on real logic.

Yes, even you have written Swing by hand. What's so odd that others might also?

Didn't the experience teach you about Swing? That wasn't useful?

 

[Arved Sandstrom]

No, he's suggesting that in this particular case the person might be deliberately
doing it by hand. I guess programmers do that when they want to learn what they're
actually doing.


Yes, even you have written Swing by hand. What's so odd that others might also?

Didn't the experience teach you about Swing? That wasn't useful?

During the learning phase, sure. Makes sense.

But in routine work, once I've gotten the technology, no, I don't want
to write all the tedious boilerplate. Swing, JSF, JPA etc - I generate
as much as I can if I can, or I wish I could if it's not possible. All I
really want to spend my time on is modifying the generated code.

AHS

 

[Arne Vajhøj]

If I parse your English correctly, Arne, you're suggesting that folks
*prefer* to code Swing directly rather than make use of GUI builder
interfaces?
Correct.

Man, I'm not sure I buy that. I've suffered through writing Swing code
from scratch a few times, I don't see how it's any more useful to do
that than hand-coding JSF Facelets .xhtml and backing bean boilerplate.
Which is to say, not useful at all. You gain nothing over using GUI
builder tools, and you lose time better spent on real logic.

A GUI builder is very fast to create something that from
simple to medium complexity. But if you need to create
something of high complexity you often end up having to
work around the GUI builder.

The generated code is usually much harder to read when
debugging.

And if you change IDE you risk to loose the capability
on existing code.

Anyway - there has been several GUI builders for Java.
JBuilder had one. NetBeans has tried twice I believe.
Eclipse has tried twice. No success. No widespread
usage.

And note that it is not really Java that is different
from the rest. It is really MS that is different from
the rest. GUI builders are not common in PHP, various X
etc..

Arne

 

[Arne Vajhøj]

During the learning phase, sure. Makes sense.

But in routine work, once I've gotten the technology, no, I don't want
to write all the tedious boilerplate. Swing, JSF, JPA etc - I generate
as much as I can if I can, or I wish I could if it's not possible. All I
really want to spend my time on is modifying the generated code.

That requires the generated code to be as good as handwritten code
to work.

That is rarely the case.

Arne

 

[Arved Sandstrom]

That requires the generated code to be as good as handwritten code
to work.

That is rarely the case.

Arne

I disagree that the generated code needs to be as good as handwritten
code. Handwritten code at what stage - initial layout? Final layout?
Styled and beautiful? All the actions added? Actions all do something real?

You see my argument? At what point do you consider the handwritten code
to be done?

What I see as a complete waste of time is handwriting the code for
layout, for geometry. The generated code only has to give you an
initial, compilable decent representation of layout, that is all. It
doesn't have to be as good as several of the later hand-tuned stages.

AHS

 

[Roedy Green]

No, he's suggesting that in this particular case the person might be delibe=
rately=20
doing it by hand

There is a generic problem with generators. If for any reason you
have to modify the generated code, it becomes impossible to maintain.
If you change at a high level your tweakings will be lost. If you
change at a low level, you must deal with the generated spaghetti.

You need a very good separation of visual and any other logic, so the
generator deals purely with visual code, with no need to jump outside
its box.

Generators sometimes give you stubs to insert your own code, but
figuring out how to use them is often much harder than just writing
the whole thing out long hand.

The other generic problem with generators is they are one more tool
you and anyone modifying your code has to learn. This drawback
suggests if you only have a little bit of visual code you should spell
it out longhand.
--
Roedy Green Canadian Mind Products http://mindprod.com
The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development
time.
~ Tom Cargill Ninety-ninety Law

 

[Arne Vajhøj]

No, he's suggesting that in this particular case the person might be delibe=
rately=20
doing it by hand

There is a generic problem with generators. If for any reason you
have to modify the generated code, it becomes impossible to maintain. [...]

This may be true of poorly designed GUI editors. But frankly, it does not
_have_ to be true of all editors. In fact, to Arved's previous point, it's
been my experience that the code generated by Microsoft's tools is very
maintainable.

The .NET WinForms GUI designer doesn't do anything except the initial
initialization. This includes layout, initial property settings (such as
color, text, customizing behaviors such as read-only text, etc.), and
hooking up event handlers ("listeners" in Java-jargon).

Customization of behavior involves overriding event responses, either with
an actual virtual member override or in an event handler implementation,
depending on specific needs and the situation. It's quite easy to do those
things without abandoning the designer-generated code, or even the designer
itself.

Similar things are true for the WPF designers, though it's taken some time
for Microsoft to evolve to a nice, seamless, integrated toolset there. (In
earlier versions of WPF, there was a rudimentary designer in Visual Studio,
while Microsoft expected the heavy lifting to be done in Expression
Blend...my understanding is that in VS2012, they are shifting the Blend
designer functionality back into the IDE).

I've used and become disgusted with at least one iteration each of Java GUI
designers in Eclipse and Netbeans, so I understand where Arne is coming
from when he suggests you can always write better GUI code by hand in Java.

But that's hardly something that _has_ to be true. It just happens to be
true for the lame GUI designers that Java programmers have been subjected
to.

I don't like the code generated by VS.

But there is one big advantage there. The partial class concept allows
to nicely separate the generated stuff from the manual written stuff.

Arne

 

[Arne Vajhøj]

I disagree that the generated code needs to be as good as handwritten
code. Handwritten code at what stage - initial layout? Final layout?
Styled and beautiful? All the actions added? Actions all do something real?

You see my argument? At what point do you consider the handwritten code
to be done?

What I see as a complete waste of time is handwriting the code for
layout, for geometry. The generated code only has to give you an
initial, compilable decent representation of layout, that is all. It
doesn't have to be as good as several of the later hand-tuned stages.

Ah.

Then I think we are pretty close to agreement.

When writing GUI code, then I typical either copy paste from
somewhere else or use a GUI builder to get "something" and
then manual edit it from there.

(not so much GUI builder in Java since switching from JBuilder
to Eclipse)

Arne

 

[Arved Sandstrom]

I don't have to like it, as long as I don't have to see it or mess with it.

And with the VS Designer, I don't have to. Even when customizing the UI to
suit my needs, nothing about the Designer-generated code has to be touched.


But even prior to partial classes, the IDE used code regions to collapse
the Designer-generated code. Either way, it doesn't really matter what's in
the generated code, as long as it does what it's supposed to and the
programmer doesn't have to mess with it directly (whether to customize the
GUI behavior, or for some other reason).

And in VS, that's how it is.

It's true that without the partial class feature, a Java-oriented GUI
designer couldn't be quite as seamless as what one finds in the .NET
toolset. But I think someone with sufficient motivation could in fact write
a GUI editor that works practically as well, even without that.

They just don't seem to have yet. And IMHO this is one reason why at least
some people eschew using Java for desktop apps. It's certainly a
significant factor in why I stopped bothering and went back to using .NET
for my day-to-day ad hoc projects.

I can't prove that I'm typical. But it's likely I'm not entirely unique
either.

Pete

+1. That's how I see it, all of it, except better phrased. I also don't
much care about the VS-generated code, although I find it tolerable at
worst, pretty decent usually. Fact is, as Pete points out, it don't
matter - I can concentrate on interesting stuff and if I change layout
later VS won't trample it.

I also cannot see why someone couldn't write decent code generators for
AWT or now Swing, or JSF. As I pointed out previously, people have
accomplished just this, in Java and for Java/XML source, for process
designers and SOA type tools, which is considerably more complicated. So
I don't know why this is so bloody difficult.

Like I mentioned to Arne, I already have my workaround, because I can't
stand to waste my time writing JSF boilerplate. Thankfully I don't have
to write Swing - I've managed to stick to .NET for desktop GUIs.

AHS

 

[Roedy Green]

This may be true of poorly designed GUI editors

I tired out Symantec's many moons ago and have been shy ever since. I
think a similar thing happened with SCIDS where programs are
maintained as parse trees. Early efforts frightened people off.
--
Roedy Green Canadian Mind Products http://mindprod.com
The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development
time.
~ Tom Cargill Ninety-ninety Law

 

[Arne Vajhøj]

I don't have to like it, as long as I don't have to see it or mess with it.

And with the VS Designer, I don't have to. Even when customizing the UI to
suit my needs, nothing about the Designer-generated code has to be touched.


But even prior to partial classes, the IDE used code regions to collapse
the Designer-generated code.

Yes.

But that does avoid mixing generated and non generated up in source
control.

Or having to view the generated code when using a plain editor/

Either way, it doesn't really matter what's in
the generated code, as long as it does what it's supposed to and the
programmer doesn't have to mess with it directly (whether to customize the
GUI behavior, or for some other reason).

But of one do need to mess with it, then ...

And in VS, that's how it is.

You have never heard of anyone using VS that wanted to do something
for GUI that required manual editing??

It's true that without the partial class feature, a Java-oriented GUI
designer couldn't be quite as seamless as what one finds in the .NET
toolset. But I think someone with sufficient motivation could in fact write
a GUI editor that works practically as well, even without that.

They just don't seem to have yet. And IMHO this is one reason why at least
some people eschew using Java for desktop apps. It's certainly a
significant factor in why I stopped bothering and went back to using .NET
for my day-to-day ad hoc projects.

I can't prove that I'm typical. But it's likely I'm not entirely unique
either.

I am sure there are other that do not like the Java GUI builders.

But I am convinced that the main reason for the low usage
of Java for desktop apps is the look and feel not being
sufficient native.

Arne

 

[Arved Sandstrom]

On 1/31/2013 7:54 PM, Peter Duniho wrote: [ SNIP ]

They just don't seem to have yet. And IMHO this is one reason why at
least
some people eschew using Java for desktop apps. It's certainly a
significant factor in why I stopped bothering and went back to using .NET
for my day-to-day ad hoc projects.

I can't prove that I'm typical. But it's likely I'm not entirely unique
either.

I am sure there are other that do not like the Java GUI builders.

But I am convinced that the main reason for the low usage
of Java for desktop apps is the look and feel not being
sufficient native.

Arne

I think you're right about that latter. Desktop apps that I've written
for various platforms in the past few years, professionally that is,
have not been Java because they look like Java, not native. And I'll use
Mono before I use Java, on other OS's.

The pain of using Swing is there, it helps convince me not to use Java
for desktop apps, but L&F is a bigger factor, sure.

So for me the current painpoint with Java and GUIs is JSF, because I do
that quite a lot. Like I said, I finally bit the bullet and automated
the process for myself, so I can easily generated matching XHTML
Facelets pages and managed beans, for example.

AHS

 

[Roedy Green]

For my own part, if I had a Java toolset that worked as well as the Visual
Studio/.NET combination

If you go that route, what do you think the lifetime of your code is
before either tools are dropped or evolve so your code no longer
works?

In HTML you do a lot of your layout with style sheets rather than
tweaking each component individually. I think we need something
similar for desktop apps. Maybe HTML 5 will evolve to fill that
niche.
--
Roedy Green Canadian Mind Products http://mindprod.com
The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development
time.
~ Tom Cargill Ninety-ninety Law

 

[Arne Vajhøj]

[...]
But I am convinced that the main reason for the low usage
of Java for desktop apps is the look and feel not being
sufficient native.

Well, I can't say I have data to dispute that. Far be it from me to try to
dissuade you of your opinion.

But it sure sounds like a pretty weak basis to me. If look-and-feel were so
important, more of the .NET community would have jumped on the WPF
bandwagon years ago, rather than continuing to write new WinForms apps
today in spite of its entirely dated look.

WinForms may look dated, but it is still very Windows like.

For my own part, if I had a Java toolset that worked as well as the Visual
Studio/.NET combination, I'd invest a lot more time coding in Java.
Granted, in that case it's not just the Designer. There are C# language
features missing from Java that I appreciate and love too much. But the
language feature issue is balanced somewhat by Java's superior
cross-platform story, so certainly the GUI-building tools (or lack thereof)
are a big part of what finally tips the scales in favor of .NET for me.

What did you try? JBuilder? NetBeans Matisse? Eclipse VE? Eclipse
WindowsBuilder?

Arne