aspose file tools*
The moose likes Java in General and the fly likes Rapidly calling inner thread classes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Rapidly calling inner thread classes" Watch "Rapidly calling inner thread classes" New topic
Author

Rapidly calling inner thread classes

Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Here's a tricky problem, which I think may be a thread issue, for reasons noted below (but I could be wrong, so I'm posting in this forum).
I have a table (JClass LiveTable, but I think that's moot). The last price field in the table is constantly changing. When it changes, I need to make the text green, if its equal to or above a certain (fixed) value, opening value, and red if its below it.

The listing corresponds to a "line" of data backing the table. The PriceWatcher has the two numbers, the last value and the opening value.
Assuming the ticks aren't null (they never are except when I first create the table), I select a style, red or green, for the text. It seems to work.
But we want to make it even better, by first bolding the text for 1 second after the price changes. The modified code to do this is below (at the bottom of the method.

I basically save off the styles (either for red or green) and start the thread. The problem is, it doens't work correctly. The colors are no longer consistent, i.e it's red when it should be green and visa-versa. However, when I look at the comparison in the print statement, it is correct!
My theory is, because the comparison is correct, and because it work without the bolding, the problem is in the thread. Specifically, I'm thinking I'm not understanding something about how the thread works wrt the method. The changes are happening very quickly, i.e. a few different rows will be changed in under a second. I'm thinking somehow the method is getting called multiple times, but there is a single row value be shared across them. (I'm not 100% certain what it means to make the row variable final in the method, but that seemed necessary to get the thread to accept the value.)
Any thoughts, ideas, or explainations?
--Mark
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
Any thoughts, ideas, or explainations?
I hate to show my ignorance here but I'm not sure what a JClass LiveTable is. Is it a swing component? If so, that is probably where the problem lies. Swing components are not thread safe. Any change to a swing component should be made on the swing dispatch thread. Any time I run across this problem, I use a javax.swing.Timer, set the delay to 1 milli and make my changes on the actionPerformed() callback. Just a possibility.


Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
JClass LiveTable is a proprietary GUI component made by KLGroup (now Sitraka (now Quest Software :-p )). It does ultimately extend javax.swing.JComponent, however I've been following their examples and assume they took care of all that.
Oh yeah, I vaguely remember using some special Swing event thread when I have to do some GUI events about once a year. But since the examples don't use it, I'm hesitant to.
--Mark
[ May 21, 2003: Message edited by: Mark Herschberg ]
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
You can try something like this:
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
OK, yep, its a swing threading issue. They never noted that in their docs, and for some reason I was under the impresison that their refresh listener methods might take care of this for me. Thanks for pointing this out Michael.
So this leads me to another question. I've done this kinda stuff very rarely. I'm not sure what the best way is to approach my current situation.
Here's what's going on. I have two types of datasets, which I'll describe below. For each type there is a JMS receiver listening to a JMS topic/queue and is has an onMessage() method which is invoked. This method passes the data packet on to a TableModel (it's the JClass LiveTable table model, but its effectively like a JTable and its table model). The table model is then updated, possibly with some caluclations before hand (explained below).
One type of table is a "news table." In this table, we basically simply add new rows to the table and never change existing rows. I may need to have the table resort itself each time (although this is done internally by LiveTable, which only exposes a sort method call). This type of table gets new data every few seconds.
The other type of table is a stock table. This table updates once a second or even up to 5-6 times a second. It occasionally adds or removes a row, but usually just changes the data in the cell, and in some cases the cell color (we have stoplighting functionality). There is usually some degree of calculations going on with doubles (mostly + - * /) and also locating the row to be updated.
Most question is, for each type of table, what should be done in the swing thread and how? The onMessage() method basically makes a single method call to kick off all the work. I can do that in an invokeLater() method or I can create a SwingWorker. I can also do all the calculations in the onMessage() thread and only do the update usng either an invokeLater() method or using a SwingWorker. How do I decide which is most appropriate?
Thanks for any help.
--Mark
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
I guess it really comes down to what works. You aren't alone in your disdain for GUI programming, I'd by far rather be manipulating data than creating a pretty UI. I would try invokeLater() first and see if that accomplishes your task. Just use the DelayThread you posted above. I would also say only do the update on the invokeLater() call because that seems more in keeping with the MVC paradigm. You may want to post this in the Swing forum as well, I'm sure there are much more experienced GUI programmers that could take a look at this.
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Now that we're certain that it is a Swing issue, can you move this to the Swing forum for me? Thanks.
--Mark
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
OK.


"I'm not back." - Bill Harding, Twister
 
 
subject: Rapidly calling inner thread classes