Having used ArchestrA System Platform for a while now, along with all the benefits that come with it, I found it really frustrating to be working in InTouch.
Just to be clear, System Platform still has InTouch but everything I need to do is done within the ArchestrA environment. That is, I still have to create an InTouch window and I might have a few InTouch tags and a few minor window scripts. But essentially everything else is contained within objects inside ArchestrA. Whereas, StandaloneInTouch is just that, everything is contained in the one InTouch application.
Reusable Graphics with Inbuilt Tagging
For a while we have been trying to get this customer to migrate to System Platform but from their point of view the expense just not worth it. Everything was working fine for them. But I ask you, how much more expensive is it compared to the amount of time wasted performing the same tasks in InTouch?
So, my plan of attack has now changed. Customers who are looking solely at the dollar cost are not really appreciative of the benefits. I mean, why would they if they have never used the product?
That’s why I’m here. To tell you why System Platform is so much better. So, I decided to go through some real-life experiences developing in InTouch and how I would do this in SP.
Lucky for me I was making another InTouch window for an existing application so I could copy the existing graphics and reuse them. The real problem I had was with the tags. I started out by creating tags and decided to use super tags to keep things all nice and neat. I had to create 20 valve objects with four properties each. Right there, if I was using SP I would have created a valve template and added the four User Defined Attributes (equivalent to InTouch tags). From here I would have just gone and created 20 instances of my valves. 10 minutes work… tops.
Lucky for me I was making another InTouch window for an existing application so I could copy the existing graphics and reuse them. The real problem I had was with the tags. I started out by creating tags and decided to use super tags to keep things all nice and neat. I had to create 20 valve objects with four properties each. Right there, if I was using SP I would have created a valve template and added the four User Defined Attributes (equivalent to InTouch tags). From here I would have just gone and created 20 instances of my valves. 10 minutes work… tops.
Definitely an easier task in System Platform than in InTouch but I guess neither here nor there at this point. The real differences came about when I had to modify things.
Scalability is solved!
The first problem I ran into was that our electrical engineer later came back to ask me to add an additional tag for the valves that he had forgot about. Simple, just add it to my supertag template. I could modify the template but couldn’t apply to existing objects, only new ones. What I needed to do was first find all graphics where I referenced the super tag, delete the reference then delete the supertag so that I could recreate it, then re-reference in the graphics. What a pain!
I did actually do this (delete and recreate) for a couple of objects because at the time I only had two so wasn’t a big drama. But 20! No way! So, I decided to create the tag outside the supertag and chastise myself for trying to be clever by using supertags in the first place. What a mess! I now had tags existing as supertags and normal tags. 20 valves had to be updated and not only that I had to go into each graphic symbol and update each action script as well because I was using indirect tags for a popup.
Do it once, reuse over and over!
In System Platform all I would need to do is add the UDA (tag), update the template graphic and…well that’s it. The change would be propagated down to all the instances automatically and all I would need to do is deploy out to production. 5 minutes as opposed to half an hour, plus the time to go back and fix a typo for one of them. Also, because in System Platform I create the graphic symbol once at the template level if I needed to change that graphic in any way, I would only have to do it once and all instances that use that graphic would be updated. No fuss. In InTouch I would have to go to each graphic symbol, break it, modify it, then remake it, reposition it because it moved, then go onto the next one, only to find I forgot something that I would have to go back to the beginning and do it all over again for each object. In System Platform, if I modify a graphic in a template, and because I am using ArchestrA graphics, then on the InTouch window where they appear I don’t need to even touch the window as it is updated automatically with my changes, so no graphic alignment issues.
Also, in InTouch, if I used an action script for a graphic, and if I had several graphics of the same type with the same functionality, I would have to copy this script to each and every graphic. In System Platform, to accomplish the same task I would modify the template ONCE and all instances of that template would have the change without the danger of incorporating additional typos as I copied, as I did do when modifying the InTouch graphics.
No Need for Indirect Tagging!
A great feature of System Platform is that I don’t need to use indirect tagging to display a common popup for all my valves. I simply create a graphic in the template for the popup, then on my valve graphic create a Show Symbol animation that opens the popup (e.g. me.Popup) and that’s it. When I click on the valve graphic the popup will open, referencing my object tags (e.g. me.OpenedLS). No need for an indirect tag anywhere!
With this feature I can display multiple popups at the same time. That is, because each popup is related to an instance of say a valve I can have several popups open for each valve side by side. Whereas, in standalone InTouch, because of the use of indirect tagging, I can only display the popup for a single valve at any one time. That is, I need to close the currently open popup, and clear any indirect tags I have used before I can open a popup for another valve.
In all, for this small project I calculated that I would have saved several days development and commissioning time if we had have been using ArchestrA System Platform instead of developing in standalone InTouch, because I didn’t go through the above scenario once, but many, many times as we developed and commissioned with this application.
So, for all those die hard standalone InTouch developers out there. Have a go at using ArchestrA and experience the pleasure for yourselves.
By Chris Van Duin
