ATL MFC EXE singleton server, single instance application 
Author Message
 ATL MFC EXE singleton server, single instance application

perhaps u r releasing references at wrong point...for signleton instance of
ur object, u may use

DECLARE_CLASSFACTORY_SINGLETON(classname) in ur classfactory (object co
class).

HTH


Quote:
> I have an MFC ATL application that has a user interface and a COM server
> that it exposes.

> If I invoke the application and load a document, then a client accesses
> this server and exits, my server remains as expected.

> If I invoke a client, my server application loads but doesn't display
> its user interface. If I then invoke another copy of this application, I
> made it open the user interface on the already running server app - and
> this is where the problems start. As soon as all clients shutdown, the
> main server closes, closing the UI with it - how do I prevent that? I
> don't want multiple copies of the server app running, is there a correct
> way of implementing this for an ATL server?

> Pete



Sat, 16 Apr 2005 20:48:54 GMT  
 ATL MFC EXE singleton server, single instance application
I have an MFC ATL application that has a user interface and a COM server
that it exposes.

If I invoke the application and load a document, then a client accesses
this server and exits, my server remains as expected.

If I invoke a client, my server application loads but doesn't display
its user interface. If I then invoke another copy of this application, I
made it open the user interface on the already running server app - and
this is where the problems start. As soon as all clients shutdown, the
main server closes, closing the UI with it - how do I prevent that? I
don't want multiple copies of the server app running, is there a correct
way of implementing this for an ATL server?

Pete



Sat, 16 Apr 2005 19:16:07 GMT  
 ATL MFC EXE singleton server, single instance application
Call _Module.Lock() when showing your main window, _Module.Unlock() when
hiding it. Essentially, the user is another client that holds a strong
reference on the server by way of seeing the main window, and releases
this reference by clicking X button.
--
With best wishes,
    Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken


Quote:
> I have an MFC ATL application that has a user interface and a COM
server
> that it exposes.

> If I invoke the application and load a document, then a client
accesses
> this server and exits, my server remains as expected.

> If I invoke a client, my server application loads but doesn't display
> its user interface. If I then invoke another copy of this application,
I
> made it open the user interface on the already running server app -
and
> this is where the problems start. As soon as all clients shutdown, the
> main server closes, closing the UI with it - how do I prevent that? I
> don't want multiple copies of the server app running, is there a
correct
> way of implementing this for an ATL server?

> Pete



Sat, 16 Apr 2005 22:48:01 GMT  
 ATL MFC EXE singleton server, single instance application

Quote:

> perhaps u r releasing references at wrong point...for signleton instance of
> ur object, u may use

> DECLARE_CLASSFACTORY_SINGLETON(classname) in ur classfactory (object co
> class).

I've got DECLARE_CLASSFACTORY_SINGLETON(classname) in my server class.
What I'm trying to work out is the difference when my exe gets invoked
as a COM server and as an application. At the moment I can't see any,
yet in one case, closing the client closes the server when I don't want
it to.

Pete



Sat, 16 Apr 2005 21:31:40 GMT  
 ATL MFC EXE singleton server, single instance application
It crashes where? Maybe MFC has its own module ref count, too, which you
don't maintain properly. I'm really not familiar with MFC.
--
With best wishes,
    Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken


Quote:
> I'm not having much luck with this crash. It's something to do with
the
> following:

> void CMainFrame::OnShowWindow(BOOL bShow, UINT nStatus)
> {
> CMDIFrameWnd::OnShowWindow(bShow, nStatus);

> if (bShow)
> _AtlModule.Lock();
> else
> _AtlModule.Unlock();
> }

> This works fine if the app is a server or starts up normally.

> If the app starts as a server, then opens its main Window, when it
> finally closes, I get a crash. If I remove the Unlock above, it closes
> but the app hangs around (not suprising really).



Sun, 17 Apr 2005 00:20:15 GMT  
 ATL MFC EXE singleton server, single instance application

Quote:

> Call _Module.Lock() when showing your main window, _Module.Unlock() when
> hiding it. Essentially, the user is another client that holds a strong
> reference on the server by way of seeing the main window, and releases
> this reference by clicking X button.

This did cross my mind... thinking about it now it does no harm to lock
the module if the main window is shown.

With a client, the server starts up, servers the client and exits
cleanly when the client closes. If during this time, you fire up another
copy of the server, it makes the running version open. Exiting the
client doesn't close the server - which is what I wanted.

Unfortunately, when I exit my server now, it crashes in
CWinApp::HideApplication, however I think I might know what this is...

Thanks!

Pete



Sat, 16 Apr 2005 23:25:33 GMT  
 ATL MFC EXE singleton server, single instance application
It has in fact, and there are some global functions staring with
AfxOle... to maintain it. The ATL integration code is aware of
that. I crossed this once when an ATL sink was preventing my
MFC application (which served no objects BTW) from closing,
but all the details have evaporated since... I remember my solution
was to create a new version of the CComObjectNoLock class
since the original didn't suit me for some reason (CComObject
calls _Module.Lock/_Module.Unlock which was the crucial bit
for me). At any rate, I advise you to ask this in the MFC group:

microsoft.public.vc.mfcole

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD

MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================

Quote:

> It crashes where? Maybe MFC has its own module ref count, too, which you
> don't maintain properly. I'm really not familiar with MFC.
> --
> With best wishes,
>     Igor Tandetnik

> "For every complex problem, there is a solution that is simple, neat,
> and wrong." H.L. Mencken



> > I'm not having much luck with this crash. It's something to do with
> the
> > following:

> > void CMainFrame::OnShowWindow(BOOL bShow, UINT nStatus)
> > {
> > CMDIFrameWnd::OnShowWindow(bShow, nStatus);

> > if (bShow)
> > _AtlModule.Lock();
> > else
> > _AtlModule.Unlock();
> > }

> > This works fine if the app is a server or starts up normally.

> > If the app starts as a server, then opens its main Window, when it
> > finally closes, I get a crash. If I remove the Unlock above, it closes
> > but the app hangs around (not suprising really).



Sun, 17 Apr 2005 11:00:53 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. ATL MFC EXE singleton server, single instance application

2. single instance of EXE server

3. singleton exe server event, atl client.

4. ATL Singleton EXE Server

5. Attach multiple executables to single ATL COM EXE instance

6. Single instance of MFC dialog based application

7. running instance of COM object in ATL/MFC server

8. Singleton exe server and ADO IRecrodset

9. Windows 2000 & MFC-exe server + ATL-support

10. Singleton EXE Server not shutting down

11. using MFC Extension DLL from ATL server(exe)

12. Windows 2000 & MFC-exe server + ATL-support

 

 
Powered by phpBB® Forum Software