I have mulled this over and over, and am not sure it is necessary to refresh the data in the combo boxes (one for Hotel name selection, and one for Hotel location selection). I think that it is OK not to, because if the room is already reserved, they are going to see it in the table (the owner id field will have numbers in it, not be blank). I display a message if it is deleted (they can't delete anyway), or if they decided to go ahead and try to reserve an already reserved room. I will document it in choices.txt. People have gotten away with a lot of other things that might not be appropriate in the real world with a good explanation in the choices.txt. The other issue that came to mind was duplicates in the combo boxes. I decided to leave that one alone, too. The boxes get their data right from the table. A click of the search button will return a new set of data, whole new read of table and new model. I couldn't find much on this with a search both on this site and on the internet in general. Any thoughts appreciated.
If i understand you correctly the data in the comboboxes is taken/refreshed from the JTable containing all matching records. So if you do a search, Table is filled with another set of data and combo boxes are refreshed with data from the JTable. Is my understanding correct? If it is, I'll have some doubts about it.
Nonetheless I would certainly not allow duplicates in my comboboxes, because that will confuse a user: why is "Ritz" 3 times in the combo? Will a search on each occurence have another result.
OK, Roel, you've got me working on using a set to hold the strings that go in the box models (No duplicates). Good in theory, but not working. It's allowing duplicates, basically the same thing that I already have. I'm pretty sure the problem is that since I am dealing with Strings, equality of content and equality are not the same thing. The Strings have the same hotel name but are actually a different Object, so the set is allowing the dupes. I gave up and went home. Back to the drawing board tomorrow. I'm amazed at how much I don't know about Swing
I'm doing also the combo box approach. I also thought about refreshing the boxes as they might not reflect the database state. I come to the conclusion not to bother with it as a client might never be sure to see the latest state of the database anyway! That's why I have my combo boxes made editable, so even when the entry is not displayed the user can still type in what he liked to search for. I populate them once when the application starts and has to perform a search for all records anyway.
You're second problem with having dupes in the combo boxes, I also think this to be weird for the user experience. So I'm using a java.util.TreeMap and add all found entries to it and return a String-array from my helper method. The combo box are then filled with the contents of the array. This avoid the dupes and gives the additional advantage of the combo box being sorted.
Hello Anne, the duplicates in the combo box should not have anything to do with Swing components. It's on how you getting that data from the database file. Since you are using strings, have you thought of using collections? Working with lists, sets or maps are easier to manipulate, iterate etc.
Anne Crace wrote:OK, Roel, you've got me working on using a set to hold the strings that go in the box models (No duplicates). Good in theory, but not working. It's allowing duplicates, basically the same thing that I already have.
That's weird it isn't working. Because if I use the following program which uses a set (TreeSet to sort alphabetically) only 4 names are printed to the console (although i add 6 strings to the set). I'm a bit that it isn't working with you.
Joined: Aug 29, 2005
I got it working. I was having some scoping (curly brace location) issues as far as where everything was happening. I ran it through the debugger to see that the set was indeed correct (all unique). I just needed to put the set back into an array to load the boxes. Now I have a slight bug in my Search algorithm, but don't think that will be so difficult to fix. All in all, a good learning experience.