How automation client recognizes that automation server unloaded 
Author Message
 How automation client recognizes that automation server unloaded

How automation client recognizes that automation server has been
manually unloaded by the user?

Hi all,
I have client C++ application, which connects to whatever automation server.
For it, I wrote simple UtAtomation class which encapsulates IDispatch
interfeace.
Everything works good, but if user manually unloads Automation server, and
continue to work with our application, he/she gets messages likes as  "RPC
is unavailable...".
How my application may recognize that server has been unloaded ?

My solution is :

static UtAutomation* m_pAutomation;

className:method {

// init UtAutomation, create object ,save in the class members
IUknown*,IDispatch*...
       m_pAutomation = new UtAutomation("..");
       ASSERT(m_pAutomation, UtIncorrectCodeError);
       result = m_pAutomation -> CreateObject();

   >>    ..........here goes automation scripts.....

here additional worker thread runs, whith the next thread procedure :
{
// check whether server still running
      while(m_pAutomation -> isServerLoaded(false)) {;}

// send message to main thread - server has been unloaded , do something
::PostMessage(*(HWND*) pWin,WM_WORD_UNLOADED_BY_USER,0,0);
   return 0;

Quote:
}

below code for UtAutomation::isServerLoaded method :

bool UtAutomation::isServerLoaded(bool i_showError)
{
    IUnknown     *pUnknownInterface;
    if (!m_pUnknownInterface) return false;

    HRESULT hr;
    hr = ::GetActiveObject (m_classID, NULL,&pUnknownInterface);
    if (FAILED(hr) || pUnknownInterface != m_pUnknownInterface)
    {
      if (m_pUnknownInterface) m_pUnknownInterface->Release();
      if (m_pDispatchInterface) m_pDispatchInterface->Release();
      if (i_showError)
          MessageBox(0,"COM Server has been unloaded.","Automation
Error",MB_OK);
      return false;
    }
    return true;

Quote:
}

When ::isServerLoaded is called from main thread everuthing is ok, but when
it
is called from thread  GetActiveObject returns  failed HRESULT, even if
server is loaded.


Any advice gratefully accepted. Thanks...



Tue, 22 May 2001 03:00:00 GMT  
 How automation client recognizes that automation server unloaded
Generally, automation apps are not supposed to shutdown until all clients
disconnect. You should construct the app such that if the user selects an
Exit/Quit command then all UI is shutdown (the windows close), but the app
remains active until all clients disconnect. In other words, don't post a
WM_QUIT message from a WM_CLOSE message *unless* there are no clients
connected.

--
Tim Hill -- Windows NT MVP

(Pursuant to US Code, Title 47, Chapter 5, Subchapter II, 227, any and all
nonsolicited commercial E-mail sent to this address is subject to a download
and archival fee in the amount of $1000 US.  E-mailing denotes acceptance of
these terms.)

Quote:

>How automation client recognizes that automation server has been
>manually unloaded by the user?

>Hi all,
>I have client C++ application, which connects to whatever automation
server.
>For it, I wrote simple UtAtomation class which encapsulates IDispatch
>interfeace.
>Everything works good, but if user manually unloads Automation server, and
>continue to work with our application, he/she gets messages likes as  "RPC
>is unavailable...".
>How my application may recognize that server has been unloaded ?

>My solution is :

>static UtAutomation* m_pAutomation;

>className:method {

>// init UtAutomation, create object ,save in the class members
>IUknown*,IDispatch*...
>       m_pAutomation = new UtAutomation("..");
>       ASSERT(m_pAutomation, UtIncorrectCodeError);
>       result = m_pAutomation -> CreateObject();

>   >>    ..........here goes automation scripts.....

>here additional worker thread runs, whith the next thread procedure :
>{
>// check whether server still running
>      while(m_pAutomation -> isServerLoaded(false)) {;}

>// send message to main thread - server has been unloaded , do something
>::PostMessage(*(HWND*) pWin,WM_WORD_UNLOADED_BY_USER,0,0);
>   return 0;
>}

>below code for UtAutomation::isServerLoaded method :

>bool UtAutomation::isServerLoaded(bool i_showError)
>{
>    IUnknown     *pUnknownInterface;
>    if (!m_pUnknownInterface) return false;

>    HRESULT hr;
>    hr = ::GetActiveObject (m_classID, NULL,&pUnknownInterface);
>    if (FAILED(hr) || pUnknownInterface != m_pUnknownInterface)
>    {
>      if (m_pUnknownInterface) m_pUnknownInterface->Release();
>      if (m_pDispatchInterface) m_pDispatchInterface->Release();
>      if (i_showError)
>          MessageBox(0,"COM Server has been unloaded.","Automation
>Error",MB_OK);
>      return false;
>    }
>    return true;
>}

>When ::isServerLoaded is called from main thread everuthing is ok, but when
>it
>is called from thread  GetActiveObject returns  failed HRESULT, even if
>server is loaded.


>Any advice gratefully accepted. Thanks...



Tue, 22 May 2001 03:00:00 GMT  
 How automation client recognizes that automation server unloaded
Re-reading the post I agree that it looks as if he has no control over the
server source code.

As far as shutdown is concerned, there have been several "guidelines"
suggested by MS, most of which are contradictory. The general rule that I
follow, and which seems to make most sense of these guidelines, is that if
the server supports multiple distinct objects, then you should follow the
rule I specified. If the server only supports a single object, then you
should shut down as soon as the user requests it. It's more or less
equivalent to the old SDI/MDI thing. It's not documented as such, but
reading between the lines I think this is what the MFC guys had in mind, for
example.

--
Tim Hill -- Windows NT MVP

(Pursuant to US Code, Title 47, Chapter 5, Subchapter II, 227, any and all
nonsolicited commercial E-mail sent to this address is subject to a download
and archival fee in the amount of $1000 US.  E-mailing denotes acceptance of
these terms.)

Quote:

>Bellow is a clip from SDK documentation for CoLockObjectExternal

>Note The end user has explicit control over the lifetime of an application,

even if there are external locks on it. That is, if a
Quote:
>user decides to close the application (File, Exit), it must shut down. In

the presence of external locks (such as the lock set by
Quote:
>CoLockObjectExternal), the application can call the CoDisconnectObject

function to force these connections to close prior to
Quote:
>shutdown.

>and last time I test, InternetExplorer just works in this way. It shutdown
itself even if
>other applicaiton has a connection / instance pointer to it.

>>Generally, automation apps are not supposed to shutdown until all clients
>>disconnect. You should construct the app such that if the user selects an
>>Exit/Quit command then all UI is shutdown (the windows close), but the app
>>remains active until all clients disconnect. In other words, don't post a
>>WM_QUIT message from a WM_CLOSE message *unless* there are no clients
>>connected.

>I know, for example, MFC based app are generally have this nature. but this
time
>the original poster is I think not an author of that automation

application, and have

- Show quoted text -

Quote:
>no control over server's behavior. Automation client can't expect that
server will
>always acts as you describe. So, what is your point, MVP?



Tue, 22 May 2001 03:00:00 GMT  
 How automation client recognizes that automation server unloaded
Bellow is a clip from SDK documentation for CoLockObjectExternal

Note The end user has explicit control over the lifetime of an application, even if there are external locks on it. That is, if a
user decides to close the application (File, Exit), it must shut down. In the presence of external locks (such as the lock set by
CoLockObjectExternal), the application can call the CoDisconnectObject function to force these connections to close prior to
shutdown.

and last time I test, InternetExplorer just works in this way. It shutdown itself even if
other applicaiton has a connection / instance pointer to it.

Quote:
>Generally, automation apps are not supposed to shutdown until all clients
>disconnect. You should construct the app such that if the user selects an
>Exit/Quit command then all UI is shutdown (the windows close), but the app
>remains active until all clients disconnect. In other words, don't post a
>WM_QUIT message from a WM_CLOSE message *unless* there are no clients
>connected.

I know, for example, MFC based app are generally have this nature. but this time
the original poster is I think not an author of that automation application, and have
no control over server's behavior. Automation client can't expect that server will
always acts as you describe. So, what is your point, MVP?


Wed, 23 May 2001 03:00:00 GMT  
 How automation client recognizes that automation server unloaded
Thanks Hill for responding my rather offensive asking - "what is your point?".

I'm looking forward to see all the automation server capable applicaiton
will follow that guideline.

Quote:

>Re-reading the post I agree that it looks as if he has no control over the
>server source code.
>[snip]



Fri, 25 May 2001 03:00:00 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. How automation client recognizes that automation server has been.

2. VB client to VC++ server, automation debugging

3. OLE Automation, Client to Server debugging

4. COM-Automation Server - client stub files ???

5. C++ Automation server calling client

6. Automation server and events to clients ?

7. Need sample for server calling back client in OLE automation

8. Distribution of Automation Client/Server

9. prob: VB 4.0(16bit) client of VC++4.2 automation server

10. Memory Leaks in Automation Client

11. automation clients & ado recordsets

12. Automation Client and 2D array

 

 
Powered by phpBB® Forum Software