I have a wxwindows application and in the onclick event of a button, I have a very long process, for example I have something such as this:
for(int i=1;i<100;i++)
{
sleep(1000);
gaugeProgress->SetValue(i);
*textOutput<<i;
}
Running this code, stops UI to be responsive. I add
Refresh();
Update();
just after
*textOutput<<i;
but it did not work.
is there any way that I can pump the events?
I am working on Windows using VS 20102
In those cases I use wxYield() like this:
for(int i = 1; i < 100; i++)
{
// sleep() freezes the program making it unresponsible.
// sleep(1000);
gaugeProgress->SetValue(i);
*textOutput << i;
// wxYield stops this function execution
// to process all the rest of stocked events
// including the paint event and resumes immediately.
wxYield();
}
This stops the current process and lets the application to process the message stack like the paint event.
But I think that the proper way to do this should be using threads.
You can add a wxTimer member in your wxwindows, start it in the window constructor, as such:
m_timer.Start(1000);
then capture the timer event with a function, for example:
void mywindow::OnTimer(wxTimerEvent& event)
{
Refresh();
Update();
}
Make sure you connect the event to the wxTimer member.
Related
I want to implement a GUI that receives messages from an external device. The "advancedReceiveExample" is waiting for messages. Once it has received one, it does stuff with it, saves it and terminates.
I want to make my function wait for new messages after receiving one as long as the button is toggled.
I have tried this so far:
void MainWindow::on_pushButton_clicked()
{
if (ui.pushButton->isChecked()) {
ui.pushButton->setText("Stop Receiving");
ui.label_3->setText("Receiving...");
advancedReceiveExample(ui.comboBox->currentIndex() + 1);
}
else
{
ui.pushButton->setText("Start Receiving");
ui.label_3->setText("Not Receiving");
}
}
This works perfectly fine but as mentioned above it only receives one message. If I do that:
void MainWindow::on_pushButton_clicked()
{
if (ui.pushButton->isChecked()) {
ui.pushButton->setText("Stop Receiving");
ui.label_3->setText("Receiving...");
while (1)
{
advancedReceiveExample(ui.comboBox->currentIndex() + 1);
}
}
else
{
ui.pushButton->setText("Start Receiving");
ui.label_3->setText("Not Receiving");
}
}
it blocks the function because the state of the button can only be change after the function "on_pushButton_clicked()" has terminated.
Visual Studio 2019
C/C++
EDIT: Okay, I have understood the problem of blocking the thread. Multithreading might be the right option but I am very unexperienced regarding this topic. The <QThread> could be possible. How would you use it?
Do you have suggestions which other library could be used?
Note QT is event-based. If you keep your computer busy inside some function without returning to the main loop frequently, your GUI will freeze.
What you need to do is slice your action that you want to do into small bits that can repeatedly return to the main loop in order to keep the GUI responsive. (Another method yould be to swap out your action into a separate thread and handle it in parallel, killing the thread when the button is released)
Probably the simplest method to do what you want is with timers that you arm in the PushButton::clicked slot, and then check in the timer event whether the button is still pressed, and, if yes, do a bit of your action, save state and re-arm the timer to have you return.
Something along the lines of the following pseudo code should work and execute what you want to do in slices every 10ms:
MainWindow::onPushButtonClicked () {
// do the action, or, alternatively, start a
// parallel thread that does it
do_a_bit_of_action();
// sets up a timer to call onTimer after 10ms
QTimer::singleShot (10, this, SLOT(onTimer()));
}
MainWindow::onTimer () {
// check if button is still held down
if (pushButton.down) {
// re-arm timer
Timer::singleShot (10, this, SLOT(onTimer()));
// do some more action bits
do_a_bit_of_action();
}
else {
// kill optional background thread here
}
}
You can try it with:
while(ui.pushButton->isChecked()){
*your function*
}
I have two GTK windows
Normal (main) window that runs animation, draws stuff in callback registered by gtk_widget_add_tick_callback().
At some point secondary window is created that runs modal loop:
void show_modal()
{
GtkWindow* gw = gtkwindow(this);
if( parent() )
gtk_window_set_transient_for(gw, gtkwindow( parent() ));
gtk_widget_show(GTK_WIDGET(gw));
gtk_window_set_modal(gw,TRUE);
gtk_window_set_keep_above(gw,TRUE);
this->update_window_state(gool::WINDOW_SHOWN);
while( this->is_valid_window() )
{
if(this->_window_state == WINDOW_HIDDEN) break;
if(this->_window_state == WINDOW_STATE_NA) break;
gtk_main_iteration(); // gtk_main_iteration_do(true);
}
}
Problem: Animation in main window works fine until show_modal() is invoked. It appears as gtk_main_iteration(); blocks ticks added by gtk_widget_add_tick_callback() function. As soon as I close secondary window and so while() {gtk_main_iteration();} loop exits then animations in main window start running again.
Any idea of how to make "animation friendly" modal loops in GTK?
UPDATE: it appears as gtk_main_iteration(); blocks not only ticks but any updates of any windows other than "current" - they are simply frozen. What is the reasoning of such GTK behavior?
UPDATE #2:
gtk_dialog_run(); behaves exactly as gtk_main_iteration(); - locks any updates on any window in process other than active window.
It seems to be by definition: link
gboolean gtk_main_iteration (void);
Runs a single iteration of the mainloop. If no events are waiting to be processed GTK+ will block until the next event is noticed. If you don’t want to block look at gtk_main_iteration_do() or check if any events are pending with gtk_events_pending() first.
The explanation suggests to use gtk_main_iteration_do(FALSE) if you don't want blocking:
gboolean gtk_main_iteration_do (gboolean blocking);
Runs a single iteration of the mainloop. If no events are available either return or block depending on the value of blocking:
TRUE if you want GTK+ to block if no events are pending
As for gtk_dialog_run: it also blocks by design link
gint gtk_dialog_run (GtkDialog *dialog);
Blocks in a recursive main loop until the dialog either emits the “response” signal, or is destroyed.[...]
I read about people solving this using multiple threads: handle the GUI in the main thread and do background work in another one. There's an article about it here that might be useful.
I assume that show_modal is called from a callback or other activity in main context. You could try adding your modal window into main context using invoke or signal_idle.
This way execution of show_modal will end.
#include <gtkmm.h>
#include <string>
int main()
{
auto Application = Gtk::Application::create();
Gtk::Window window;
Gtk::Window* window2;
Gtk::Button button;
window.add(button);
//I hope timeout behaves similar to ticks. I have no idea how animations in GTK work
int i=0;
Glib::MainContext::get_default()->signal_timeout().connect([&]()->bool{
button.set_label(std::to_string(i++));
return true;
}, 1000);
button.signal_clicked().connect([&]{
Glib::MainContext::get_default()->invoke([&]()->bool{
window2 = new Gtk::Window;
window2->set_modal(true);
window2->set_keep_above(true);
window2->signal_delete_event().connect([&](GdkEventAny* any_event)->bool{
delete window2;
return false;
});
window2->show_all();
return false;
});
});
window.show_all();
return Application->run(window);
}
I'd like to ask some advice on how handle an Embarcadero CB10.1 issue with re-entrancy. Compiled in Debug configuration with "Disable all optimizations" set to true. I'm running on Win7.
I have a simple test case. A form with two buttons. The OnClick event handler for each button calls the same CPU intensive function. Below is the header file followed by the program file.
#ifndef Unit1H
#define Unit1H
//---------------------------------------------------------------------------
#include <System.Classes.hpp>
#include <Vcl.Controls.hpp>
#include <Vcl.StdCtrls.hpp>
#include <Vcl.Forms.hpp>
//---------------------------------------------------------------------------
class TForm1 : public TForm
{
__published: // IDE-managed Components
TButton *Button1;
TButton *Button2;
void __fastcall Button1Click(TObject *Sender);
void __fastcall Button2Click(TObject *Sender);
private: // User declarations
double __fastcall CPUIntensive(double ButonNo);
double __fastcall Spin(double Limit);
public: // User declarations
__fastcall TForm1(TComponent* Owner);
};
//---------------------------------------------------------------------------
extern PACKAGE TForm1 *Form1;
//---------------------------------------------------------------------------
#endif
//---------------------------------------------------------------------------
#include <vcl.h>
#pragma hdrstop
#include "Unit1.h"
//---------------------------------------------------------------------------
#pragma package(smart_init)
#pragma resource "*.dfm"
TForm1 *Form1;
//---------------------------------------------------------------------------
__fastcall TForm1::TForm1(TComponent* Owner)
: TForm(Owner)
{
}
//---------------------------------------------------------------------------
void __fastcall TForm1::Button1Click(TObject *Sender)
{
Button1->Caption = "Pushed";
double retv = CPUIntensive(1);
Button1->Caption = "Button1";
if (retv) ShowMessage("Button1 Done");
}
//---------------------------------------------------------------------------
void __fastcall TForm1::Button2Click(TObject *Sender)
{
Button2->Caption = "Pushed";
double retv = CPUIntensive(2);
Button2->Caption = "Button2";
if (retv) ShowMessage("Button2 Done");
}
//---------------------------------------------------------------------------
double __fastcall TForm1::CPUIntensive(double ButtonNo)
{
//
static bool InUse = false;
if (InUse) {
ShowMessage("Reentered by button number " + String(ButtonNo));
while (InUse) {};
}
double retv;
InUse = true;
retv = Spin(30000); // about 9 seconds on my computer
//retv += Spin(30000); // uncomment if you have a faster computer
//retv += Spin(30000);
InUse = false;
return retv;
}
//---------------------------------------------------------------------------
double __fastcall TForm1::Spin(double Limit)
{
double k;
for (double i = 0 ; i < Limit ; i++) {
for (double j = 0 ; j < Limit ; j++) {
k = i + j;
// here there can be calls to other VCL functions
Application->ProcessMessages(); // added so UI would be responsive (2nd case)
}
}
return k;
}
//---------------------------------------------------------------------------
-
1st case : the code shown but WITHOUT the call to ProcessMessages().
When I run this and click on button 1, CPU usage jumps up to almost
100% for about 9 seconds. The form becomes unresponsive during this time.
Can't move the form or click on button 2.
That works as I would expect.
2nd case : To make the form responsive to the user during the CPU
intensive function, I added the ProcessMessages() call as shown.
Now, I can move the form around and click on other buttons.
That is not always good, because I could click on button 1 again or
even click on button 2. Either click would fire off the CPU intensive function again. To prevent the CPU intensive function from running the second time, I made a static boolean flag "InUse". I set that
when the function starts and clear it when the function completes.
So I check the flag when I enter the CPU intensive function and
if its set (it must have been set by a previous click on a button), I
show a message and then wait for the flag to clear.
But the flag never clears and my program loops on the 'while' statement
forever. I would like the program to just wait for the CPU intensive function
to complete and then just run it again.
If I set a breakpoint in the Spin() function after I hit the deadlock,
it never fires indicating that neither event is executing.
I know the VCL is not thread safe but here, all of the processing takes
place in the main thread. In my actual code, there are many calls to
VCL functions so the CPU intensive function has to remain in the main
thread.
I considered Critical Sections and Mutexes but since everything is in
the main thread, any use of them does no blocking.
Maybe its a stack issue? Is there a solution that lets me handle this without the deadlock?
2nd case : To make the form responsive to the user during the CPU intensive function, I added the ProcessMessages() call as shown. Now, I can move the form around and click on other buttons.
That is always the wrong solution. The correct way to handle this situation is to move the CPU intensive code to a separate worker thread, and then have your button events start a new instance of that thread if it is not already running. Or, keep the thread running in a loop that sleeps when it doesn't have work to do, and then have each button event signal the thread to wake up and do its work. Either way, NEVER block the main UI thread!
That is not always good, because I could click on button 1 again or even click on button 2. Either click would fire off the CPU intensive function again.
To prevent the CPU intensive function from running the second time, I made a static boolean flag "InUse". I set that when the function starts and clear it when the function completes.
A better way would be to disable the buttons while the work is being performed, and re-enable them when finished. Then the work can't be re-entered to begin with.
But, even if you keep your flag, your function should just exit without doing anything if the flag is already set.
Either way, you should display a UI displayed telling the user when the work is in progress. This becomes easier to manage if the work is done in a separate thread.
So I check the flag when I enter the CPU intensive function and if its set (it must have been set by a previous click on a button), I show a message and then wait for the flag to clear.
But the flag never clears and
That is because you are just running an endless loop that does nothing, so it doesn't allow the code to progress any further. And certainly not finish the existing work and reset the flag.
The smallest fix you can make to your existing code without re-writing it is to change CPUIntensive() to use return 0 instead of while (InUse) {} when InUse is true. That will allow a call to ProcessMessages() to exit and return control back to the previous CPUIntensive() call that is waiting to finish running.
I know the VCL is not thread safe but here, all of the processing takes place in the main thread.
Thay is a BIG mistake.
In my actual code, there are many calls to VCL functions so the CPU intensive function has to remain in the main thread.
That is not a good enough reason to perform the work in the main thread. Move it to a worker thread, where it belongs, and have it sync with the main thread whenever it needs to access the UI. Do as much work as possible in the worker thread, and sync only when absolutely necessary.
My question was not about threads but rather how to prevent multiple clicks of buttons from being acted upon while at the same time, not having the form become unresponsive. All of this in my single threaded VCL program. As I saw, when I did not have the call to ProcessMessages(), the form became unresponsive once a button was clicked (until the event handler completed its processing). When I added the call to ProcessMessages(), the form was TOO responsive in that mouse clicks caused event handlers to run EVEN IF the same mouse click's event handler was only part way complete when it called ProcessMessages(). The event handlers are not re-entrant but Windows/VCL was re-entering them when the second mouse button was pushed.
I needed a way to defer processing of mouse button events while at the same time processing messages so the form did not appear unresponsive.
ProcessMessages() was not going to work here. It dispatched every message that it found in the message queue.
I found a way to go part way, a version of ProcessMessages that checked the message queue and if a non-mouse button message was there, dispatch it. Otherwise, leave the messsage in the queue for later.
Here is the code I ended up with to replace the call to ProcessMessages:
// set dwDelay to handle the case where no messages show up
MSG msg;
DWORD dwWait = MsgWaitForMultipleObjects(0, NULL, FALSE, dwDelay, QS_ALLINPUT);
if (dwWait == WAIT_TIMEOUT) { // Timed out?
// put code here to handle Timeout
return;
}
// Pump the message queue for all messages except Mouse button messages
// from 513 to 521 (0x0201 to 0x0209)
bool MsgAvailable;
while (true) {
MsgAvailable = PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE);
if (!MsgAvailable) break; // no messages available
if (msg.message <= WM_MOUSEMOVE) {
// Message from WM_NULL to and including WM_MOUSEMOVE
GetMessage(&msg, NULL, WM_NULL, WM_MOUSEMOVE);
TranslateMessage(&msg);
DispatchMessage(&msg);
continue;
}
if (msg.message >= (WM_MOUSELAST+1)) {
// Message from WM_MOUSELAST+1 to the last message possible
GetMessage(&msg, NULL, WM_MOUSELAST+1, 0xFFFFFFFF);
TranslateMessage(&msg);
DispatchMessage(&msg);
continue;
}
// if all that's left is mouse button messages, get out
if (msg.message > WM_MOUSEMOVE || msg.message < WM_MOUSELAST+1) break;
}
return;
Now the event handler gets to finish its processing without re-entry. All of the non-mouse button events get processed. When the event handler is done, control goes back to the main VCL thread message pump and the waiting mouse button event(s) is/are fired.
I need to create a simple GUI which displays images, the images in this example can change and the GUI will need to update it's contents.
I wrote the following update function in my widget class:
void myClass::updatePic() {
QPixmap pix("./pic.png");
int width = ui->picLabel->width();
int height = ui->picLabel->height();
ui->picLabel->setPixmap(pix.scaled(width,height,Qt::KeepAspectRatio));}
I try to use it in the following manner:
int main(int argc, char *argv[]) {
QApplication a(argc, argv);
myClass w;
w.show();
sleep(3);
w.updatePic();
sleep(3);
w.updatePic();
sleep(3);
return a.exec();}
But the window just opens and does not display the images until we get to the a.exec() line, and then it opens the last image. What am I doing wrong?
EDIT:
Clarification, the trigger for changing the images comes from an external program (specifically, the gui will be a node in ros, and will be triggered by another node). Is there a way to push a button not from the gui via an external program? the timer will work but I dislike this "busy wait" style solutions.
Thanks for the suggestions so far
exec runs the QT event loop, which includes rendering widgets.
So move your updatePic call into your widget and activate it by for example a button or in the show event
At first learn more about event loop. In particular, you must know that all events like paintEvent or resizeEvent are usually called on corresponding events handle. The events handle is usually called by the event loop, i.e. inside of exec function.
Let's unite answers of #MohaBou and #RvdK. You need to handle timer shots after the exec call. Use QObject::timerEvent for this.
myClass::myClass()
{
<...>
// This two variables are members of myClass.
_timerId = startTimer(3000);
_updatesCount = 0;
}
myClass::~myClass()
{
<...>
// For any case. As far as I remember, otherwise the late event
// may be handled after the destructor. Maybe it is false, do
// not remember...
if (_timerId >= 0) {
killTimer(_timerId);
_timerId = - 1;
}
}
myClass::timerEvent(QTimerEvent *event)
{
if (event->timerId() == _timerId) {
if (_updatesCount < 2) {
updatePic();
++_updatesCount;
} else {
killTimer(_timerId);
_timerId = - 1;
}
}
}
The startTimer method here adds especial timer event to the event query every 3 seconds. As all events, it may be handled only when the event loop will take control and all earlier events are handled. Because of it you can have a duration if many "heavy" events are handled.
EDIT: sorry, I didn't understand #MohaBou at first read. His answer with explicit QTimer is also good enough (but I still don't understand a part about modality).
The function exec also renders the child widgets. exec() blocks the application flow while show() doesn't. So, exec is mainly used for modal dialogs.
I recommend to update it in your custom witget by using a refresh timer. Use a QTimer to update the image every 3 secs:
QTimer* timer = new QTimer(this);
timer->setInterval(3000);
connect(timer, SINGAL(timeout()), this, SLOT(updatPicture()));
Update your picture in your custom slot:
MainWindow::updatePicture() {
updatePic()
}
If you want, you could use a lambda function:
connect(timer, &QTimer::timeout, this, [&w]() {
updatePic()
});
I'm trying to create a "responsive gui", which basically means that I have an app, and on the main window there is a button. After I press this button I want the "progress bar window" to get displayed which will show the progress of the work being done, and of course this work is being done in separate thread.
Unfortunately my approach with starting a new thread in ctor of this progress_bar window doesn't seems to work and I got frozen gui.
Here is the link to this project so you can download it and run without the need for copying and pasting anything: http://www.mediafire.com/?w9b2eilc7t4yux0
Could anyone please tell me what I'm doing wrong and how to fix it?
EDIT
progress_dialog::progress_dialog(QWidget *parent) :
QDialog(parent)
{/*this is this progress dialog which is displayed from main window*/
setupUi(this);
working_thread_ = new Threaded;
connect(working_thread_,SIGNAL(counter_value(int)),progressBar,SLOT(setValue(int)),Qt::QueuedConnection);
working_thread_->start();//HERE I'M STARTING THIS THREAD
}
/*this is run fnc from the threaded class*/
void Threaded::run()
{
unsigned counter = 0;
while(true)
{
emit counter_value(counter);
counter = counter + 1 % 1000000;
}
}
Independently from the fact that tight looping is bad, you should limit the rate at which you make changes to the main GUI thread: the signals from your thread are queued as soon they are emitted on the main thread event loop, and as the GUI can't update that fast, repaint events are queued rather than executed in real time, which freezes the GUI.
And anyways updating the GUI faster than the screen refresh rate is useless.
You could try something like this:
void Threaded::run()
{
QTime time;
time.start();
unsigned counter = 0;
// initial update
emit counter_value(counter);
while(true)
{
counter = (counter + 1) % 1000000;
// 17 ms => ~ 60 fps
if(time.elapsed() > 17) {
emit counter_value(counter);
time.restart();
}
}
}
Do you try to start the thread with a parent object?