Is there a way to prevent a QT app to be executed twice ?
Is there a way to prevent a QT app to be executed twice ?
If you are a commercial user and willing to pay a few bucks more, then QtSingleApplication is for you.
if you are not a commercial user, then you have few choices.
On *NIX often used approach is creating a lock file (Unix Daemon Server Programming), on Windows - creating a mutex (MSDN: Mutex Objects).
There are better ways on Windows than with an interprocess mutex.
One would be: "On Windows the implementation uses FindWindow() to detect a running instance, and the WM_COPYDATA message to send string data." This is from the QtSingleApplication documentation. One could also use lock files on windows too.
I didn't say that mutexes are the best.
Of course, and mutexes (or semaphores, depends on chosen "backend" - POSIX or not) on unix. There are also named pipes, shared memory (without mutexes we can get races, but I bet there exists a program using only shm to achieve only one instance running, in most cases it'll work...) and others that I not remember right now.
I only wanted to point the solution used by the QtSingleApplication.
I am sure they opted for the most efficient solution when they implemented that class.
There are many methods, I can't argue with that. But some of them are almost "theoretical". There's no winning in implementing them.Of course, and mutexes (or semaphores, depends on chosen "backend" - POSIX or not) on unix. There are also named pipes, shared memory (without mutexes we can get races, but I bet there exists a program using only shm to achieve only one instance running, in most cases it'll work...) and others that I not remember right now.
On Unix they use: "On X11 systems the implementation uses X atoms to communicate through the selection mechanism.".
Can't believe you have to pay additional fees for such a class.
Why don't you create it yourself?
You have all the necessary information...
Well that's why you use Qt over MFC, because you don't have to code architecture specific components. If one purchase a Qt license he could expect to have this crucial feature out of the box.
Correct me if I'm wrong but QtSinglaApp feels more like : "Too bad you need to pay extra bucks for doing that crucial feature".
Instead of
"It's so complicated to develop we've decided to charge you more".
Anyway, thanks for the help guys.
It is not a crucial feature. You just feel like that because you need it right now.If one purchase a Qt license he could expect to have this crucial feature out of the box.
If you'd have started to implement your own last night when you first asked about it, it would have been ready right now. Twice.
But why? It shouldn't. I find it very useful that Trolltech offered some insight on how QtSingleApplication was implemented. Once you had this information, the Internet is full of documentation on FindWindow and WM_COPYDATA, and the other methods used on the other platforms.
bunjee (13th February 2008)
Yeah, I needed that class... but then I found out that even though I have a commercial developer license I needed to buy a special license just to get it. So to make a long story short... I spent 5 minutes and I wrote my own. I have my own cross platform mutex/semaphore class and I used it.
Here is a quick example of how it works using semaphore.h... as if you didn't know.
Qt Code:
// Example using <semaphore.h> under linux. string sSemaphoreKey = "test777"; cout << "Opening semaphore: " << sSemaphoreKey << endl; sem_t* mySemaphore = sem_open(sSemaphoreKey.c_str(), O_CREAT|O_EXCL, S_IRUSR|S_IRGRP|S_IROTH, 1); if (mySemaphore == SEM_FAILED) { cout << "Failed to open semaphore: " << sSemaphoreKey << endl; return 1; }To copy to clipboard, switch view to plain text mode
Anyone thinking about buying that crappy class should light a 100$ bill on fire so they can learn before hand what it is like to burn money.
Last edited by bpetty; 4th March 2008 at 21:00.
I was going to make my own code, but then I decided to look around for some open source apps which already implemented this. Then I found the infamous QGRUBEditor (now known as KGRUBEditor). I looked in the source code and I found this in main.cpp:
Qt Code:
{ { qWarning( "QGRUBEditor: Already running" ); return 0; } lockFile.close(); } { lockStream << getpid() << endl; lockFile.close(); }To copy to clipboard, switch view to plain text mode
Now, this code isn't very system independent. To make it system-independent, we /proc/ and getpid() has to be eliminated. So, how would I find out an "id" of the application?
Or, is there an alternative way? Using sockets seems wrong... it looks like it can cause problems for other applications.
This is another idea: What if I create, in the event loop, a function which will constantly update the lockfile with the current time, and then have a new instance of the application check if the time of the file is different from the current file. This will use too much hard drive though...
Locking a file seems a good idea, and the Qxt extension contains a file locking class. Perhaps I could import some of the more vital functions from there? Also, is the file unlocked when the process is terminated?
If there is no system-independent way, how would I achieve this? I already have the code for Linux, but I don't have a Mac to test the code on nor do I know of any way to check it on Windows. Semaphores - do they work in between applications?
Well... if anyone has any bright ideas, please make a new thread or reply here. Thanks!
Alright, I did the implementation for Windows if anyone is interested.
Hi,
Can we use this with network shared files?How? We have files on network and if somebody open file for write,others mustn't open it.How can understant file was opened?
i want to use this approach with microsoft network and samba shares.Is this lock file approach enough for me???
Thanks in advance
Ramazan
Bookmarks