"On Show" script substitute for ArchestrA graphics

-
While developing a control screen using ArchestrA graphics, I found that the "On Show" script provided for graphics is flaky at best. This is especially apparent when referencing dynamically referenced objects in the script. In this case, the graphic can be used by several different objects. In order to allow it to get it's bearings on startup, it is embedded in another graphic. That graphic has a "while showing" script with a statement something like this:

MyGraphic.OwningObject = InTouch:MemoryNodeID + "some other text to dynamically build the object name";

This allows me to use "Me.WhateverUDA" type references in my graphic to interact with the object assigned as "OwningObject" above. The problem is that any "Me.WhateverUDA"-type statements I put in the "On Show" script don't work because of timing issues. The "On Show script apparently fires before the "OwningObject" statement above. The result is that "Me.WhateverUDA" means nothing & anything I do with it fails. Simply, it doesn't YET know what "Me" is referencing.

So, as with most things done in Wonderware products, I had to find a workaround. Here's what I came up with: I created a private custom property called "Reset" with a default value of true. I then created a named script for the graphic and set it's expression to "Reset" and it's trigger to "WhileTrue" with a Period of 500ms. This 500ms delay essentially waits a half second after the graphic loads to fire the script. This allows the owningobject to be set so the "Me" expressions will reference the correct object.

In the script, I simply set Reset to 0 (false), and did what I needed to with my "Me.WhateverUDA" statements.

Comments

Post a Comment

Popular posts from this blog

Fixing Conan Lock Issues

-
I've been implementing Conan as our C++ package manager, and I had the following issue cause me a fair amount of grief over the last couple days: [MyPackageName] is locked by another concurrent conan process, wait... If not the case, quit, and do 'conan remove --locks'  You would be forgiven for thinking conan remove --locks should do the trick, but alas, it does not.  After finding hints on several Conan Github issues, I finally figured out that manually removing the package folders in one or both of the following places will alleviate the issue: Windows : C:\Users\username\.conan\data\packagename WSL/Linux : /home/username/.conan/data/packagename
Read more

Dynamic Object Oriented programming in ArchestrA

-
As with most developers using Wonderware products, I often have to get creative to compensate for the limitations in the development platform, scripting language, etc. Lately, I've been need to create "objects" (in the object oriented programming sense of the word, not the app server sense). That is I need collections of data describing some real world thing. For example, I have been creating a callout feature for a client's SCADA host system. The callouts are stored in a SQL database and my scripts pull out a whole set at a time. Each callout has various attributes such as the callout type, the comparison operator (>, <, =, >=, <=), the setpoint, etc. This presents two issues. First, how do I keep all of these pieces of information together for each callout without creating & deploying App Server objects for each one. Second, at any given time, there will be a variable number of callouts. I have used the following method (read complete hack
Read more

Initialize With Care

-
Pointers are funny things.  They are one of the make or break concepts for beginners, and even years later, they can cause grief to experienced developers.  I am no exception.  Here is one such story: I was faced with a class which I wanted to refactor.  It can be simplified as follows: In the interest of breaking up the responsibilities, I added a couple of interfaces. The idea is that I can pass around smart pointers to these interfaces and begin to decouple portions of the code.  For example, I can inject them into classes that need them: However, I made a mistake.  I blame it on years of using boost::intrustive_ptr instead of std::shared_ptr, but enough excuses.  Let's see if you can spot it. Do you see it?  If so, give yourself 5 points.  If not, maybe after seeing the output: 'second' going out of scope... Destructor 'first' going out of scope... 'root' going out of scope... All done... Both shared pointers ( first & second ) are created from the
Read more