 |
|
 |
This is weird, it only works for me when I build the project in debug mode...
|
|
|
|
 |
|
 |
Same here, anyone know why this might be?
|
|
|
|
 |
|
 |
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()
{
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();
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
|
|
|
|
 |
|
 |
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
|
|
|
|
 |
|
 |
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
|
|
|
|
 |
|
 |
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.
|
|
|
|
 |
|
 |
But sir it is working well.
|
|
|
|
 |
|
 |
But it is working well.
A.R Gupta
|
|
|
|
 |
|
 |
[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" );
}
}
}
|
|
|
|
 |
|
 |
FLAW: This approach will fail if the process(EXE) name is renamed!
Ramu
|
|
|
|
 |
|
 |
But you have to have admin rights to use GetProcessesByName
|
|
|
|
 |
|
 |
hi nish,
I think it would be better to use a GUID instead of other names for the mutex.
.
cheers
kannan
|
|
|
|
 |
|
 |
Yes.
That's correct. Thanks.
Nish
Sonork ID 100.9786 voidmain
www.busterboy.org
Nish is a BIG fan of Goran Ivanisevic
|
|
|
|
 |
|
|
 |
|
 |
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
|
|
|
|
 |
|
 |
I agree with MN. Be original.
|
|
|
|
 |
|
 |
Ouch!
I am tired of repeatedly saying that this is a .NET port of a universal technique
Nish
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
 |
|
 |
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#
|
|
|
|
 |
|
 |
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
|
|
|
|
 |
|
 |
Well done once again Nish just what I needed to know
So Mutex's live again with C# huh
Regardz
Colin J Davies
colin@vmtu.com Sonork ID 100.9197:Colin
Bring back the EMBED tag
|
|
|
|
 |
|
 |
Actually I have used Managed C++ for this class.
But thanks anyway...
and yeah..Long live the mutex
Nish
Sonork ID 100.9786 voidmain
|
|
|
|
 |
|
 |
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?"
|
|
|
|
 |
|
 |
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.
|
|
|
|
 |
|
 |
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?"
|
|
|
|
 |
|
 |
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.
|
|
|
|
 |