This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I've got a problem which im sure will be quiet common when building GUI's.
I have a class called GUI in which the constructor sets up the entire interface, however parts of the interface need to be updatable to reflect changes in data and user selection.
The method im using atm is JTextFields etc are created in the constructor, however they only exist for the duration of the constructor because they aren't class level.
So how do I get around the problem of needing to update these controls? I would need to create an entire new GUI with my current approach which isn't efficent.
I have two combo boxes, the value selected in the first decides the value in the second. However because neither are class level I can't access them in the ActionListener that picks up the change in value from the first combo. So how do I get around this?
I'm assuming I don't have to make all of my controls class level fields?
I know this is quite a long post but it's stopping me from working atm.
You don't have to use "class-level fields" (more commonly called "members" or "member variables") for all of your components -- just the ones that you'll need to refer to later. You seem to think this is difficult, somehow -- but all you need to do is move the declarations of the variables out to class scope. You can still initialize them in the constructor. In other words,
If you create a brand new JComboBox, then the old one is still part of the GUI, and you don't have a handle to it anymore. Remember that a Java variable is just a reference or "pointer" to an object -- it's not the object itself. (See here for an entertaining explanation of this, if needed.)
What you want to do is to tell the existing JComboBox that it should display a new set of items. Perhaps the shortest -- if not the easiest to understand -- way to do this is to construct a new ComboBoxModel containing the new data, and giving it to the JComboBox:
I made a few other small but significant changes to this bit of code. One important one is to use the equals() method rather than the "==" operator to compare Strings. The operator checks for physical equality -- i.e., both Strings are the same physical block of memory. The equals() method checks for equivalence -- i.e., the same characters in the same order, but perhaps two different copies of them.
The other change is that I renamed your "StringArray" variable to "stringArray". Java's naming conventions for classes (CapitalizedLikeThis) and variables (lowercaseLikeThis) are very firmly entrenched; flouting them makes your code harder for other people to understand at a glance.
Joined: Nov 11, 2004
Originally posted by Ernest Friedman-Hill: Java's naming conventions for classes (CapitalizedLikeThis) and variables (lowercaseLikeThis) are very firmly entrenched.
I have implemented your suggestions and I appreciate your help, when I found your post I was researching the ComboBoxModel interface but hadn't come across the DefaultComboBoxModel class, I appreciate it!
Additionally are there any conventions for method naming?