This question already has answers here:
Closed 10 years ago.
I wonder how to create an application that would be capable to have only one instance of it running on a host OS at a time.. so to say a singleton app. I wonder how to create such singleton C++ app in Qt?
You could use the QtSingleApplication class from Qt Solutions. Notice that this is not a standard Qt class. You should download it. The QtSingleApplication component provides support for applications
that can be only started once per user.
When the application starts, create a file. When the application ends, remove the file.
If the file exists, exit with an error message.
You don't really need Qt for this, it's a graphics library.
Just use some normal WINAPI method to do this.
You could either create files like suggested (but can get strange when your application will crash, or after a power outage), or use memory mapped files or some other global objects to check if your app is stil running.
You also could just check the process list to see if another copy is running.
Another thing is to do a FindWindow with your window class, that's pretty easy and will work well.
There are a lot of options, just search for this, it's a common question.
(you could use some libraries for this, but since you are only targetting windows, I'd go with FindWindow.)
Related
Im trying to make (what I thought was a simple) extension for Game maker studio 2.
I am restricted to making a DLL app.
I am wondering is there any was to have a dll app open the file explorer have the user locate a file and then return said directory?
I fell like this is a sumb question but one I really need to know the answer too before slaving away coding for hours only to find its not possible.
You do not want to launch the explorer but to open a file dialog that allows the user to select a file.
Depending on the framework you use in your program the solutions may differ.
If you are using Qt framework you may use a QFileDialog for a platform independent mechanism.
If you are okay that it will only works on Windows then you may directly use the WinAPI functions GetOpenFileName or GetSaveFileName (that is a lot easier than the Common Item Dialog that is suggested as replacement on their documentation pages)
On GameMaker terms, you want to use get_open_filename or get_open_filename_ext.
See Dialog Module (marketplace, github) for C++ implementation reference.
I'm trying to develop C++ application for a client. So far, i have added the basic functionalities and it works as expected but i will likely to gradually grow the application in future (i.e. adding more feature to it) and the client will likely to update those feature in their app. Now my questions are the following:
For adding feature, i have decided to add features to a dll and the client will likely replace the old dll with the new one (in order to use latest features). Is there a better approach for updating C++ app?
Why some developer use ordinal values instead of function names while exporting symbols, whats the benefit of using ordinal values other than less binary file size ?
I don't want my client to recompile/link the app, i just want to keep the updating process as smooth as possible. Need advice.
P.S:
Environment = Windows + Visual Studio
#Vasilij way is the way to go. If you update only de DLL, how you application will know that there are new functions to call? You have to dynamically adapt your menus and so on.
Just create an exe stub that runs the real application (may be in a subprocess it can kill) and update the whole app (not the stub) and DLLs when necessary. That stub can check for updates also and suggest the restart after downloading.
I made a program in c++ (visual studio 2010) that looks for serial com ports and compares their friendly names with defined text. When there is a match that port is opened/connected and serial communication starts.
The program notifies the user when a com port is found, whether the connection was successful or not and if the data send was successful or not and other useful information. The program uses cout to notify the user.
I want to replace console output window with windows form but cant find much resources online on how to do this. To illustrate, I want this:
To become this:
I included form1.h and other files and tried replacing cout with below line but code is not compiling:
Form1::textBox1->Text = L" Text I want to display";
Can anyone explain how to use textBox1, or a tutorial for this?
"I included form1.h" - You can't just grab random files and hope it works. That is not how C++ works, or computers in general.
How then do you do something like this? The Standard Library provides std::cout and Visual Studio by default includes the Standard Library, so using it is fairly easy. But for graphics, you will need another library. I recommend Qt, if only because there are good tutorials for beginners.
So I finally did achieve the functionality I described above in my question and thought I should post my findings here.
To convert my code from console output to Windows Form I basically had to migrate from c++ to C++/cli.
holowczak.com has a great tutorial on how to get started with windows form (c++/cli) in visual studio.
Next if there is any busy looping(like infinite while-loop) in your c++ code then you would need to run that busy loop on a separate thread or the program can hang. Dr.Dobb's tutorial on how to create and mange threads in c++/cli, can help a lot.
Finally, if you need to access resources (such as textbox and other controls) of windows form from another thread then a thread-safe call has to be made. Microsoft's "HowTo:Make thread-safe call to windows Form controls" explains how the invoke method can be used for updating textbox from another thread.
I'm fairly new to Windows programming. I'm doing a simple launcher app for WinCE using VC++ (not MFC). So far I've created the basic interface and buttons and stuff. I just wanted to know the best way to launch an external application when the user clicks the button (on BN_CLICKED).
I found some methods such as ShellExecute, CreateProcess and others. But I couldn't get it to work (yet?). Any suitable reference or simple example on this?
The question don't matter that it happens inside the event of a button click, but...
ShellExecute is a good way to start programs (and the default program for any other type of files) in Windows, but use CreateProcess if you need a return code, or if you need the ability to wait for the program to finish.
Nevermind. I found a working example on MSDN - a comment by a user.
For anyone interested, you can go to this CreateProcess() article and scroll down to a comment entitled "Working code for creating two processes "p1.exe" and "p2.exe" using CreateProcess() Method"
Thanks!
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!