I’ve created class that is just like ThreadWithProgressWindow, except that I update the progress directly from the timer callback. The reason for this is that the code I am running on the thread makes a long (~20 sec) call into a driver, so there’s no opportunity to call setProgress.

This work fine sometimes, but other times, the progress bar updates a few times and then freezes. I’ve tried bumping the thread priority up and down, and also tried different timer intervals, but that has no effect. Any ideas?

I’m using JUCE 1.45.



Well, the only reason it’d freeze would be if some thread is hogging the message thread for a period of time. I guess it all depends on what’s going on in your driver - maybe that’s indirectly calling into some function that does something with messages?


Well, the driver definitely has something to do with it – if I replace the driver call with ::Sleep(20000), then there’s no problem. However, the driver is doing the exact same thing in the cases where it works as in the cases it doesn’t, so I still feel like there’s a bug lurking here. I managed to isolate it a bit further:

I realized that the case that works is when my thread object is created in my app’s initialise override. In the problem cases, the thread’s creation is invoked from an event handler. For instance, if I create my thread object in my override of ApplicationCommandTarget::perform, or filesDropped, then the timer messages mysteriously stop until the thread exits.

Does that make any sense?


Well what happens in the thread creation?


Thanks for humoring me, Jules.

Not sure exactly what you are asking, so please clarify if I answered the wrong question. My class inherits from Thread and Timer, just like ThreadWithProgressWindow. The thread is created like so:

[code] status_type runThread()
startThread (5);
startTimer (100);


	return m_error;

and the Thread::run routine looks something like this:

[code] void run()
MemoryBlock buf;

	if (m_updateFile.loadFileAsData(buf))
			m_error = hugeDriverCall(buf, buf.getSize());

The thread is successfully created, and runs to completion. However, in the case where the object is created post-initialise, the timer callback only fires a couple of times, and then peters out until the thread completes.

The timer callback is also very much like ThreadWithProgressWindow:

[code] void timerCallback()
double ms = 170;

	progress += 1/ms;

	if (! isThreadRunning())
		// thread has finished normally..
		alertWindow.setVisible (false);


Very strange. Well, the first thing I’d do is break it in the debugger when it’s stuck, and see what’s on the message thread’s call stack. Chances are that it’d be obvious from that what’s causing the blockage…


Oh dear. Yes, it is pretty obvious. I had another timer running that was doing naughty things, which I had (in)conveniently forgotten about.

Thanks for pointing me in the right direction!