Editable issues

Discussion in 'Java' started by K, Jan 29, 2013.

  1. K

    K Guest

    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);
    }

    }
    K, Jan 29, 2013
    #1
    1. Advertising

  2. > 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?
    Mikhail Vladimirov, Jan 29, 2013
    #2
    1. Advertising

  3. On 01/29/2013 03:17 AM, Peter Duniho wrote:
    > On Mon, 28 Jan 2013 22:21:25 -0800 (PST), Mikhail Vladimirov wrote:
    >
    >>> 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?

    >
    > 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
    Arved Sandstrom, Jan 29, 2013
    #3
  4. K

    Roedy Green Guest

    On Mon, 28 Jan 2013 21:19:03 -0800 (PST), K <> wrote,
    quoted or indirectly quoted someone who said :

    >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
    Roedy Green, Jan 29, 2013
    #4
  5. K

    Arne Vajhøj Guest

    On 1/29/2013 5:27 AM, Arved Sandstrom wrote:
    > 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
    Arne Vajhøj, Jan 30, 2013
    #5
  6. On 01/29/2013 11:02 PM, Arne Vajhøj wrote:
    > On 1/29/2013 5:27 AM, Arved Sandstrom wrote:
    >> 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
    >

    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
    Arved Sandstrom, Jan 30, 2013
    #6
  7. K

    Lew Guest

    Arved Sandstrom wrote:
    > Arne Vajh�j wrote:
    > > 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

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

    --
    Lew
    Lew, Jan 30, 2013
    #7
  8. On 01/30/2013 12:32 PM, Lew wrote:
    > Arved Sandstrom wrote:
    >> Arne Vajh�j wrote:
    >>> 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

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

    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
    Arved Sandstrom, Jan 30, 2013
    #8
  9. K

    Arne Vajhøj Guest

    On 1/30/2013 6:38 AM, Arved Sandstrom wrote:
    > On 01/29/2013 11:02 PM, Arne Vajhøj wrote:
    >> On 1/29/2013 5:27 AM, Arved Sandstrom wrote:
    >>> 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
    >>

    > 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, Jan 31, 2013
    #9
  10. K

    Arne Vajhøj Guest

    On 1/30/2013 6:34 PM, Arved Sandstrom wrote:
    > On 01/30/2013 12:32 PM, Lew wrote:
    >> Arved Sandstrom wrote:
    >>> Arne Vajh�j wrote:
    >>>> 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
    >>>
    >>> 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?
    >>

    > 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
    Arne Vajhøj, Jan 31, 2013
    #10
  11. On 01/30/2013 09:04 PM, Arne Vajhøj wrote:
    > On 1/30/2013 6:34 PM, Arved Sandstrom wrote:
    >> On 01/30/2013 12:32 PM, Lew wrote:
    >>> Arved Sandstrom wrote:
    >>>> Arne Vajh�j wrote:
    >>>>> 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
    >>>>
    >>>> 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?
    >>>

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

    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
    Arved Sandstrom, Jan 31, 2013
    #11
  12. K

    Roedy Green Guest

    On Wed, 30 Jan 2013 08:32:09 -0800 (PST), Lew <>
    wrote, quoted or indirectly quoted someone who said :

    >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
    Roedy Green, Jan 31, 2013
    #12
  13. K

    Arne Vajhøj Guest

    On 1/31/2013 10:26 AM, Peter Duniho wrote:
    > On Thu, 31 Jan 2013 04:15:57 -0800, Roedy Green wrote:
    >
    >> On Wed, 30 Jan 2013 08:32:09 -0800 (PST), Lew <>
    >> wrote, quoted or indirectly quoted someone who said :
    >>
    >>> 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, Jan 31, 2013
    #13
  14. K

    Arne Vajhøj Guest

    On 1/31/2013 5:21 AM, Arved Sandstrom wrote:
    > On 01/30/2013 09:04 PM, Arne Vajhøj wrote:
    >> On 1/30/2013 6:34 PM, Arved Sandstrom wrote:
    >>> On 01/30/2013 12:32 PM, Lew wrote:
    >>>> Arved Sandstrom wrote:
    >>>>> Arne Vajh�j wrote:
    >>>>>> 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
    >>>>>
    >>>>> 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?
    >>>>
    >>> 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.


    > 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
    Arne Vajhøj, Jan 31, 2013
    #14
  15. On 01/31/2013 08:54 PM, Peter Duniho wrote:
    > On Thu, 31 Jan 2013 11:04:38 -0500, Arne Vajhøj wrote:
    >
    >> I don't like the code generated by VS.

    >
    > 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 there is one big advantage there. The partial class concept allows
    >> to nicely separate the generated stuff from the manual written stuff.

    >
    > 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
    Arved Sandstrom, Feb 1, 2013
    #15
  16. K

    Roedy Green Guest

    On Thu, 31 Jan 2013 07:26:22 -0800, Peter Duniho
    <> wrote, quoted or indirectly quoted
    someone who said :

    >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
    Roedy Green, Feb 1, 2013
    #16
  17. On 1/31/2013 7:54 PM, Peter Duniho wrote:
    > On Thu, 31 Jan 2013 11:04:38 -0500, Arne Vajhøj wrote:
    >
    >> I don't like the code generated by VS.

    >
    > 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 there is one big advantage there. The partial class concept allows
    >> to nicely separate the generated stuff from the manual written stuff.

    >
    > 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
    Arne Vajhøj, Feb 2, 2013
    #17
  18. On 02/01/2013 09:08 PM, Arne Vajhøj wrote:
    > 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
    Arved Sandstrom, Feb 2, 2013
    #18
  19. K

    Roedy Green Guest

    On Fri, 1 Feb 2013 18:12:21 -0800, Peter Duniho
    <> wrote, quoted or indirectly quoted
    someone who said :

    >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
    Roedy Green, Feb 2, 2013
    #19
  20. On 2/1/2013 9:12 PM, Peter Duniho wrote:
    > On Fri, 01 Feb 2013 20:08:10 -0500, Arne Vajhøj wrote:
    >> [...]
    >> 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
    Arne Vajhøj, Feb 2, 2013
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. kalyani mantripragada

    editable dropdownlist COM

    kalyani mantripragada, Oct 29, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    599
    kalyani mantripragada
    Oct 29, 2003
  2. Bei

    Simple editable div question

    Bei, Jul 13, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    522
    Kevin Spencer
    Jul 13, 2003
  3. Alex K

    Editable DataGrid Validation

    Alex K, Aug 13, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    441
    Alex K
    Aug 13, 2003
  4. Mike Moore [MSFT]

    RE: Editable Datagrid.

    Mike Moore [MSFT], Aug 29, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    418
    Mike Moore [MSFT]
    Aug 29, 2003
  5. Alex
    Replies:
    0
    Views:
    449
Loading...

Share This Page