VSTA Macro Concepts | ||
| ||
Overview
This section contains an overview.
Microsoft Visual Studio Tools for Applications (VSTA) is smoothly integrated within V6. Users already accustomed to writing VBA macros in earlier releases can migrate to this new technology to benefit from new .NET languages for writing their scripts.
The existing Macros UI has been enhanced with a new sort of macro library, called a PLM VSTA project.
As for PLM Directories and PLM VBA Projects, you can also create a new PLM VSTA Project, add an existing one, or remove one. A PLM VSTA project is mainly defined by its name and its language (VB.NET or C#).
A VSTA project, when opened, will be built and introspected so that its macros (i.e. public subs in VB.NET or public functions in C#, whose name starts with "Macro") are displayed.
You can then run a macro (in optimized release mode or in debug mode if you check an option), edit a macro in the VSTA IDE (built upon the well-known Visual Studio IDE), rename a macro or delete a macro.
These actions are basically the same as for the other existing types of macros libraries, except for the release/debug mode concept.
When you edit the VSTA project within the IDE, the whole V6 Object Model is be accessible via IntelliSense. This technology allows auto-completion while typing.
Note that VSTA natively supports 64-bit platforms, whereas VBA does not.
Performance, Capacity and Scalability
This section discusses performance, capacity and scalability.
The new VSTA v1.0 technology is supported by the .NET framework v3.0, which impacts macro development at three levels in comparison with VBA:
- The .NET framework provides a huge and rich API for add-in developers; on the other hand, it takes some time to load at start-up (up to one minute to display the Tools>Macros GUI the first time the user clicks on it). Other areas of the Macros GUI responsiveness are impacted, as the .NET interoperation relies on a remoting technology which introduces loss of performance. In general, Dassault Systemes makes no commitment whatsoever regarding VSTA performance and will not accept any performance regression as compared to VBA integration. The customer may continue to use VBA with no performance hindering, as VBA remains available alongside VSTA.
- Build time: there is no such concept of building a VBA macro project, as VBA is an interpreted programming language. Opening a VBA project only takes a couple of seconds, and makes it readily available in the GUI. On the other hand, VSTA projects are written in C# or VB.NET, which is first compiled and linked into a Common Intermediate Language, resulting in a DLL assembly. This phase, for a small project, takes a few seconds to achieve, before the project can actually be introspected (i.e. before macros list is displayed in the GUI) or run.
- Run time: as mentioned before, the remoting technology used by the .NET framework to allow interoperation between the unmanaged world of V6 and the managed world of VSTA impacts performance and GUI responsiveness.
Compatibility
This section discusses compatibility.
VBA remains available and fully functional for end customers, as many resources have been invested in VBA macro development. VSTA integration does not alter the way VBA works.
Limitations
This section describes limitations.
Limitation 1: Complexity
The most visible limitation is a direct drawback of the power brought by this new technology: the end user must now understand what a programming language really is, dealing with issues such as compilation, release/debug modes, using a complex IDE with debugging windows and debugging concepts etc.
As for the language itself, VB.NET is close enough to VBA, avoiding the complexities of C#. Yet, as of January 2008, there is no available tool for an automated migration of VBA projects to VSTA projects.
Limitation 2: Macro naming
In VSTA, the concept of Macro corresponds to C# or VB.NET methods, whereas in VBA it corresponded to modules. To separate actual macros to be listed in the Macros GUI from helper methods or utility methods, a naming rule has been introduced: a macro name must start with "Macro". For example, the error popup like this will appear if the user tries to bypass this rule when renaming a macro:
Similarly, a macro is basically a sub in VB.NET or a method in C#. Thus, some reserved characters cannot be used (dash, sharp etc.).
Limitation 3: PLM integration
VSTA projects rely on a file-based view. The PLM integration aspect is achieved by persisting this view in the ENOVIAV6/MatrixOne database.
Therefore, the end-user must understand that actions which influence the (hidden) file-based view will influence in turn the database view, e.g. simply building a VSTA project causes its source files to be saved in the projected file view, hence committing them back in the database (even if the source files contain build-time errors).
This may have a performance impact if the network suffers latency, or a collaborative impact if other users are trying to manipulate the same VSTA project at the same time.
Limitation 4: First-time users must restart CATIA once after VSTA registration
Microsoft VSTA documentation acknowledges that each different user must register VSTA with the host application (i.e. CATIA) so that configuration files are copied to the local user profile.
CATIA automates this step when a new user tries to create a VSTA macro library for the first time. Note that the creation will fail with the following 3 successive errors:
As the error 1712 explains, after CATIA restart, VSTA should work as expected. Therefore, if this is your first time using VSTA in the V6, you should create a dummy VSTA macro library (i.e. whose PLM name is not important) before creating your actual working library.
Limitation 5: VSTA cannot be executed from a network share
As with all .NET applications, VSTA assemblies cannot load from a network share unless they are signed by the manufacturer and a specific .NET code execution policy has been set.
For the moment, you will get the following error if assembly loading has failed:
To bypass this, you can copy:
CATVSTAIntegration.dll
to a local folder on your computer, and start CATIA again with the concatenated full path. This means that you have to ask your administrator to modify the CATInstallPath variable using the environment editor.
For example, if the variable value was:
\\networkshare\CATIAInstall
the administrator can modify it on your computer to:
C:\temp;\\networkshare\CATIAInstall
This supposes that you have copied CATVSTAIntegration.dll from:
\\networkshare\CATIAInstall\yourOS\code\bin
into:
C:\temp\yourOS\code\bin
where:
yourOS
can be intel_a or win_b64.