I have a for-loop which is setting the value of the progress bar on every iteration.
The for-loop executes the setProgress-method described here:
void setProgress(int progStep){
progressBar->setValue(progStep);
progStep++;
QTextStream(stdout) << progStep << " " << progSum << endl;
}
I can print out that last line, so the method is executed but the GUI of the progress bar is not updated every time.
When I have a maximum value of 25 (and min 0), the method prints every number from 0-25. My goal is to have the progress bar to then show 25 different percentage values during this execution.
Structure:
for(.....) {
.....
.....
setProgress(progStep);
}
What actually happens is that it updates the progress bar with percentage values about 2-3 times. The for-loop takes about 30 seconds so it should definitely be able to make 25 percentage updates.
How can I solve this?
You have to call QApplication::processEvents() after calling setProgress(progStep), to let the GUI thread update the progress bar.
It seems you're simply calling several time setProgress() without running the event loop, thus the GUI is not updated.
Call QApplication::processEvents() after setProgress() in order to update the GUI.
If you want setProgress() to update the GUI whatever the situation is, you can call QApplication::processEvents() in the body of setProgress(), after the progress bar update part.
Related
My QLabel is not updating from slot. I run sender class in separate thread using QObject::moveToThread:
QThread* serviceThread = new QThread;
service = new ExportService();
connect(service,SIGNAL(stateChanged(Service::ServiceState)),
this,SLOT(statusChanged(Service::ServiceState)));
service->moveToThread(serviceThread);
serviceThread->start();
Service object send states by emiting signal with ServiceState enum value, this signal is captured by QDialog slot:
void Dialog::statusChanged(Service::ServiceState s)
{
switch (s) {
case Service::IDLE:
qDebug() << "Idle";
ui->label->setText("Service send response succesfully.");
break;
case Service::REQUESTING:
qDebug() << "Requesting";
ui->label->setText("Requesting response from service...");
break;
case Service::ERROR:
qDebug() << "Error";
ui->label->setText("Error. Cannot get response from service.");
break;
default:
break;
}
}
After operation on the object which emits a signal twice, the first time with value of Service::REQUESTING and second time with value of Service::IDLE my QLabel change text only to "Service send response succesfully.". In the console I can see that qDebug() << "Requesting"; works so the state changed successfully.
After comment out ui->label->setText("Service send response succesfully."); label has changed to requesting state but after the whole operation was done ie i see "Requesting" in console then "Idle" and after that QLabel has changed.
What should I do if I want to see QLabel changing in realtime?
First, try adding update() after setText(), chances are setText() doesn't automatically schedule a repaint() for the QLabel, if it works then problem solved.
However, for update() function:
http://doc.qt.io/qt-4.8/qwidget.html#update
void QWidget::update()
This function does not cause an immediate repaint; instead it
schedules a paint event for processing when Qt returns to the main
event loop. This permits Qt to optimize for more speed and less
flicker than a call to repaint() does.
> Calling update() several times normally results in just one
paintEvent() call.
which basically says, if you call them too frequently and some of them will be optimized away.
If this is not the desired behaviour, try adding a forced repaint() after setText(), or using a timer to schedule periodical forced repaints.
http://doc.qt.io/qt-4.8/qwidget.html#repaint
UPDATE
As is mentioned in the comment, forcing repaint() isn't good solution.
This answer is intended to provide an analysis of the cause of the code's behaviour and the "forced repaint()" suggestion is more of a way to verify this analysis than a solution to the problem.
However, without further information on the purpose of the program, it's very difficult to provide further suggestions.
The status change from requesting to idle happens quickly. The text "Requesting response from service..." is not on the label long enough for the eye to see it.
The fact that "Requesting ..." is in the debug output is proof of this, but if you want more proof there are other things you could do:
use a counter that counts each time the statusChanged() function is called and display this either in the same label as the status text (in addition to the status text) or a different label.
add a high accuracy timer output to the debug outputs - see how close together the status changes are.
use a couple of check boxes, one for idle status and one for requesting status. Change their state when the appropriate status is received. That is whne the first Idle is received set the check box to checked. When the next idle is received toggle it to unchecked.
I would just accept that the debug outputs are telling the truth and move on.
I'm selecting and loading some big Dicom files on my program. The whole loading process takes a long time(depends on the number of files, but the whole process can take more than minutes if the files are many). I want show a "waiting symbol" or something like that when the file uploading is going on. I searched for it, but I didn't get anything definite.
My code for the selection and uploading part is as below:
void MainWindow::showTheSelectedList()
{
QFileDialog * fileDialog = new QFileDialog(this);
fileDialog->setFileMode(QFileDialog::ExistingFiles);
QListView* list = fileDialog->findChild<QListView*>("listView");
if(list)
{
list->setSelectionMode(QAbstractItemView::MultiSelection);
}
QTreeView* tree = fileDialog->findChild<QTreeView*>();
if(tree)
{
tree->setSelectionMode(QAbstractItemView::MultiSelection);
}
if(fileDialog->exec())
{
if(fileDialog->selectedFiles().size()>0)
{
int listsize=stringList.size();
for(int i=0;i<listsize;i++)
{
// get the name of the file
// check if the file is dicom
// upload if the file is dicom
// after uploading, get the pixel data of that file
// use the pixel data and make a icon out of it
//then insert the icon in an a QTablewView
}
}
}
//show the QtableView
}
Could you please instruct me where and how I can show the waiting sign or symbol while the uploading part is running?
Thanks
I think you are looking for the QProgressBar class. The documentation makes it clear below. You will need to set up the minimum and maximum values, and it will do the job for you.
The QProgressBar widget provides a horizontal or vertical progress bar.
A progress bar is used to give the user an indication of the progress of an operation and to reassure them that the application is still running.
The progress bar uses the concept of steps. You set it up by specifying the minimum and maximum possible step values, and it will display the percentage of steps that have been completed when you later give it the current step value. The percentage is calculated by dividing the progress (value() - minimum()) divided by maximum() - minimum().
You can specify the minimum and maximum number of steps with setMinimum() and setMaximum. The current number of steps is set with setValue(). The progress bar can be rewound to the beginning with reset().
If minimum and maximum both are set to 0, the bar shows a busy indicator instead of a percentage of steps. This is useful, for example, when using QNetworkAccessManager to download items when they are unable to determine the size of the item being downloaded.
I do not think much more details can be provided based on the question as the worker loop seems to be commented without actual code being provided in there, but this documentation should make it clear either way.
Note that I would personally even move the worker loop into an own worker thread if it is that hefty that it deserves a progressbar. As for the progressbar, you would probably write something like this:
QProgressBar bar(this);
bar.setRange(maximum, maximum);
bar.setValue(minimum);
bar.show();
Dialog box:
My novice suggestion would be to use progress bar inside your for loop and increment the progress bar as each file finishes loading.
Let me know if you need more detail.
I have a horizontal layout and when user enters a number, I am adding that number of widgets (which contain picture) to that layout.
void MainWindow::on_pushButton_2_clicked()
{
for(int i=0; i<count; i++)
{
ui->horizontalLayout_4->addWidget(label);
}
}
For example, if user enters 100, this function loop 100 times and after the function finishes its execution, it adds 100 widgets at the same time.
But I want function to add widgets step bu step.
For example, when i=0, it adds, when i=1 it adds.. And user should see the adding items step by step.
Is it possible?
In on_pushButton_2_clicked you could start a QTimer, connected to a slot that adds a single widget. Give the timer a reasonable timeout so that you can "see" each widget being added. Then use a counter in your class so that you know when to stop the timer. So, if the user entered 10, set the counter to 10 and subtract one from it each time the timer is fired. Stop the timer when the counter reaches zero.
i would implement a timer , that gives the UI a chance to refresh between each shot
I have a custom widget which displays many items in rows:
void update(){ //this is a SLOT which is connected to a button click
QVBoxLayout *layout = this->layout();
if (layout == NULL){
layout = new QVBoxLayout;
this->setLayout(layout);
} else {
QLayout_clear(layout); //this is a function that I wrote that deletes all of the items from a layout
}
ArrayList *results = generateData(); //this generates the data that I load from
for (int i = 0; i < results->count; i++){
layout->addWidget(new subWidget(results->array[i]));
}
}
The problem is that there are about 900 items and a profile reveals that simply adding the child object to the layout takes 50% of the time (constructing takes the other 50%). Overall it takes about 3 seconds to load all of the items.
When I click on the button to load more data, the entire UI freezes for the 3 seconds and then all of the items appear together when everything is done. Is there a way to progressively load more items as they are being created?
The first trick is, as Pavel Zdenek said, to process only some of the results. You want to process as many together so that the overhead (of what we're going to do in the next step) is low, but you don't want to do anything that would make the system seem unresponsive. Based on extensive research, Jakob Nielsen says that "0.1 seconds is about the limit for having the user feel that the system is reacting instantaneously", so as a rough estimate you should cut your work into roughly 0.05 second chunks (leaving another 0.05 seconds for the system to actually react to the user's interactions).
The second trick is to use a QTimer with a timeout of 0. As the QTimer documentation says:
As a special case, a QTimer with a timeout of 0 will time out as soon
as all the events in the window system's event queue have been
processed. This can be used to do heavy work while providing a snappy
user interface.
So that means that a timer with a timeout of 0 will be executed next, unless there is something else in the event queue (for instance, a mouse click). Here's the code:
void update() {
i = 0; // warning, this is causes a bug, see below
updateChunk();
}
void updateChunk() {
const int CHUNK_THRESHOLD = /* the number of things you can do before the user notices that you're doing something */;
for (; i < results->count() && i < CHUNK_THRESHOLD; i++) {
// add widget
}
// If there's more work to do, put it in the event queue.
if (i < results->count()) {
// This isn't true recursion, because this method will return before
// it is called again.
QTimer::singleShot(0, this, SLOT(updateChunk()));
}
}
Finally, test this a little bit because there's a gotcha: now the user can interact with the system in the "middle" of your loop. For instance, the user can click the update button while you're still processing results (which in the above example means that you would reset the index to 0 and reprocess the first elements of the array). So a more robust solution would be to use a list instead of an array and pop each element off the front of the list as you process it. Then whatever adds results would just append to the list.
#Adri is generally right, the twist is that the "another thread" must be the UI thread again. The point is to allow UI thread's event loop to keep spinning. The fast and dirty way is to put QCoreApplication::processEvents() in your for() cycle. Dirty because, as the doc says, it should be called "ocassionally". It might have some overhead even if there are no UI events, and you are messing Qt's performance optimization as to when and how often spin the loop. Slightly less dirty would be to call it only ocassionally, after chunks of result.
Cleaner and proper way is to create a private slot, which pops one result element (or chunk, to speed up), adds to the layout and increments index. Then it will recall itself until end of results. The gotcha is to define connect() with forced connection type Qt::QueuedConnection, so it will get deferred after already queued UI events (if any).
And because you run in only one thread, you don't need any locking over results.
Adding example per OP's request:
While #TomPanning solution is correct, it kind of hides the real solution behind QTimer which you don't need - you don't need any timing, you just need a specific non-timer behavior upon specific parameter value. This solution does the same thing, minus the QTimer layer. On the other hand, #TomPanning has a very good point about the plain ArrayList not being very good data storage, when interaction can happen in between.
something.h
signals: void subWidgetAdded();
private slots: void addNextWidget();
ArrayList* m_results;
int m_indexPriv;
something.cpp
connect(this,SIGNAL(subWidgetAdded()),
this,SLOT(addNextWidget(),
Qt::QueuedConnection);
void addWidget() {
// additional chunking logic here as you need
layout->addWidget(new subWidget(results->array[m_indexPriv++]));
if( m_indexPriv < results->count() ) {
emit subWidgetAdded(); // NOT a recursion :-)
}
}
void update() {
// ...
m_results = generateData();
m_indexPriv = 0;
addNextWidget(); // slots are normal instance methods, call for the first time
}
Here is the problem:
I want to show a progress bar (just as a text like "Remaining 35%...") during a C++ function execution. I've done the first part which is the progress bar but the problem is how do I show the progress bar during the other functions execution?
I just want to start showing the bar when execution enters a specific function and reach 100% when leaving the function.
How do I do this in C++? any suggestion?
thanks in advance!
/Niklas
Use a separate thread to update the progress bar. That should give "near real" progress of your application.
There are two things to consider. First is, when do you update your progress bar? In general this can be done by dividing the work your function does into ticks, and then use a tick-count that you increase every time the function has advanced one tick. One example would be this:
void SomeFunction() {
for ( int i = 0; i < 1337; i++ ) {
// do important stuff
ProgressBar.IncreaseTickCount();
}
}
The caller would then do something like this:
ProgressBar.SetNumberOfTicks( 1337 );
SomeFunction();
This way, the progress bar would be able to recalculate its value at every iteration of the loop. How this is presented on the screen depends on your GUI-Framework. As has been suggested by #Amit and the comments to his answer, you will most likely have the function run in a worker-thread, and the UI-thread will update the progress bar continuously. In this case make sure that the tick-counter is thread-safe.
A simple text-based stdout tic style progress bar can be found in a single file at ezProgressBar
. You can wrap it in a thread if you'd like. One nice feature is that is does minimal printing to a single line so overhead is pretty cheap and you don't need to play games with finding the magic "reset cursor to beginning of line" character like '\r'.