my Main calls DisplayQueryResults, which offers a GUI interface for the user to interact with my Database.
Display Query results give the user the option to insert, delete and update rows. So far I have only implemented Insertion.

When the user chooses to insert a row, a RowEntryFormat object is created and its update function is called.

This in turn creates an InputWindow object (which calls its own createGUI method from its constructor)

Using debug mode and stepping thru everything i found that when we step into the RowEntryFormat.insertion() method, the InputWindow GUI becomes completely unresponsive, and RowEntryFormat keeps sleeping, waiting on the user to enter data in the InputWindow and click ok or cancel, but this won't happen because the GUI doesnt respond. The only thread that seems to be actively running is RowEntryFormat.insertion()

Heres my output to the console:
*******
AWT-EventQueue-0 is about to sleep!!
AWT-EventQueue-0 is about to sleep!!
AWT-EventQueue-0 is about to sleep!!
AWT-EventQueue-0 is about to sleep!!
AWT-EventQueue-0 is about to sleep!!
AWT-EventQueue-0 is about to sleep!!
AWT-EventQueue-0 is about to sleep!!
AWT-EventQueue-0 is about to sleep!!

AND SO ON.............
*******
These printed lines are all from RowEntryFormat.insertion()

why does the GUI become unresponsive? why is RowEntryFormat taking up all the CPU time?

Heres my code... Ive left out a LOT of the details, but included all the important stuff (i hope)

Do you know about threads. If not, best thing is work on some examples on thread before carry on.

Using threads you can handle multiple process at the same time. In your case, UI interactions of users in one thread and process the DB in another thread. Once you read more about Threads, you can clear up more what I say here.

02-24-2009, 09:53 AM

FezKazi

I was using a separate thread for each class until I hit this problem. to make everything simpler i got rid of all the thread code, but it didnt help me...
the problem is exactly the same now with, or without the thread code that I had put in.
so once i fix this problem, i'll put all the threading back in.

somehow, i think the problem is that when i run either of my GUI's they run on the EDT and keep sitting on it... rather than "sharing". thus one is blocking the other.
I suppose i can double check it with : javax.swing.SwingUtilities.isEventDispatchThread()
but im fairly certain theyre just hogging it, by looking at the console output

any ideas?
I am reading all the material at: java.sun.com/ docs /books /tutorial /uiswing /concurrency (Lesson: Concurrency in Swing (The Java™ Tutorials > Creating a GUI with JFC/Swing), but a couple hints would be much appreciated! :)

Quote:

Originally Posted by Eranga

Do you know about threads. If not, best thing is work on some examples on thread before carry on.

Using threads you can handle multiple process at the same time. In your case, UI interactions of users in one thread and process the DB in another thread. Once you read more about Threads, you can clear up more what I say here.

I can't tell exactly what you are doing, but I noticed a Thread.sleep(2000). In addition, your remarks about threads seem suspicious.

*Never* run *any* GUI related code on your own thread. Swing has its own Event Dispatcher Thread (EDT), where *all* GUI code is supposed to run. In addition, you can run your own code in response to GUI events on the EDT, as long as they don't take forever.

*Never* do a Thread.sleep() on the EDT. That prevents the GUI from responding.

A JFrame represents a window. How many applications do you see that have more than one main window? Instead of creating multiple JFrame's, create one and create multiple JPanel's instead. Add the JPanel's to the JFrame, and control their visibility.

Get rid of the threads. I doubt you need them, and they are adding a huge amount of complexity to your code. Updating GUI components from outside the EDT requires special code involving EventQueue.InvokeLater().

You are right.I shouldnt be messing with the EDT thread. i was causing the EDT to sleep, because I allowed a long-running process to take over the EDT (in the insert method, which waits on user input)

I fixed it by adding a new thread... strangely enough threads saved the day.
the new thread went into the insertion function, so that it caused this new thread to sleep and wait on input rather than causing the EDT to sleep and wait. therefore preventing my GUI from becoming unresponsive. wasn't my idea, but some thread friendly guy on another forum gave me this advice and it worked :)

I shall try using multiple Jpanels like you said, it seems like a much neater solution.

I can't tell exactly what you are doing, but I noticed a Thread.sleep(2000). In addition, your remarks about threads seem suspicious.

*Never* run *any* GUI related code on your own thread. Swing has its own Event Dispatcher Thread (EDT), where *all* GUI code is supposed to run. In addition, you can run your own code in response to GUI events on the EDT, as long as they don't take forever.

*Never* do a Thread.sleep() on the EDT. That prevents the GUI from responding.

A JFrame represents a window. How many applications do you see that have more than one main window? Instead of creating multiple JFrame's, create one and create multiple JPanel's instead. Add the JPanel's to the JFrame, and control their visibility.

Get rid of the threads. I doubt you need them, and they are adding a huge amount of complexity to your code. Updating GUI components from outside the EDT requires special code involving EventQueue.InvokeLater().

Anyway, all what you need is nicolas.blancpain.free.fr /Documents/Java/online/ Chapter14.html. Just check with examples there.

02-27-2009, 09:21 PM

Steve11235

Two things.

If it ain't broke, don't fix it.

Waiting for input *should* (has to?) happen on the EDT. Is your thread examining the content of a JComponent and acting when the content changes? If so, at least declare the component with the "volatile" keyword. That makes sure that both threads are looking at the same values.

The "right" way to handle content changes in a JTextComponent or one of its children is to create a custom model object and handle changes through the model. Start in the API for JTextComponent, read the summary information, and then look at getDocument and setDocument.

Or don't, if it ain't broke...

02-28-2009, 08:22 AM

FezKazi

hahha, well, now that youve mentioned some new interesting details, i won't "fix it", ill just create a new project and try out what youre saying.

yes, the thread is waiting on user input, and by extension, we can say that is it waiting on the content of a JComponent to change. I shall try to declare it volatile in my next revision. :)
Although, I have structured it such that the thread that waits on the object is the ONLY thread that actually accesses that object later, so my data is safe.

ive worked with custom models before, and i should probably do that again, taking it slow for now, because im new to threading and database stuff.

thanks, ill look up the documentation :)

03-04-2009, 05:47 AM

Eranga

Quote:

Originally Posted by FezKazi

Thanks for the link! its awesome documentation!

You are welcome. Try to learn something new from there. That make me happy :p