 |
|
|
 |
|
|
 |
|
|
I know this is a little late, but I just found this article and I think I figured out a workaround.
My guess is that in Release mode (with optimizations), the optimizer incorrectly destroys the Mutex prematurely. My workaround is to reference the SingleInstance variable after you need it:
int __stdcall WinMain() { //create a mutex with a unique name CSingleInstance *si= new CSingleInstance("{94374E65-7166-4fde-ABBD-4E943E70E8E8}"); if(si->IsRunning()) MessageBox::Show("Already running...so exiting!"); else Application::Run(new MainForm());
bool running = si->IsRunning(); // I added this line
return 0; } This way, my understanding is that now the optimizer will not prematurely dispose of the si object, and it seems to work for me.
-- Marcus Kwok
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Nish,
Thanks for this piece of code. It works great. I was wondering how you would go about adding a feature. I can do it with some code form one of your tips in MFC, however I am trying to accomplish this is a Visual C++ .net managed application.
//Attach foreground window thread to our thread AttachThreadInput( GetWindowThreadProcessId(::GetForegroundWindow(),NULL ), GetCurrentThreadId(),TRUE );
//Do our stuff here  SetForegroundWindow( hwnd ); SetFocus( hwnd ); //Just playing safe
//Detach the attached thread AttachThreadInput( GetWindowThreadProcessId(::GetForegroundWindow(),NULL ),GetCurrentThreadId(),FALSE );
Instead of putting up a messagebox saying already running I want to be able to bring the application that is already running to the foreground.
Thanks,
Steve
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Thanks for the article, but I found out the following problem: When I run my app under debugger (Visual Studio .NET) when I exiting the application, the ApplicationException is being throwed in ReleaseMutex() with such msg: Attempt to release mutex not owned by caller.
My code is in C#, not managed C++, but it's actually the same:
public class SingleInstance { private Mutex m_mutex;
public SingleInstance(string sMutexName) { m_mutex = new Mutex(false, sMutexName); }
~SingleInstance() { m_mutex.ReleaseMutex(); }
public bool IsRunning() { return !m_mutex.WaitOne(10, true); } }
The call is made as:
static void Main() { SingleInstance si = new SingleInstance("My App");
if (si.IsRunning()) MessageBox.Show("Already running!"); else Application.Run(new frmMainWnd()); }
If I run the code not from debugger, no exception!
Does anybody have an idea? Thanks, Serge
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Two things :-
(1) Your code is not .NET (2) Even allowing non-.NET code, using the title text of a window as the unique key based on which we limit our apps to one instance is a very poor method.
Nish
Regards, Nish Native CPian. Born and brought up on CP. With the CP blood in him.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
 |
|
|
 |
|
|
[C#] using System; using System.Diagnostics; using System.Windows.Forms;
class Foo: Form { public Foo() : base() { } public static void Main( String[] args ) { Int32 RunningProcesses = Process.GetProcessesByName( Process.GetCurrentProcess().ProcessName ).Length; if ( RunningProcesses <= 1 ) { Application.Run( new Foo() ); } else { MessageBox.Show( "already running the program" ); } } }
|
| Sign In·View Thread·PermaLink | 1.00/5 (1 vote) |
|
|
|
 |
|
|
 |
|
|
 |
|
|
 |
|
|
 |
|
|
 |
|
|
Gosh!
Can't you see that this is the .NET port? Anyway for a comprehensive article on limiting your applications to one instance you can read Joe Newcomer's article.
This article is not intended as a revelation. It's a simple port to .NET of a universal technique used to limit apps to a single instance.
Regards Nish
p.s. Sorry for not being able to address you, but since you made an anonymous post, I could not do that
Sonork ID 100.9786 voidmain
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
 |
|
|
 |
|
|
Don't let them get to you, Nish. You and I know that there are a ton of singleton techniques and yes, the mutex one (especially involving guids) has been around for a few years now. However, people should focus on the fact that for some of the newcomers to .NET you gave a very quick port to .net without taking credit for the work of others.
Cheers, Tom Archer Author, Inside C#
|
| Sign In·View Thread·PermaLink | 5.00/5 (1 vote) |
|
|
|
 |
|
|
I completely agree with Tom Archer. Although I'm not new to Win32/C++, I am new to MC++ (just installed VC++ .NET today). This port and other articles on MC++ are very helpful!
I appreciate your practical articles, Nishant. I've learned more in the few minutes I've spent scanning these pages/articles than the months and months I wasted scrounging through MSDN.
-- RMC
|
| Sign In·View Thread·PermaLink | 5.00/5 (1 vote) |
|
|
|
 |
|
|
 |
|
|
Actually I have used Managed C++ for this class.
But thanks anyway...
and yeah..Long live the mutex
Nish
Sonork ID 100.9786 voidmain
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Funny -- This is not managed C++! This is a simple use for basic synchonization objects. The same method can be used in MFC (all the way back as far as I can remember MFC having synchronization objects!). Personally, this is one of your worst articles. It is almost literally a copy of MSDN documentation. I know you can do better Nish . . .
Zac
"If I create everything new, why would I want to delete anything?"
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Zac Howland wrote: Funny -- This is not managed C++! This is a simple use for basic synchonization objects. The same method can be used in MFC (all the way back as far as I can remember MFC having synchronization objects!). Personally, this is one of your worst articles. It is almost literally a copy of MSDN documentation. I know you can do better Nish .
This article was written in November 2001 during the beta 2 days. In fact some of us still had only beta 1. I have mentioned in my article that this is simply a port of something we used to do with normal API. The documentation for Mutex class wasn't good during the beta days. This is basicalyl a 1:1 port of a universal technique used to restrict applications to a single instance. I have not claimed that this is something new or innovative. It's a straight port!!!
Regards, Nish Native CPian. Born and brought up on CP. With the CP blood in him.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
It doesn't matter when this was written. Since Sept '94 (when Windows 95 was released), you have had to do this to create single instance applications. This does not use any .Net or managed C++ code -- just simple synchonization. MSDN (version 6.1a that was released with VC6) had an example that did just about the same thing (it made the mutex a member of the CWinApp derived class -- but the effect was the same). What I was pointing out was that this article was little more than you running up your article count. If you get bored, try working on something that is actually useful (and NOT already documented).
Zac
"If I create everything new, why would I want to delete anything?"
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
If there was a code-snippets section here I might have submitted it there, but on CP we don't have code-snippets separate from articles. Some articles are simple functions basically. It's not insisted that every article should be a unique master piece.
While I regret the fact that you seem to be thoroughly annoyed with my articles, I don't accept all of what you are saying. There will be articles that are ports and re-runs of new techniques in newer clothes. But I understand your concern. Thank you.
I'll try and keep some of the things you said in mind. But it's not going to discourage me in any way. I've gone past that stage.
Nish
Regards, Nish Native CPian. Born and brought up on CP. With the CP blood in him.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |