JComboBoxes

[David Abramowicz]

Hi all!

Is there anyone who has made the choice to omit the use of JComboBoxes for search criteria (I have B&S)???

I just don't like the way most people seem to populate the criteria once... I mean, if someone were to add a new record it would require restart of the client before the JComboBoxes were updated...

How have you guys justified this?

Thanks /Dave

[Frans Janssen]

David,

You will probably get away with combo boxes as long as your other design decisions are consistent with it. As far as I can tell by reading this forum, a lot of people have used them.
E.g. you will need to assume that no new records are created or introduce a mechanism that notifies clients if records are added.
(And what to do if records are deleted?)

I have decided to use regular JTextFields for the following reasons:

avoids problems you just mentioned

matches with how people expect to search (compare e.g. searching in web browsers and word processors)

combo boxes are very annoying when the number of options is large (>10). Remember those combo boxes where you must select your country?

I decided to add an option in my search dialog that allows the user to switch between searching for exact matches and partial matches. I am aware that this won't give me any extra credits, but it adds to the testability of my find() method.

Frans.

[David Abramowicz]

Thanks Frans...

I think I will continue as planned without the JComboBoxes.

Cheers /D

[Eric Chang]

Why would you need a restart of the application to repopulate the JComboBoxes? You can just create a method that will "refresh" everything after an update/create/delete action.

[dennis du]

Yeah.........It is a problem.
If database data is changed,but the data in JComboBox is not changed.

So I will add [refresh NameCombox] [refresh locationcomboBox]
to the menu.

Thanks again!

[David Abramowicz]

Originally posted by Eric Chang:
Why would you need a restart of the application to repopulate the JComboBoxes? You can just create a method that will "refresh" everything after an update/create/delete action.

Hmmm... I'm using RMI so it is impossible for the server to contact the client for this refresh should update/create/delete occur.

I mean, I know it is doable by for instance refreshing everytime a search is performed, or every time the JComboBox is touched etc... But I still don't like that solution.

[Eric Chang]

You would need to provide a refresh method anyway, because if one Client updates something, you would need the other Client to see the changes, so why not just use the same method to refresh the ComboBoxes?

[Daniel Simpson]

I dynamically populated JComboBoxes for searching but I feel you guys may be trying to work past the scope of this assignment. For this assignment, the only thing being updated is the customer id field, nothing else. So there is no need to refresh the JComboBoxes after every call to update. Plus think how much overhead that would cause if you did that for every call to update (even when clients aren't changing the contractors name and location in update). My solution was to load them dynamically once at runtime and then I documented my reason why.

[peter wooster]

Originally posted by Frans Janssen:
David,

You will probably get away with combo boxes as long as your other design decisions are consistent with it. As far as I can tell by reading this forum, a lot of people have used them.
E.g. you will need to assume that no new records are created or introduce a mechanism that notifies clients if records are added.
(And what to do if records are deleted?)

I have decided to use regular JTextFields for the following reasons:

avoids problems you just mentioned

matches with how people expect to search (compare e.g. searching in web browsers and word processors)

combo boxes are very annoying when the number of options is large (>10). Remember those combo boxes where you must select your country?

I decided to add an option in my search dialog that allows the user to switch between searching for exact matches and partial matches. I am aware that this won't give me any extra credits, but it adds to the testability of my find() method.

Frans.

I agree with your approach, I don't use combo boxes, since in a real world application the overhead to keep the lists up to date is considerable. I provide exact and prefix searches and AND and OR searches using JTextFieds. This satisfies the requirements to allow users to search by name and/or location.

Just because our client can't add and delete records doesn't mean that those legacy COBOL programs won't do that while our client is running.

[David Abramowicz]

Originally posted by Eric Chang:
You would need to provide a refresh method anyway, because if one Client updates something, you would need the other Client to see the changes, so why not just use the same method to refresh the ComboBoxes?

ACtually I don't use a refresh method. Clients will just have to see upon the next search that the data has changed. I do however "double-check" that the data is what the clients believe it to be before peforming a book (through an additional read operation in the business logic of the book method).

Perhaps you implemented your solution using sockets?

Or have I missed something? Like how to send events from a server to a client through RMI....

Cheers /Dave

[David Abramowicz]

Also, I am still going with the original decision of "freetext with tickbox for exact match" over the "stale/consantly updating JComboBox"... With the freetext version you introduce a tick box, with the JComboBox a really poor cache of some sort.

I mean, I know that people have passed (and with really good scores) with the JComboBox... It just doesn't feel right