@Alistair: PI ActiveView does support PI ProcessBook add-ins; in fact, any add-in developed for PI ProcessBook and set to load and execute on startup, also loads when PI ActiveView starts up. But add-ins written for PI ProcessBook can throw errors or disable themselves in various scenarios. I would suggest you first take a look at the PI ProcessBook Add-ins and PI ActiveView, Making them work together White Paper.
We briefly discussed this paper in our Programming .NET Add-Ins for PI ProcessBook webinar, which you can review as well.
Hope this helps!
Sounds like you won't need this option now, but I tend to use VBA code in Excel to automate ProcessBook modifications.
- This has the advantage of letting you create a list of files, and then apply a standard set of changes to each one in succession.
- One such application I have used in the past is to load a standard piece of code into each display.
- The VBE programming environment alows you to edit displays quite explicitly, but I try to make my display code standard anyway.
- What I do is save the code from a tested display into text files, and then have the VBA copy the text into the display.
- You can handle the main class, sub-modules, classes etc
- I can't remember the details, but you do need to delete some of the compiler directives at the start of some file types.
- I can dig out an example if you need it.
Another option if we are talking about common code routines is to have an addin in ProcessBook that hooks into the application object and waits for events, this way common code is only stored in one place but applied to all displays/workbooks. Gets even better by using .Net methods/functions that are stored in a database and compiled when requested by the addin so you never need to recompile the addin again.
Also, have one display (.pdi) that contains all kinds of common routines and have all other displays reference the "common" display to expose all routines (well public routines) to each and every display.