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
Related
I wrote in C++ a solver for the 8-puzzle game, and now I'm trying to use Qt to give it a GUI.
Basically I have an underlying object of type "Board" which represents the board of the puzzle, and I have organized the GUI as a grid of QPushButton. Then I have a method updateUI which associates to every button the correct text, based on the Board. Something like
for(int i=0; i<Board::MATRIX_DIM * Board::MATRIX_DIM; i++)
{
m_buttons[i]->setText(m_values[i]);
}
In another method (solveGUI) I have
void MainWindow::solveGUI()
{
m_game->solve();
int solutionDepth = m_game->getSolutionDepth();
Move *solutionMoves = m_game->getSolutionMoves();
for(int i=0; i<solutionDepth; i++)
{
Move m = solutionMoves[i];
m_board.performMove(m); /* perform the move on the Board object */
updateUI(); /* should update the GUI so that it represents the Board */
Sleep(1000);
}
}
where the first line (m_game->solve) takes some time. Then I obtain a list of the moves performed, in solutionMoves, and what I would like to do is showing this moves on the board, with some delay between a move and the next one. This method is called by my main, which looks like this:
QApplication app(argc, argv);
MainWindow w;
w.show();
w.solveGUI();
return app.exec();
The result is that the GUI hangs and, after some time, it displays only the solution, completely skipping the moves.
What am I missing? Thank you!
P.S. I don't think I need a different Thread for the solver because I want the solver to run before the solution is displayed. Is it right?
It's app.exec() that actually runs the main loop which handles all events, including displaying GUI. If you want to call solve() before that, it's OK, but if you want to actually display and update GUI before exec(), it's wrong. I'm not sure if it's totally impossible, but it's definitely not the right way to do it.
There are two ways around it. The more canonical way is to redesign a program using a QTimer. Then everything will be smooth and responsive. But that can be tedious sometimes. In your case it should be quite easy, though. Just save the results somewhere, and call a slot using a QTimer object every 1000 seconds - it will have the same effect as your Sleep(), but will keep everything responsive.
The other solution is to call your solveGUI() method after exec() starts its job. It can be done, for example, using QTimer::singleShot():
QTimer::singleShot(0, &w, SLOT(showGUI()));
return app.exec();
Then, before each Sleep(), you should call QApplication::processEvents(), which basically allows you to temporary yield control, processing all pending events, including GUI updates. This approach is somewhat easier, but it's inferior since the GUI still freezes at each Sleep(). For example, if the user wants to exit the application, or if the window is needed to be repainted, it will cause uncomfortable GUI lags.
You're stalling the main thread (which also does the event processing) and rendering it uncapable of responding to keyboard/mouse/window messages.
You should use an asynchronous timer operation instead of the sleep function: use a QTimer to delay showing the next solution and avoid messages being left unanswered for too long.
There is a nice article of methods to keep the GUI responsive during processing loops. if it's not a complicated case I think, just insert QCoreApplication::processEvents(); inside the long processing loops.
try the following:
void MainWindow::Wait(int interval ) {
QTime timer = new QTime;
timer.restart();
while(timer.elapsed() < interval) {
QApplication::processEvents();
}
}
...
for(...) {
//wait 1 second (1000 milliseconds) between each loop run at first
Wait(1000);
...
}
...
not tested yet - but should work (maybe there is some cpu load)!
I want to update list's row or grid's cell in wxwidgets using a loop or with a callback function which is called 10 times in a second. But app waits until the last run of the loop and then shows the last value. I tried refresh() and ForceRefresh() but it doesn't work. how can I achieve this?
for(int i=0; i< 30000; i++) {
list->SetItem(itemIndex, 0, wxString::Format(wxT("%i"),i));
//grid->SetCellValue( 0, 0, wxString::Format(wxT("%i"),i));
}
Edit: What I mean is outputting(printing, streaming) data live like a clock counter or printing progress rate. Using virtual style also does not update it often enough.
I'm not sure what is list and grid in your code but in any case, this is not how you should be doing it. There is no chance that 30000 items fit on your screen at once, so why set the values of all of them? Instead, use a "virtual" wxListCtrl, i.e. with wxLC_VIRTUAL style, or (always "virtual") wxGrid or wxDataViewCtrl and just update your data and refresh the items after they change. The GUI control will take care of showing the updated values of visible items only as fast as it can.
Well I got the complete answer from wxWidgets IRC. I should have refreshed before updating.
for(int i=0; i< 30000; i++) {
list->SetItem(itemIndex, 0, wxString::Format(wxT("%i"),i));
//grid->SetCellValue( 0, 0, wxString::Format(wxT("%i"),i));
MyFrame::Refresh();
MyFrame::Update();
}
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
}
I have QSpinBox which should take only odd numbers, so I've set initial value to 3 and step to 2.
QSpinBox* spinBox = new QSpinBox;
spinBox->setValue(3);
spinBox->setSingleStep(2);
When I'm using spin box arrows to modify value everything is ok. But when I input value from keyboard it can take not odd numbers to.
So is it possible to set validation which fulfills my requirements without inheriting QSpinBox and redefining its validate method?
My current solution is checking in slot if the value is odd:
void MyWidget::slotSetSpinBoxValue(int value)
{
if(value%2 != 0)
{
//call function which takes only odd values
}
else
{
//here I want to show some kind off message that value can only be odd
//call function with --value parameter
}
}
Second question is how to show some tip for QSpinBox? I would like to show tip like tool tip is shown with message that QSpinBox value should be odd. I've found statusTip property in QWidget but cant find example how to use it.
You can connect to the editingFinished signal and fix it:
void Obj::onSpinEditFinished()
{
int val = ui->spinPoints->value();
if(val % 2 == 0)
ui->spinPoints->setValue(val-1);
}
With respect to Richard's comment, I think that ctrl->setKeyboardTracking(false) would get around the checking that would otherwise happen on each keystroke, and allow the validation only to happen at the end.
I think the correct answer doesn't work perfectly. It makes you unable to input values like "12", because the value changed singal will be triggered when "1" was input and it will be corrected to "0" as 1 is an odd numer.
The fix could be using a timer to correct the values in the spinbox. E.g. we restart a timer with (500ms) timout once we received the valueChanged signal(The timer will only triggered once if you type quickly enough). And we check and correct the input in the timers timeout slot.
In python I solved this as follows using the editingFinished property of the spinbox. This only fires a signal when you hit enter or move the focus away from the box. In python I had to pass the function references or the value passed is not the updated one but the one at initialization.:
class SpinboxExample:
def __init__(self)
spinbox = QSpinBox()
spinbox.editingFinished.connect(
lambda value=spinbox.value, set_spinbox_val=spinbox.setValue:
self.value_changed_spinbox(value,set_spinbox_val, set_slider_val)
)
I then had a callback function which checked whether number was odd and if not altered the value in the spinbox to make it odd.
def value_changed_spinbox(self, get_value,set_spinbox_value):
value=get_value()
if value % 2 == 0:
value += 1
set_spinbox_value(value)
Hope that helps.
Well you can make a workaround using the valueChanged() slot:
void MainWindow::on_spinBox_valueChanged(int arg1)
{
if( arg1 % 2 == 0)
{
//for even values, show a message
QMessageBox b;
b.setText("Only odd values allowed!");
b.exec();
//and then decrease the value to make it odd
ui.spinBox->setValue( arg1 - 1 );
}
}
Now if you want to keep the old value in case the used enters an even number, you will have to either inherit from QSpinBox, or use an event filter to catch key press events, and act before the value gets changed.
To show the message when the user hovers his/her mouse over the spinbox, you will need to set the box's toolTip, which holds the string that will be shown:
UPDATE:
If you don't want a message box, you can:
use QStatusBar. It can display messages which only last for some amount of time (that you pass it). The downside of it is that the message will appear on the bar on the bottom of the window, instead of being close to the spinbox.
Place a label under the spinbox. Set the label's text to something like "only odd values are allowed" when the user enters an invalid value, and set an empty string when the user enters a good value. You could also do this dynamically:
The user inputs a wrong value
Create a QLabel with the warning text, and set Qt::WA_DeleteOnClose flag, so the label will delete itself when closed.
Create a QTimer with singleShot, and set it to fire after a couple of seconds (when you want the message to dissapear)
Connect the timer's signal to the label's close() slot. When the timer will expire, the label will be closed, and, thanks to WA_DeleteOnClose, will be deleted.
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.