I'm currently working on a console application with Qt, and I was wondering, if there is any way to automatically test my application, so I don't have to test everything manually. I've searched the web, but haven't found anything yet.
If there is no way to do this with a preexisting framework, would it be possible to have an extra thread writing to, and reading from stdin and checking on this thread if the program is behaving correctly? If yes, how exactly would I do this? (I'm a beginner at everything multithreading)
Thanks in advance.
Related
I'm not sure if anyone asked this, I tried to find it but I couldn't. I'm starting a new project and I want to make a GUI in C++ that will run another application called "GAMS" which does some optimization problems for me.
Now, I do know how to create GUI and how to run GAMS itself using ShellExecute(), but I don't know how to run those algorithms from my GUI.
All I need is to run scrip that I wrote in GAMS and that I would be able to manipulate with data that I receive from GAMS.
So my question is, can I send commands from my GUI to GAMS?
Thanks in advance!!
I´m developing an application in QT 4.7.3. This application is called from Matlab(simulink) using a mexFunction (*.mexw32)
When I try to open a dialog using dialog.exec() command, the form is displayed but I get a "non responding application" instantaneously. After that, matlab crashes.
If i try to open the dialog using dialog.show() command, it works fine.
I really have no idea of whats going on, since both commands are somehow similar, as described here
Does anyone know what is happening?
dialog.exec() spins a local event loop that doesn't integrate well with the one that Matlab itself is spinning. Thus the crash. Conversely, you're banking on Matlab doing the right thing as far as its own event loop being compatible with Qt's requirements goes. This doesn't hold on all platforms, unfortunately, although on Windows it seems to work.
You should never be using exec() outside of main anyway.
This is a follow on from a question I asked about embedding Qt code in a legacy C application.
I am able to build Qt code into my C application and was surprised to find that I can even run gui code from within the static library I'm using to do this.
(My C application is also GUI driven, by the way).
This opens up some exciting possibilities, and I'm trying to get the two GUIs to work side by side.
The problem I have now is that in order to launch Qt GUI code I need to call QApplication::exec(), which is effectively blocking the rest of my application as it doesn't return until I kill the qt gui.
Is there any way I can start the qt gui code up and still return to my host application?
I appreciate I could start my Qt code up as a different process and implement some inter process communication, but the whole point is to try and get this embedded as a library.
There's also no way I can host the legacy application in Qt, before anyone suggests that!
Thanks for your help!
Don't call QApplication::exec(). Instead have the application call QApplication::processEvents() in it's event loop.
The answer to your problem is threading.
Since you are doing C, pthreads is probably available to you.
void * qt_thread(void * parm) {
// code here
QApplication::exec();
}
//some where in your main()
pthread_t qt;
pthread_create(&qt, NULL, qt_thread, NULL); //returns immediately
// rest of code
This is a VERY rough example, you should study and learn threading properly.
Good reference:
https://computing.llnl.gov/tutorials/pthreads/
Well, you can start a second thread (e.g., using the pthread library) and start QApplication::exec() from the second thread. However, you must be very careful when communicating with your QT code in order not to have race conditions in your library.
I'm developing a QT application with QTCreator (and QT 4.5.3) on Arch Linux. I'm using KDE 4.3
The project is basically a GUI that let you insert a url and make some web requests to give the user some data back.
The web requests are asynchronous.
I've encountered a weird problem.
If I start the application the first time and click on the button that launches the web requests, it crashes.
On the second time it works as expected.
The third and the fourth time it returns just one of the 900 values I was expecting.
What's strange is that on Windows (and QT 4.6) is working always fine..
Have you ever seen such a thing?
Thanks in advance for your information
Best regards
I've never seen anything exactly like this, but I have seen different behaviours between Linux and Windows where the Windows code seemed to work. In my experience, the code is almost always wrong - it's just much easier to catch it when you run in Linux.
I have two suggestions to make:
run with Valgrind: this will catch the obvious flaws
link with the Qt debug libs (usually QtCored.so, QtGuid.so on Linux)
And a third: look very carefully at the web requests responses in Linux / Windows, possibly in a diff-scanner. Any differences might point you in the right direction
I'd say that has something to do with cookies.
Try to create the smallest possible application that reproduces that bug and then try to determine, if it's your or Trolltech's code that crashes.
The problem was related to an array of elements which weren't set in time
Greetings overflowers.
I am trying to add a GUI to to an existing project. More specifically to a plugin that is loaded as a .so file (or when compiled on win32 a .dll)
The project has its own threading implementation already to deal with portability. I know that Qt has its own cross platform threading model but it would be preferable to stay within this existing threading model.
My question to the Qt veterans out there [I have only just started reading the docs] is: Would it be possible to embed a GUI using Qt in to a plugin as described above? The plugin already is a command line interface and I would like to have the GUI optional, even if its compiled in. Since those standard functions get called by the main program, the GUI (which I assume will live in another thread) will have to be accessible or able to have methods called on it so that the CLI thread can coexist and the standard functions can work with any permutation of the two interfaces.
edit 1:
after playing with the code a bit I am able to launch a simple GUI from the plugin. The plugin already is the CLI and has functions that are called from the main program. I simply created a new thread on initialization of the plugin and launched the blocking GUI from there:
QApplication app(NULL, NULL);
window = new zGui;
window->show();
app.exec();
The question here is: Is it possible to communicate with the GUI or rather access GUI elements from the CLI thread?
edit 2: some results
Alright, so far starting the blocking GUI in a separate thread has worked with no problems. I am able to access widgets in the GUI from the main plugin thread as well. I understand that this practice is discouraged as not only per the answers I've received so far but also the Qt libs are spitting out some warning about unsafe access by another thread.
As of now I have only been working in a linux environment, perhaps real issues will be presented on other systems. I have seen only one glitch that I can not say for sure is related:
Upon changing the the max and min values of a progress bar widget, the progress bar appears blank. I was able to apply a simple fix to this by the following
//here is me setting the values
window->progressBar->setMaximum(character.maxHP);
window->progressBar_2->setMaximum(character.maxMP);
window->progressBar->setValue(character.curHP);
window->progressBar_2->setValue(character.curMP);
//and here is the fix
window->progressBar->setVisible(false);
window->progressBar->setVisible(true);
window->progressBar_2->setVisible(false);
window->progressBar_2->setVisible(true);
I suppose my final question is 'What specifically are the situations where accessing a Qt GUI from an other thread is unsafe and why?'
You can use a Qt GUI from a dll or so that is called from a non-Qt application, but it cannot be from a secondary thread, it has to run in the main thread. And the application event loop is started via a blocking method that returns when the GUI is closed out, so if you needed to have logic running in your app that is independent of the GUI, then that logic would need to be running in a secondary thread.
If you felt ambitious, you could modify the QCoreApplication and QEventLoop classes in such a way that you can manage the event loop from your calling application, and it probably wouldn't be all that difficult. But as far as I know there's no way to do it with Qt out of the box.
Consideing to Gerald answer, might I suggest that its better to keep the CLI (your app) separate from your apps GUI (ergo, a separate app).
Make your GUI app use the cli in the background. its easily done by using QProcess.
cheers!