开发者

WindowBuilder for Swing made member data and it seemed unnecessary

开发者 https://www.devze.com 2023-04-06 21:28 出处:网络
WindowBuilder for Swing creates checkboxes as local variables and textboxes as member data.This inconsistency bothered me.Since it all gets linked up into the toplevel JFrame anyway, these widgets are

WindowBuilder for Swing creates checkboxes as local variables and textboxes as member data. This inconsistency bothered me. Since it all gets linked up into the toplevel JFrame anyway, these widgets are sure to live as long as the JFrame has references down to them so there doesn't seem to be a need for the textboxes to be member data. It seems to me that the textboxes should be locals just like the checkboxes. Locals are better encapsulation. The local references can die at the end of the GUI object (a class that extends JFrame) constructor generated by WindowBuilder and the JFrame will still have references to all the widgets.

Making them local and putting "final" in front of these widget declarations so that they can be used inside the event handler's anonymous inner classes was what it took to make them work. I also had to rearrange the order a bit since the order of instantiation of textboxes doesn't matter if they are all declared as members. Order does matter for locals so I had to move the uses of the "new" operator (instantiation) "up" a bit towards the top of the local scope. They just had to be north of the event handlers that use them.

So far I've found no bugs as a consequence so I am asking why WindowBuilder did not do it this way to begin with. I am new to Swing and WindowBuilder so there is a high probability that there are excellent reasons for WindowBuilder to not do this even though it seems to be the right approach for my case.

The following is the WindowBuilder output after some trivial naming modifications but before the modifications described above. This is the output as it is with 2 textboxes, 2 checkboxes, 2 buttons in the north and 1 label in the center. This is being pasted here in case somebody can see something here that may explain the choice behind WindowBuilder's use of member data.

public 开发者_StackOverflow中文版class TestWB extends JFrame
{
    private static final long serialVersionUID = 1L;
    private JPanel contentPane;
    private JTextField textBox1;
    private JTextField textBox2;

    public TestWB() // the constructor
    { 
       ... // see the constructor below
    }
}

The constructor for the above class:

public TestWB()
{
    setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    setBounds(100, 100, 646, 451);
    contentPane = new JPanel();
    contentPane.setBorder(new EmptyBorder(5, 5, 5, 5));
    contentPane.setLayout(new BorderLayout(0, 0));
    setContentPane(contentPane);

    JPanel northPanel = new JPanel();
    contentPane.add(northPanel, BorderLayout.NORTH);

    JButton button1 = new JButton("button1");
    button1.addActionListener(new ActionListener() {
        public void actionPerformed(ActionEvent arg0) {
        }
    });
    northPanel.add(button1);

    JButton button2 = new JButton("button2");
    button2.addActionListener(new ActionListener() {
        public void actionPerformed(ActionEvent e) {
        }
    });
    northPanel.add(button2);

    final JCheckBox checkBox1 = new JCheckBox("cb1");
    checkBox1.addActionListener(new ActionListener() {
        public void actionPerformed(ActionEvent e) {
            CbProcessor cbp = new CbProcessor();
            cbp.dealWithCb(checkBox1.isSelected(), textBox1);
        }
    });
    northPanel.add(checkBox1);

    final JCheckBox checkBox2 = new JCheckBox("cb2");
    checkBox2.addActionListener(new ActionListener() {
        public void actionPerformed(ActionEvent e) {
            CbProcessor cbp = new CbProcessor();
            cbp.dealWithCb(checkBox2.isSelected(), textBox2);
        }
    });
    northPanel.add(checkBox2);

    textBox1 = new JTextField();
    textBox1.addActionListener(new ActionListener() {
        public void actionPerformed(ActionEvent e) {
        }
    });
    textBox1.setText("tb1");
    northPanel.add(textBox1);
    textBox1.setColumns(5);

    textBox2 = new JTextField();
    textBox2.addActionListener(new ActionListener() {
        public void actionPerformed(ActionEvent e) {
        }
    });
    textBox2.setText("tb2");
    northPanel.add(textBox2);
    textBox2.setColumns(5);

    JPanel centerPanel = new JPanel();
    contentPane.add(centerPanel, BorderLayout.CENTER);

    JLabel label1 = new JLabel("label1");
    centerPanel.add(label1);
}


This is a case where reading the WindowBuilder docs would have easily answered your question(s). WindowBuilder will generate code any way that you like. Widgets can all be local variables, all be fields, or any combination in between. You can control the scope of different widgets individually or on a type-by-type basis (by setting defaults). In fact, WindowBuilder has an incredibly rich set of code generation preferences and can replicate just about any code generation style you could desire. It will also happily reverse engineer just about any code you throw at it, so you can make just about any changes you want to the generated code (by hand or via the tool) and it will remain perfectly happy.

WindowBuilder for Swing made member data and it seemed unnecessary

WindowBuilder for Swing made member data and it seemed unnecessary


I don't know something about WindowBuilder, but I do know something about SWT and SimpleDesktopAplication FrameWorks but

1) both are based on AWT(part from SWT) and Swing

2) both are overrode standard AWT & Swing's methods

3) in some cases is too hard to returns back to standard AWT & Swing's methods from Framework's methods

I'd suggest to learn basic Swing at begining,

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号