Error getting current time
-
Try:
@
QString currentTime = QTime::currentTime().toString("hh:mm");
@"http://doc.qt.nokia.com/4.7/qtime.html":http://doc.qt.nokia.com/4.7/qtime.html
-
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
@QString::number(QTime::currentTime().hour()) + QString::number(QTime::currentTime().minute();@
or
@QString s = QString("%1%2").arg(QTime::currentTime().hour()).arg(QTime::currentTime().minute());@
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:
@while (this->ui->alarmOn->checkState() == Qt::Checked)
{
// make QStrings for the alarm time and current time
QString alarmTime = (QString)this->ui->alarmTimeEdit->time().hour() + (QString)this->ui->alarmTimeEdit->time().minute();
QString currentTime = (QString)QTime::currentTime().hour() + (QString)QTime::currentTime().minute();
// if the alarm time and current time match ...
if (alarmTime == currentTime)
{
// make a beep sound
QSound::play("alarm.mp3");
}
}@ is my code.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:
@while (this->ui->alarmOn->checkState() == Qt::Checked)
{
// make QStrings for the alarm time and current time
QString alarmTime = QString::number(this->ui->alarmTimeEdit->time().hour()) + QString::number(this->ui->alarmTimeEdit->time().minute());
QString currentTime = QString::number(QTime::currentTime().hour()) + QString::number(QTime::currentTime().minute());
// if the alarm time and current time match ...
if (alarmTime == currentTime)
{
// make a beep sound
QSound::play("alarm.mp3");
}
}@ -
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.
-
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 @ui->alarmTimeEdit->time()@ into a String to compare it to another QString (which happens to be another QTime!)? Both the conversion and the string comparison are needlessly expensive. Why don't you e.g. check that @a.secsTo(b)@ is in an appropriate interval (note: the return value of that may be negative)?
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.
-
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 @a.SecsTo(b) <= 0@ as a condition and you should be fine (if a bit late;-).
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!
-
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).