Hello vCampus world!
Here at OSIsoft, we're thinking hard about ways to move our primary graphical client tool, PI ProcessBook, into the future. Many of you have expressed the desire to have these capabilities provided using newer technologies, and especially to make the result web-friendly. While we have some major developments going on in that direction, there is one open, burning question that needs to be addressed: How to handle all the existing content folks have that relies on VBA?
This is a burning question because there is no support for VBA scripting in most of the web-facing technologies we've considered. Microsoft doesn't even have an upgrade path through VSTA (we've asked).
So, the input I'd like to collect from you developers here, is how problematic is it for you and your customers to have no VBA-equivalent in a graphical tool?
Is there an identifiable set of behaviors that we could build in that would make VBA unnecessary? I have my doubts that we could ever cover everything people do now--our mission is to provide the tools to match data to graphics and not to build specific solutions to meet every need (some of you make your living doing the latter part using our tools).
Is it acceptable to have a different kind of extensibility model? This would require re-implementing any custom behaviors you may have already implemented for the existing tools we offer. Seems like not an ideal solution, but is it really unreasonable?
What areas of functionality do you see being most affected? Display appearance (e.g., setting colors and fonts)? Data-driven display changes (e.g., conditional formatting based on multiple inputs; showing/hiding display components conditionally; adding/removing data to display elements (e.g., adding or removing a trace)? Printing routines? Manipulating time on displays? Something I haven't mentioned at all?
Please respond on this post with your ideas, opinions and concerns.
OSIsoft Product Manager, PI ProcessBook/PI ActiveView