Maybe not...

Post #309,633 by Another Scott 6/13/09 12:53:35 AM Reply	Maybe not... While the GUI stops being updated for my BC++ program, it does continue to run. When the calculation is done, the GUI updates properly. It's probably due to a stupid way that I release the GUI thread (yield) occasionally during the calculations (rather than learning how to do the calculation in a separate thread). On slower machines, it works fine. Here, something happens after the program loses focus that causes updates to stop. What matters is the calculations continue. I can live with that. So, there's probably not a hardware or driver issue with the T61, but a programming issue. Cheers, Scott. (Who hopes the simulation -> gnuplot program issue can be solved as easily.)
Post #309,639 by folkert 6/13/09 10:55:36 AM Reply	Hmmm... Sounds familiar... Programmers blaming hardware... hardware guys blaming the software devs for sloppy work... Same conundrum as has been forever.
Post #309,642 by Another Scott 6/13/09 11:26:20 AM Reply	"It always worked before, therefore it's not my fault." "Nothing bad has happened yet, therefore I'm Ok." http://xkcd.com/582/ :-) Cheers, Scott. (Who thinks that some programmers may have a lot of work upcoming - fixing old code to run on superfast CPUs.)
Post #310,233 by Another Scott 6/27/09 10:46:30 PM Reply	Application->ProcessMessages() http://www.borlandta...n+processmessages discusses a reasonable work-around without using threads. Cheers, Scott.
Post #310,237 by folkert 6/28/09 9:46:11 AM Reply	Re: Application->ProcessMessages() it looks like a matter of slowing it down a touch.
Post #310,238 by Another Scott 6/28/09 9:56:16 AM Reply	Sorta. It's a matter of letting go of the GUI message queue (or whatever the proper term is) so that the interface messages continue to flow in the OS properly. It's much less granular to do it this way than to add "sleep" messages which do nothing more than slow it down. As I understand it, anyway. :-) Cheers, Scott.

Welcome to IWETHEY!