Accessing a single EXE automation server from VBScript

Posted on 2005-04-07
Last Modified: 2013-11-20

Is it possible to launch an executeable automation server without the /Automation command line parameter, and then have an external VBScript access the exposed objects from that particular instance of the server?

Basically, I want to have an application that can be launched by the user, which is accessed and manipulated by external VBScripts. I only want one instance of the application to ever be present. If the application doesn't exist, then I want it to be automatically launched by the VBScript. The app should stay open after the VBScript has finished with it.

My current situation is that if I manually run the executable (i.e. without the "/Automation" command line parameter), and then run a VBScript to access the automation objects exposed by the application, it just starts a new instance of the application, rather than using the existing instance.

Secondly, if I run the application WITH the "/Automation" command line parameter, the VBScript is able to access the instance correctly, BUT(!) the application shuts down as soon as the VBScript has finished with it.

It's not a major problem to have to start the app with the automation flag, it's just a bit untidy. Although in which case, I need to know how to stop the app shutting down after it has finished with it.

Ideally, an answer would tell me how to do get what I want without having to use the automation flag at all.

Thanks in advance.


Question by:fxnut
    LVL 9

    Expert Comment

    Do you have the source code of the server application?

    If you do, you can change it so that:
    1. it doesn't require the automation switch
    2. it remains active/running if started without the automation switch, even after all clients have released their COM pointers

    If you don't have the source code, you are stuck - short of wrapping the existing server in another one that you would have to write and which would act as a broker/manager to the original server. Btw, this solution would have performance issues due to the double marshalling layer involved.

    LVL 1

    Author Comment

    Hi Radu,

    Yep, I can't believe I didn't think of your first point that you stated! Obvious, yet effective. Thanks :-D

    Yes, I do have the source code of the server app. It's just a simple MFC project with Automation enabled on it. The problem I'm having is that when the internal CCmdTarget derived object is finally released by the VBScript, my application quits. I traced this problem down to the override of the OnFinalRelease() function, where it simply calls the base class's implementation of it. It's this function that closes the program. If I comment it out, it works okay and doesn't quit, but I'm a little worried that there may be some resources that remain allocated if I don't call this function from the base class.

    Do you know what the OnFinalRelease() function actually does? I'm wondering if I can implement it myself and just leave out the part where my application is forced to close (which, to be honest, seems a little "rude" - what if I had to release my own resources external to the CCmdTarget derived object in my app?).

    Do you think it would it be dangerous for me to call the object's CCmdTarget::OnFinalRelease() function manually when I'm about to shut the app down myself?

    LVL 9

    Accepted Solution

    CCmdTarget::OnFinalRelease is called on the COM object (represented in an MFC application by a CCmdTarget derived class instance) when the last reference to the object was released by the client.
    You are supposed to release associated resources and delete the CCmdTarget object at this stage. If you don't, you're going to leak memory/resources.

    The easiest way to conditionally keep your MFC COM server alive is to create/instantiate one of your COM objects right in your server (e.g. at start-up). Then, on close, release this COM object and go through the normal shut-down procedure.

    LVL 1

    Author Comment

    Cool, thanks for your help :-)

    Featured Post

    How your wiki can always stay up-to-date

    Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
    - Increase transparency
    - Onboard new hires faster
    - Access from mobile/offline

    Join & Write a Comment

    In this article, I'll describe -- and show pictures of -- some of the significant additions that have been made available to programmers in the MFC Feature Pack for Visual C++ 2008.  These same feature are in the MFC libraries that come with Visual …
    Introduction: Load and Save to file, Document-View interaction inside the SDI. Continuing from the second article about sudoku.   Open the project in visual studio. From the class view select CSudokuDoc and double click to open the header …
    This video will show you how to get GIT to work in Eclipse.   It will walk you through how to install the EGit plugin in eclipse and how to checkout an existing repository.
    Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.

    734 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    16 Experts available now in Live!

    Get 1:1 Help Now