Only One Instance to be opened...
-
Does anybody know how I can force my MFC-Dialogbased-Application to be opened only once. No second instance should be possible. I tried it with a flag BOOL MyInstance = FALSE; in the InitApplication() - and in the InitInstance() I wrote if(!MyInstance) { MyInstance = TRUE; CZones dlg; m_pMainWnd = &dlg; dlg.DoModal(); } I thought that InitApplication() is called only once and every further Instance is just calling InitInstance(). But it looks like every Instance is also calling InitApplication()... Any Ideas ? Manfred
manfred ... the win32 apps all run in their own process space so they dont get to see the others and the concept of a global flag across all instances doesn't hold what you should do in the initinstance (or what i would do) is use the enumerate thru all the active windows and see if another instance of your app is in the list ... if it is just terminate gracefully from the second instance :suss: --- "every year we invent better idiot proof systems and every year they invent better idiots"
-
manfred ... the win32 apps all run in their own process space so they dont get to see the others and the concept of a global flag across all instances doesn't hold what you should do in the initinstance (or what i would do) is use the enumerate thru all the active windows and see if another instance of your app is in the list ... if it is just terminate gracefully from the second instance :suss: --- "every year we invent better idiot proof systems and every year they invent better idiots"
And how can I enumerate through all active windows? Any function() available?:confused: Manfred
-
And how can I enumerate through all active windows? Any function() available?:confused: Manfred
EnumWindows() will go thruogh any top level windows in the system and call a user-supplied callback function passing the window handle of each active window ... from that you can get the window title and check against your app name :) --- "every year we invent better idiot proof systems and every year they invent better idiots"
-
EnumWindows() will go thruogh any top level windows in the system and call a user-supplied callback function passing the window handle of each active window ... from that you can get the window title and check against your app name :) --- "every year we invent better idiot proof systems and every year they invent better idiots"
Hi, here is a another way to check out if your application is already running. I used this in my API-code but it should also run in MFC. First create a mutex-object on startup. -> CreateMutex(NULL,true,"SomeName"); Than ask about last-error -> if( GetLastError()==ERROR_ALREADY_EXISTS) { // do exit stuff } Hope it helps Mario /// ---------------------- www.klangwerker.de mario@klangwerker.de ----------------------
-
Hi, here is a another way to check out if your application is already running. I used this in my API-code but it should also run in MFC. First create a mutex-object on startup. -> CreateMutex(NULL,true,"SomeName"); Than ask about last-error -> if( GetLastError()==ERROR_ALREADY_EXISTS) { // do exit stuff } Hope it helps Mario /// ---------------------- www.klangwerker.de mario@klangwerker.de ----------------------
i always used to get worried in case my app terminated abnormally and left a dangling mutex (not a pretty sight let me tell you) so i opted for a more 'passive' approach prolly just me being paranoid :cool: --- "every year we invent better idiot proof systems and every year they invent better idiots"
-
i always used to get worried in case my app terminated abnormally and left a dangling mutex (not a pretty sight let me tell you) so i opted for a more 'passive' approach prolly just me being paranoid :cool: --- "every year we invent better idiot proof systems and every year they invent better idiots"
Hi, first of all the function CreateMutex() returns a handle to an object when creation succeeds. On the other side the mutex-object will be created by the process which started first. Calling CreateMutex with same "Name" again won`t succeeds because it already exists so the worst case is to have 1 object at the same time and no more. Mario /// ---------------------- www.klangwerker.de mario@klangwerker.de ----------------------
-
EnumWindows() will go thruogh any top level windows in the system and call a user-supplied callback function passing the window handle of each active window ... from that you can get the window title and check against your app name :) --- "every year we invent better idiot proof systems and every year they invent better idiots"
> from that you can get the window title and check against your app name [...] Hmmm... You might want to be looking for a specific window class, not just a title. Titles can be duplicated, and since a window title is visible to the user, they tend to not be very complex. A Window Class, however, can be a very complex name, and is not generally shown to the user. Since the Window Class can be more complex, there is less chance of it being duplicated. For example, you can use a GUID (as long as you have a NIC in your machine) as (part of) the Window Class. -=- James.
-
Hi, first of all the function CreateMutex() returns a handle to an object when creation succeeds. On the other side the mutex-object will be created by the process which started first. Calling CreateMutex with same "Name" again won`t succeeds because it already exists so the worst case is to have 1 object at the same time and no more. Mario /// ---------------------- www.klangwerker.de mario@klangwerker.de ----------------------
> so the worst case is to have 1 object at the same time and no more. I think Lauren is trying to say that if your app AbEnds, and leaves the Mutex active, other instances of your application will not be able to launch, as they will see that the Mutex is active, and will not come up. A fix is to combine the Mutex with the "Window Search": Check for the Mutex, and then search for your app's window by it's *Window Class*. Then: o If you find the window, use ::SendMessageTimeout(...) to see if your app is not hung. If it responds, use that window handle to bring the app to the foreground (always a good idea, so the user gets some feedback). o If you find the window, but your app is hung, you can do whatever you want (kill it and relaunch, wait for it, etc.). o If you do not find the window, your app likely AbEnded, and left the Mutex lying around. You can then launch another instance. Peace! -=- James.
-
> so the worst case is to have 1 object at the same time and no more. I think Lauren is trying to say that if your app AbEnds, and leaves the Mutex active, other instances of your application will not be able to launch, as they will see that the Mutex is active, and will not come up. A fix is to combine the Mutex with the "Window Search": Check for the Mutex, and then search for your app's window by it's *Window Class*. Then: o If you find the window, use ::SendMessageTimeout(...) to see if your app is not hung. If it responds, use that window handle to bring the app to the foreground (always a good idea, so the user gets some feedback). o If you find the window, but your app is hung, you can do whatever you want (kill it and relaunch, wait for it, etc.). o If you do not find the window, your app likely AbEnded, and left the Mutex lying around. You can then launch another instance. Peace! -=- James.
>>I think Lauren is trying to say that if your app AbEnds, and leaves the >>Mutex active, other instances of your application will not be able to >>launch, as they will see that the Mutex is active, and will not come up. Yes in fact you`re right. That´s a point I haven`t thought about. The question is what will happen with a mutex-object which owner is no longer running ? Is it still reserved or is it free to get ? That`s worth a try I think. Mario /// ---------------------- www.klangwerker.de mario@klangwerker.de ----------------------
-
>>I think Lauren is trying to say that if your app AbEnds, and leaves the >>Mutex active, other instances of your application will not be able to >>launch, as they will see that the Mutex is active, and will not come up. Yes in fact you`re right. That´s a point I haven`t thought about. The question is what will happen with a mutex-object which owner is no longer running ? Is it still reserved or is it free to get ? That`s worth a try I think. Mario /// ---------------------- www.klangwerker.de mario@klangwerker.de ----------------------
> The question is what will happen with a mutex-object which owner is no longer running ? The documentation says that the handle to a created/obtained Mutex object is automatically closed when the process terminates. I am not sure if that includes abnormal termination. I am *fairly* certain I have had Mutex objects get "orphaned" on me in the past. But the thing I would concerned about is not really abnormal termination of your process, but your process trying to shut down, but cannot, because of a rogue/blocked thread, or something like that. You app will *appear* to have shut down to the user, but will still be sitting in the background someplace. Of course, you should try to prevent stuff like this from happening, but Sh*t Happens! :eek: MSDEV tends to do that to me at least twice a day (goes to sleep in the background after a shutdown)! :) Peace! -=- James.