Event Scope

Although the web service events feature was designed to hook to all Vault clients on a computer, it doesn't meant that it is required to hook to them all.  Sometimes you want to hook to an event for just one application, and that's fine too.

I'll refer to the scope of the event as the set of applications that you are interested in receiving events from.

Scenario 1:  Global scope

If you want to get events from all Vault clients on a computer, you can follow the instructions in the SDK documentation.  The "Web Service Command Events" page in the Getting Started section goes over all the details.  Here is a basic summary:

1. Create a DLL project.
2. Create a class that implements the IWebServiceExtension interface.
3. Subscribe to events in the OnLoad() function.
4. Write your event handler logic.
5. Set your <extensionType> to WebService in the .vcet.config file.
6. Deploy to the ProgramData folder.

Scenario 2:  Vault Explorer scope

Let's say you only care about events within your Vault Explorer plug-in.  For example, you have a custom command or tab view that needs to know about these events.  The steps are different in this case:

1. Open up the DLL project for your Vault Extension.
2. Do not implement the IWebServiceExtension interface.
3. Subscribe to events in the OnStartup() function for your IExplorer implmentation.
4. Write your event handler logic.
5. Your <extensionType> is still VaultClient in the .vcet.config file.  No changes or additions are needed.
6. Deployment is still to the ProgramData folder.  Again, no changes.

Scenario 3:  CAD application scope using a plug-in

If you are plugging into a CAD app, the steps are very similar to scenario 2.  The main difference is that your plug-in will have a different set of rules on how to set up and deploy.  Here are the steps, at a high level:

1. Open up the project for your CAD plug-in.
2. Do not implement the IWebServiceExtension interface.
3. During startup, subscribe to the web service events from the Vault API.  This assumes that the CAD API framework lets your code run during startup.
4. Write your event handler logic.
5. Deploy according to the rules of the CAD framework.

This technique will allow you to hook to all the Vault web service events for that CAD application, even if another plug-in fired them.  For example, you can write your own AutoCAD plug-in which responds to events from the default Vault plug-in.

Scenario 4:  "Application X" scope without using a plug-in

If you want to scope your event to an application, but you can't write a plug-in, there is still an option.  All you need to do is follow scenario 1.  In step 4, when you are writing your event handler logic, check the name of the running process.  If it's not an application you want events from, exit the function.

There is no perfect way I know of to get the name of the current process.  The safest ways is probably to can use the first value from System.Environment.GetCommandLineArgs() to find the application name.  You can also use System.Diagnostics.Process.GetCurrentProcess().ProcessName, but it might throw security exceptions depending on the user permissions.  System.Windows.Forms.Application.ExecutablePath is also unreliable because it only works for Windowed applications.

The nice thing about this technique is that you can allow multiple applications.  Or you could use it to exclude specific applications.  For example, you exit the event handler if the application name is "JobProcessor.exe".