The ArchestrAnaut

One of the best parts of using Archestra graphics in your application is the ability to freely resize the vector based graphics with no apparent loss in resolution.  The other nice thing is that as you update the size of the graphic in the design tools the graphic follows suit and grows or shrinks as necessary anywhere it is laid down.  This may be fine if you have an item in free space with no connections or other items close by.  This causes a big problem though if you are laying down graphics in tight quarters and can’t afford for things to wiggle around.

Example:

Let’s start with a simple pump graphic.

Then let’s lay it down on a process graphic with process lines connected

Note on the left hand side that my pump is actually an embedded symbol.

Now, say we want to go back and add some decoration to this pump.  Maybe a piece of text under the pump.  It’s important to remember that when Archestra looks at the size of the graphic it looks at the extents of all elements.  If you go outside those extents Archestra thinks you want to make the graphic bigger.  As such, when making the graphic bigger, Archestra will expand the graphic in all directions equally from the origin i.e. the middle.  It’s pretty easy to see on this example.

Note the 2 shifts.  First, the obvious one.  The graphic grew up and down.  The up growth is easy because you see the separation from the blue lines.  The down growth isn’t easy because I don’t have a marker.  Also, note that the graphic grew to the left and right. 

So how do we fix this problem.  Very simple.  You have to think back to the extents concept.  When you draw your graphic, think about the biggest it could possibly be, including text and other symbol decorations.  Let’s try that with our pump example.

I’ve gone a little overboard but I’ve basically set up some boundaries.  Now I lay it down on my target graphic, lining up my process lines.

Now, I go back and add that text I had before.

Notice that nothing moved around, nothing grew, nothing shrunk.  The reason is that by drawing the box before I laid the graphic down I established the extents or bounds of the graphic.  Now I can do anything I want inside the boundary without changing the “apparent” size.

The word “apparent” is key to making all this work.  Drawing this ugly rectangle works for design time but would look awful at runtime.  Easy way to handle this.

Set the Visible Runtime Behavior property to False.  Now, you can see the rectangle during design time but it will disappear during runtime.  Also, if you like you could make the rectangle really really light gray so it’s not distracting during design time.

Hope this little tidbit helps someone!

- Andy

Just ran a quick test on ArchestrA graphics to verify when the OnShow & OnHide scripts execute.  I was also testing if AA graphic objects’ visibility properties are updated when the InTouch visibility was updated.  Nothing Earth-shattering here, but just a quick FYI.

Read the rest of this entry »

If you are a blogger on a decent platform one of the metrics you will see is what kind of search terms people used to find out.  We run WordPress so we get this kind of useful intel.  When I see certain terms I want to run off and write a white paper on it because some is interested and I want to teach.  Unfortunately I just don’t have that kind of time.   With that in mind I have decided to take a handful of search terms, either frequent ones or interesting ones, and write a one or two line blurb about each.  They may distill down to even to two or three world comment.  Hopefully it will help someone along the way.

So,  without furuther ado I present the First Edition of of Search Term Lightning Round

Read the rest of this entry »

We are working with one of our customers on an application that runs via remote desktop on a terminal server but is served up on a handheld scanner device.  We have to do a lot of fancy footwork to make the user experience a little more seamless since they don’t have a mouse to click around everywhere.  Below is a repost of a comment by one of my colleagues describing an issue we had and a warning on what you should look out for.

A word of caution on SendKeys that I learned the hard way over the last month or two. Here is the scenario. You have an Archestra symbol that uses the SendKeys function to send a key sequence to a pushbutton (with an assigned hot key) on the Archestra graphic, like a close button to hide the symbol. Say this function is in a graphic data change script that is looking at a variable at the module level.

 
Figure 1.  Hide Symbol Animation on a Button using a SendKeys alias

Figure 2. Script Performing SendKeys Operation

This is actually the technique that Andy describes above that we use to programmatically “hide” symbols. Your Archestra symbol is embedded in a managed application which is deployed to a terminal server. Open up an RDP session and open the graphic that the symbol is on. Now minimize the RDP session to the taskbar. Using object viewer, set the variable in the module that causes the symbol’s datachange script to run which in turn executes the SendKeys function. Guess what happens, the processor that the InTouch application is running on will elevate to 100% and stay at 100%, every time. The View.exe process will also start leaking memory, about 40K a second. In our case the excessive CPU actually caused Suitelink to stop completely causing all kinds of problems with another application running on the terminal server. The CPU will remain pegged until you maximize the RDP session at which time it drop back to normal. I guess I understand it from a windows standpoint and I also understand that it is a very specific scenario, but a real one in any case. Wonderware tech support confirmed the scenario and recommended that SendKeys not be used in this scenario. Just something for you to consider when thinking about SendKeys.