I have 2 programs. Console and QT. Console program should make some data , and qt program should than show this data. But this should be separate programs, and i do not know how can i tell QT program to do somthing from my Console. Two programs are local and Qt program is always running (so that i can not just run it every time), and Console is only lunched when needed. So the question is - how can i execute somthing in Qt after console program finishes?
P.S. The console program makes a file that Qt program can read and than display.
I'm using windows.
Int Qt, you can start the console process with QProcess. That class has a finished signal, which you can connect to a slot in your application object. Then, when the console process finishes, the finished signal fires, and your slot function is called. At that point you can read the output file.
This is more efficient than a QFileSystemWatcher because you're directly watching the relevant event (console program finishes).
You might consider using something like QFileSystemWatcher to poll for changes in a particular directory, then have your console program write the file there. That way the Qt program would get a notification when the contents of the directory change.
Interprocess Communication (IPC) is the solution you're looking for.
The MSDN documentation is available here, containing more details about implementing this in your application, as well as code samples.
This technique is called "Screen scraping". You are doing this by connecting console app's stdout to Qt apps input.
Look at http://doc.qt.nokia.com/latest/qprocess.html
Take a look at QSharedMemory: http://doc.qt.nokia.com/4.7-snapshot/qsharedmemory.html. It allows inter-thread and inter-process communication.
A very nice and short example on how to use QSharedMemory is here: http://doc.trolltech.com/main-snapshot/ipc-sharedmemory.html
Related
i want to do a simple program that will run another program (easy task in C++), hook the process and, when the program is closed, run another program (needed to sync a file modified by the first program).
The second program prompt out a popout asking a simple Yes/No buttons.
There is any way?
I am writing an article about hooking : http://ntvalk.blogspot.nl/2013/11/hooking-explained-detouring-library.html
It describes the probably most common methods for hooking under Windows. (jmp/vtable/etc)
gldraphael already described a method of running another program.
Check this out: http://faq.cprogramming.com/cgi-bin/smartfaq.cgi?answer=1044654269&id=1043284392
It lists the various ways you can run another program.
I am writing an application in Qt which gets executed by a launcher app. How can I detect whether the Qt application was launched by the user or the launcher. Is command line parameters the only way or is there a better way?
Both the Qt app and launcher are written by me.
Lots of ways. A command line parameter could be easily sniffed (by Process Explorer, e.g.), if that's a concern. But a named mutex or some other interprocess handle that can be inherited by the child app would be more difficult to spoof.
I need to make a windows GUI application can run in console, so I attach the console to the process when the application is invoked with a command line. However, after the application exit, the console prompt with the path doesn't show unless the ENTER key is pressed. Is there any way that the prompt with the path can directly show up without pressing the enter key? Thanks.
Short answer: This is not possible.
Long answer: Well, it is sort of possible if you are willing to relax your requirements a little bit. You basically have three options:
What you have done already. You can attach GUI application to a console but cmd.exe will not wait for your application to exit.
Create a GUI application and open console in the GUI application. The console will only last as long as you application.
Or you can restructure your application/source a bit and provide two executables, GUI one that starts GUI directly, another that is console executable.
In C#, I use SendKeys.SendWait("{ENTER}"); to do that. I think in C++, the keybd_event function does something similar.
Like Autodesk Maya with MayaBatch, you can build a small console application which basically run your GUI application with CreateProcess and wait with WaitForSingleObject.
You will have to use this "batch" version of your application in the console.
I have an executable that I need to run some tests on in C++ - and the testing is going to take place on all of Windows, Linux and Mac OSes.
I was hoping for input on:
How would I interface with the previously built executable from my code? Is there some kind of command functionality that I can use? Also, since I think the commands change between OSes, I'd need some guidance in figuring out how I could structure for all three OSes.
EDIT - Interface = I need to be able to run the executable with a command line argument from my C++ code.
The executable when called from the commandline also ouputs some text onto a console - how would I be able to grab that ouput stream (I'd need to record those outputted values as part of my tests).
Feel free to ask me follow up questios.
Cheers!
If you use qt to develop your code, you'll find QProcess will allow you to spawn a command line program in a platform-agnostic way.
Essentially:
QObject *parent;
QString program = "yourcommandlineprogram";
QStringList arguments;
QProcess *myProcess = new QProcess(parent);
myProcess->start(program, arguments);
You can then read from the process with various function calls such as readAllStandardOutput (), and write to the input of the process with QProcess::write(QString).
Alternatively, if you prefer Boost to Qt, Boost.Process will also let you launch processes. I confess I don't like the syntax as much...
boost::process::command_line cl("yourcommandlineprogram");
cl.argument("someargument");
boost::process::launcher l;
l.set_stdout_behavior(bp::redirect_stream);
l.set_merge_out_err(true);
l.set_work_directory(dir);
boost::process::child c = l.start(cl);
You can then work with your subprocess 'c' by using stream operators << and >> to read and write.
All those OSes support some form of "subprocess" calling technique, where your tester creates a new child process and executes the code under test there. You get to not only pass a command line, but also have the opportunity to attach pipes to the child process' standard input and output streams.
Unfortunately, there is no standard C++ API to create child processes. You'll have to find the appropriate API for each OS. For example, in Windows you could use the CreateProcess function: MSDN: Creating Processes (Windows).
See also Stackoverflow: How do you spawn another process in C?
As I understand, you want to:
Spawn a new process with arguments not known at runtime.
Retrieve the information printed to stdout by the new process.
Libraries such as QProcess can spawn processes, however, I would recommend doing it by hand for both Windows and MacOS/Linux as using QProcess for this case is probably overkill.
For MacOS/Linux, here's what I would do:
Set up a pipe in the parent process. Set the read end of the pipe to a new file descriptor in the parent.
fork.
In newly created child process, set stdout (file descriptor #1) to the write end of the pipe.
execvp in the newly created child process and pass the target executable along with what arguments you want to give it.
From the parent process, wait for the child (optional).
From the parent process, read from the file descriptor you indicated in Step 1.
First of all, is it possible that you simply need to want to make your original code reusable? In that case you can build it as library and link it in your new application.
If you really want to communicate with another executable then you can need start it as a subprocess of the main application. I would recommend the Process class of the Poco C++ libraries.
Looks like a job for popen(), available on Linux, Windows, and OS X
Sounds like you are only planning to do functional testing at the executable level. That is not enough. If you plane to do thorough testing, you should also write unit tests. For that there is some excellent frameworks. My prefered one (by far) for C++ is BOOST::Testing.
If you control source code there is also common tricks for functional testing beside launching exe from an external process : embed functional tests. You just add an option to your program that execute tests. This is cool because tests are embedded in code and autocheck can easily be launched in any execution environment.
That means that in the test environment, as you call your program with some test dedicated arguments, nothing keeps you from going the full way and redirect the content of stdout and even check the tests results from within the program. It will make the whole testing much easier than calling from an external launcher, then analysing the results from than launcher.
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!