Try:

http://doc.qt.nokia.com/4.7/qtime.html [doc.qt.nokia.com]

i would also suggest not to cast an int to QString like you do.

there are several ways to convert it “a nice” way like

or

But for QTime the best way is defenatly the way anselmolsm suggested with .toString() and the formatting.

Actually, with some more debugging, I think I figured out the problem:

The application appears to be frozen because the while loop is running on the same thread as the UI.

Now the problem is that I am building this program on an old computer with only one processor core. I will be deploying it to an even older computer, which surely has only one processor core. How can I do multi-threading on a single processor computer? If I can’t, then is there another workaround?

szh1,

Although you found the problem, please consider what Felix said in his post regarding the use of casts.

As it is a different subject, please move the question about threads to a new discussion =)

you can surly put it to another thread. Having several CPUs only means a several Thread can work at the same time. On a single CPU computer threads are executed sequencialy. Means a bit of Thread A a bit of Thread B a bit of Thread A again etc…

Every thread gets an own short time slice. So in your case two threads would just rotate cpu usage, what would stop freezing your gui. But an important thing here is, you should not request the checkstate in another Thread than gui thread. You should connect the stateChanged signal to a slot in the thread to change an bool to abort the while loop. Manipulating gui elements in a non gui Thread doesnt work. Also you should add a little sleep timer (QThread::wait) no save cpu resources since it will be an old computer like you said.

Okay. Now my code looks like this:

looks better now :) just consider my second post now about the thread, since this is an infinite loop as gui has never time to change the state :)

another “dirty” solution would be to use an timer, that fires every minute to check the two times, since you only compare hour and minute.

I’m sorry Felix, I posted my post at the same time you posted yours, so I didn’t get it until afterwards. Thanks.

You are doing a busy waiting loop threre and even if you put that into a different thread it will use lots of CPU (and drain batteries of your laptop/mobile).

Why don’t you use a QTimer to trigger a slot every x seconds (where x is between 1 and 60 in your case)? And why on earth are you turing the time returned by

Felix: Using a QTimer here is not dirty, it is the right thing to do. Busy waiting has some uses in the kernel of an OS, but should (in an ideal world at least;-) never be necessary in user space applications.

well i dont like to use them, because in documentation is written they might time out late. In this case that could mean the missing of the current value and so the alarm isnt played.

so i would prefer a thread that sleeps a bit in every loop

Sleeping in a thread can miss the deadline, too! You don’t really win anything by adding the complexity of threads.

Just use a timer with a resolution fine enough for your need and use

Please keep in mind that waking up a CPU is expensive, so the shorter your wait interval the more expensive your application gets. This is especially true for battery powered devices: Each wakeup forces the CPU into a high power state!

Well didnt knew that waking up a thread takes so much load. then a timer is of course the better way to do in this case. You never stop learning! ;)

The issue is not about waking up the thread: Your code never put it to sleep! It is busily comparing times as often as possible.

Actually putting the thread to sleep will help. In fact having a timer or a sleeping thread does not really make a difference (when the timer interval and the sleep time are equal).

well i didnt post a complete code solution, i only mentioned a thread that sleeps a bit in every loop