Joe Newcomer described it very good in the essay I referred to in my previous post.
Is it so hard to read it?
PS.
OK, the simplest example: application is windowless.
More complicated example: application needs (for some reasons) some time to create the main window, and during this time period user started this application again.
But what veerakalai want is that when a window(e.g. a .exe file is running) is running , if user open it again , it should not be opened again, I mean , by using findwindow function, we may find this window of this .exe file and check whether this file is running or not , if we find this handle of this window, we can prevent it opened again, right ??
Little by little one goes far Keep moving.......! Nothing is impossible !
But what veerakalai want is that when a window(e.g. a .exe file is running) is running ,
Where in the OP did you see the word "window"?
if user open it again , it should not be opened again, I mean , by using findwindow function, we may find this window of this .exe file and check whether this file is running or not ,
Please, read my previous post (particularly, the PostScriptum section)
if we find this handle of this window, we can prevent it opened again, right ??
Wrong!
1. As I already mentioned, the window may not exist (yet);
2. Just when FindWindow has found something there is no guarantee it is the window of the first instance of your application. There might be some other windows of some other applications having the same window title.
3. Please, read "Avoiding Multiple Instances of an Application" essay and you will never more suggest using such an erroneous way as FindFindow to prevent "to open the exe next time "....
If a program is running , it must have a window to display on the screen, even if we can not find it display, perhaps the window for this program running now is invisible(hide), we can also find it out , or we also may use CreateToolhelp32Snapshot to check it exsisted in process or not .
Perhaps you now misunderstand me , as I encounter it again from you before. as for our answer is right or not for veerakalai's question, it's up to him .
Take care!
See you !
Little by little one goes far Keep moving.......! Nothing is impossible !
If a program is running , it must have a window to display on the screen
Where did you found it?
It is wrong!
Example no. 1: console application.
Example no. 2: Create an MFC dialog application, put any code (for some calculations, working with some files, registry and so on) in the App InitInstance method and comment out CDialog:oModal call.
Example nö. 3: it is for you as an exercise...
I have read the essay "avoid Multiple Instance" and i tried that. I faced
a problem in searcher function, in searcher fn the follwing condition is not met in any suitation
if(result == wm_Find)
{
/* found it */
HWND * target = (HWND *)lParam;
*target = hWnd;
return FALSE; // stop search
}
i have attched the project i tried named singleInstance below. see to that and give me some suggestion.
I faced
a problem in searcher function, in searcher fn the follwing condition is not met in any suitation
Sure!
You don't handle UWM_ARE_YOU_ME message (in your case - CSingleInstanceApp::wm_Find message) in the CMainFrame class, so why do you expect any "feedback"?
I have tried as u said but i get the error as "error C2101: '&' on constant"
and i defined the UWM_ARE_YOU_ME as (WM_APP + 5). give me some solution to this problem. I have attached the project below
I have tried as u said but i get the error as "error C2101: '&' on constant"
You did something wrong. Read MSDN about such an error. Fix this error.
and i defined the UWM_ARE_YOU_ME as (WM_APP + 5).
Why?
give me some solution to this problem. I have attached the project below
Joe Newcomer already gave you solution with a lot of pieces of code. Why are you now trying to reinvent the wheel rather than copy/paste the working code?
The hint: your CMainFrame must handle the message that your CSingleInstanceApp::searcher() sends to all top level windows. As I saw from your previous zip you had used message id CSingleInstanceApp::wm_Find . So you must handle this message in the CMainFrame class and return this value from the message handler.
At the risk of adding fuel to the fire, I'd like to propose another solution that uses a memory mapped file and mutex to track the main hWnd of the application.
Here's what you do:
1) Add the following to stdafx.h:
class CMyWinApp : public CWinApp
{
...
// Implementation
public:
void SetFirstInstanceHwnd( HWND hWnd );
// Attributes
private:
// Class which limits this application to a single instance
CSingleInstance m_SingleInstance;
};
In the .cpp file modify the ctor and InitInstance method;
Code:
Code:
CMyWinApp::CMyWinApp()
: m_SingleInstance( _T("MYAPPNAME-088FA840-B10D-11D3-BC36-006067709674") )
{
}
BOOL CMyWinApp::InitInstance( )
{
//
// Verify this is the first instance of the program.
// If not, we use a memory mapped file to track the
// first instance hwnd and use this handle to bring
// the first instance to the foreground.
//
if( S_OK != m_SingleInstance.CheckFirstInstance( ) )
{
return FALSE;
}
// Typical init instance code here
...
return TRUE;
}
Lastly, modify the MainFrame cpp file to record the main hWnd
Code:
int CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
// Typical OnCreate code here
...
//
// Set the hWnd of this dialog in the memory mapped file
// This hWnd will be used on subsequent instances to bring
// the first dialog instance to the foreground
//
((CMyWinApp*)AfxGetApp())->SetFirstInstanceHwnd( GetSafeHwnd( ) );
return 0;
}
Neither this nor the J.P. Newcomer solution will completely work across desktops. I mean if the goal is to limit the app, then they both can work. But if the goal is to limit the app and bring an existing app to the foreground, they both will fail if the existing app is already running on a different desktop.
See the attached files for the modified SingleInstance.zip project.
For an example of this approach used in a MFC dialog app, check out the OnlyOne app in the source of the Win32 Thread Sync article listed in my signature line.
Last edited by Arjay; September 10th, 2007 at 02:39 PM.
* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.