File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes JComboBoxes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "JComboBoxes" Watch "JComboBoxes" New topic
Author

JComboBoxes

David Abramowicz
Ranch Hand

Joined: Dec 10, 2004
Posts: 56
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
Ranch Hand

Joined: Dec 29, 2004
Posts: 357
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.


    SCJP 1.4, SCJD
    David Abramowicz
    Ranch Hand

    Joined: Dec 10, 2004
    Posts: 56
    Thanks Frans...

    I think I will continue as planned without the JComboBoxes.

    Cheers /D
    Eric Chang
    Ranch Hand

    Joined: Jan 27, 2004
    Posts: 113
    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
    Ranch Hand

    Joined: Dec 31, 2004
    Posts: 59
    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!


    -------------------------------<br />OCP 9i <br />SCJP/SCJD/SCWCD(92%)/SCDJWS<br />XML(IBM Test 141)<br />Who is the next?SCBCD<br />SCBCD/CCNA/CCNP/PMP<br />not sure
    David Abramowicz
    Ranch Hand

    Joined: Dec 10, 2004
    Posts: 56
    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
    Ranch Hand

    Joined: Jan 27, 2004
    Posts: 113
    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
    Ranch Hand

    Joined: Sep 02, 2004
    Posts: 181
    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.


    SCJP 1.4<br />SCJD 1.4
    peter wooster
    Ranch Hand

    Joined: Jun 13, 2004
    Posts: 1033
    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
    Ranch Hand

    Joined: Dec 10, 2004
    Posts: 56
    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
    Ranch Hand

    Joined: Dec 10, 2004
    Posts: 56
    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
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: JComboBoxes
     
    Similar Threads
    Do I follow specification or implement the interface
    JComboBox show just one line.
    Need inputs: Failed SCJD
    Problems with JComboBox additem() method
    Strange criteriaFind