wood burning stoves 2.0*
The moose likes Swing / AWT / SWT and the fly likes Combo Box Problem Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "Combo Box Problem" Watch "Combo Box Problem" New topic
Author

Combo Box Problem

Sandeep Mukherji
Ranch Hand

Joined: Mar 23, 2008
Posts: 46
Hi,

I have made a combobox(say cb2). The desired functionality is that when i moove my mouse over that cb2 then only it's data should be populated.

I am running a query from the database to populate this cb2 which is like 'select consignee from Con where buyer = ?'. And this '?' value is to be taken from another adjecent combobox cb1(say).
The snap of code is as follows:

action:

Function:


But by this way the data is not being populated to cb2. have anyone any idea please?
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19651
    
  18


Never ever do that. Quite possibly that's exactly the code that is being executed because of an SQL exception. Since you just ignore it, you don't even know.

If you want to catch an exception and do nothing with it, always at least log it; esq.printStackTrace() will suffice. At least that way you know that it is an SQL exception that causes the failure.


However, in this case the problem is most likely the fact that you do nothing with your String[]. You add the items to it, then ignore it. Surely you want to use it for the combo box. Hint: create a new DefaultComboBoxModel and set it for the combo.

And one final note: always close your ResultSets, (Prepared)Statements and Connections when you're done with them.
[ April 23, 2008: Message edited by: Rob Prime ]

SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

What Rob said plus, aside from the really poor design (I'll assume this is a learning process for you) of putting JDBC code directly in with GUI related code, you need to be aware of Swing and Threading issues. Doing any "work" such as database queries on the event dispatching thread (EDT) is a bad idea.



Instead allow Swing to kick off that code when it feels like is the best time.



This will prevent you UI from being unresponsive if the query were to take a long time.


GenRocket - Experts at Building Test Data
Brian Cole
Author
Ranch Hand

Joined: Sep 20, 2005
Posts: 862
Originally posted by Gregg Bolinger:

Instead allow Swing to kick off that code when it feels like is the best time.



This will prevent you UI from being unresponsive if the query were to take a long time.


Unless I have misunderstood what you are doing, this will still
run the body of populateBuyer() on the EDT (just not immediately).

I would think one would want to kick off a new thread for this,
perhaps using SwingWorker depending on how the Vector will be
used after it is populated.


bitguru blog
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Well, I mispoke a bit. You still want UI updates to happen on the EDT, right? You just want to let the EDT determine the best time for it to happen. So I think in this case, it is the right thing to do since the results of the task are updating the ui. I'm all for being proven wrong though.
Brian Cole
Author
Ranch Hand

Joined: Sep 20, 2005
Posts: 862
Originally posted by Gregg Bolinger:
Well, I mispoke a bit. You still want UI updates to happen on the EDT, right? You just want to let the EDT determine the best time for it to happen. So I think in this case, it is the right thing to do since the results of the task are updating the ui. I'm all for being proven wrong though.


Well yes, we do want the UI updates to happen on the EDT. But we don't
want the executeQuery() call to run on the EDT (unless we somehow know
for sure it's going to take almost no time, which is not impossible but I'm
going discount for the remainder of this thread).

By using SwingUtilities.invokeLater() as you suggest, it will all happen
on the EDT, so the GUI will still be frozen for the duration of the call to
executeQuery(). That it happens (slightly) later instead of immediately
probably doesn't even help much, as the repaint() that will be scheduled
to redraw the unpressed button typically won't be scheduled until after
the InvocationEvent that will execute the database query.

So what we want to do is run the database query on another thread, but
update the combo box with the results (which the original code didn't
actually do, but we'll presume that was the intent) on the EDT. There
are many ways to do this, but this is what SwingWorker was designed to
do. Unfortunately, there are a lot of different versions of SwingWorker
floating around, so it has been hard to write example code that works
for everyone. Things are slightly improved now that there is a version
of
SwingWorker included with JDK6. That's the version I'll use for these
examples, but versions for earlier JDKs do exist with varying degrees of
API compatibility.

Now in my experience, the call to executeQuery() will take a while, but
it will be reasonably fast to iterate through the ResultSet it will return. In
that case it's probably easiest to instantiate a new DefaultComboBoxModel
(and populate it) in the other thread, then afterwards replace the combo
box's model in the EDT:


It is possible, though, that iterating through the ResultSet could
take a while. (Theoretically, each call to rs.getString() could even
be pulling data over the network.) If this is the case, the the previous
code still works fine. But if we want the user to be able to see the
first few Strings without having to wait while we process the rest of
them, then we could use SwingWorker's publish()/process() mechanism
to append each String individually (or in small clumps) on the EDT:


We can invoke these via
new PopulateComboBoxModelWorker(comboBoxConsignee0).execute(); or
new IncrementalPopulateComboBoxWorker(comboBoxConsignee0).execute();

[edit: Please note that I haven't actually tried these examples. I may have made typos and/or more serious errors.]
[ April 23, 2008: Message edited by: Brian Cole ]
Sandeep Mukherji
Ranch Hand

Joined: Mar 23, 2008
Posts: 46
Hi Everyone,
I have followed your valuable suggessions and now the desired output is comming. Thanks to all of you. Here is the snap of code that I changed.


Method:


Moreover, I have not closed the connection as through out the module I am using the same connection. If I close it here, then next time I have to open it again. If I am wrong, please suggest.
Brian Cole
Author
Ranch Hand

Joined: Sep 20, 2005
Posts: 862
Originally posted by Sandeep Mukherji:
I have followed your valuable suggessions and now the desired output is comming. Thanks to all of you. Here is the snap of code that I changed.


It's not clear from your code, but if defaultComboBoxModel is the current model of your JComboBox, then calling defaultComboBoxModel.addElement() should only be happening on the EDT. In your code it's happening on a non-EDT thread, which will cause the combo box's event listeners to be called on a non-EDT thread, which would be a violation of Swing's single-threaded rule. If it's working ok for you, then fine, but this was the point of those SwingWorker examples.

Moreover, I have not closed the connection as through out the module I am using the same connection. If I close it here, then next time I have to open it again. If I am wrong, please suggest.


Don't close the Connection if you plan to use it again. You should still close the ResultSet and the PreparedStatement, though.
 
Don't get me started about those stupid light bulbs.
 
subject: Combo Box Problem
 
Similar Threads
about variable persistence...
help!! on dynamic select box - 2
JDBC - Retriving data from Database
help!!! java.security.access controlException
help on dynamic select box