Most current Windows applications support automation with ActiveX, i.e. they can be run by "remote control". ActiveX is based on the "Component Object Model" (COM), which describes both the Microsoft standard for objects in all Windows systems and the libraries which implement this model in the system. COM interfaces are basically objects with properties and methods, and your "remote control" involves modfying these properties or calling an object's methods. A COM class always contains at least one COM interface.
There is now a minimum standard for COM interfaces, which only specifies essential methods and properties. Anything further is specified by the creator of a COM interface, and is therefore naturally no longer uniform. Problems can arise, as accessing methods and properties require knowledge of every interface used, which may require a specific client for each application. Consider one of the most frequent tasks in automating workflows, opening a file. The corresponding method may be called "Open", "OpenFile", "OpenDocument" or "OpenForm", and there may also be localisation-dependent variations. In addition, there may be more than one possibility for passing parameters: the filename is clearly essential, but you may also need to specify the file format or add a parameter for write protection.
To deal with these issues, DataView's new ActiveX automation interface uses IDispatch, which wraps other COM interfaces in a uniform set of methods. Using IDispatch methods, you can call different methods from the same interface, however they are defined. The only requirement is that the automation server suppoirts IDispatch, but since VisualBasic also relies on IDispatch support this is almost always the case.
To use the ActiveX automation interface, you should have some experience in COM technology and object-oriented programming. You'll also need to refer to the COM interface documentation for the application you want to automate.