FTView Abort Display Issue

I have an SE application that loads multiple copies of the same display (a small process faceplate) with different parameter files for each. If the user selects a different control the displays are unloaded one at a time, and then new displays are loaded based on the user selection.

The issue I'm seeing is that sometimes all of the displays don't completely unload, and the cumulative effect over the course of several days is that there are numerous displays taking up memory (yet not visible).

I've isolated the problem to a Timing issue with command execution. If I put a 2 second pause between unload commands it works most of the time, but even then it sometimes leaves a straggler or two behind.

Ideally, if the command processor would provide some feedback that a command had successfully executed I could condition subsequent abort commands off the previous completion, yet I can find no direct method of doing this other than writing to a memory variable from the Load/Unload subs of the display, which of course only adds an additional delay to processing commands.

Has anyone else had a similar issue? Any suggestions / workarounds / undocumented features that might offer some relief? Any advice is appreciated.

Sigh...
FTView SE... Don't allow multiple copies to be loaded.
On the display itself (in the editor), Right click the display, and uncheck "Allow multiple running copies". Then set it as a "Replace" display, so it will auto-close anything under it.

It's a pain, but, well, the software is pretty bad.

rdrast said:

Sigh...
FTView SE... Don't allow multiple copies to be loaded.
On the display itself (in the editor), Right click the display, and uncheck "Allow multiple running copies". Then set it as a "Replace" display, so it will auto-close anything under it.

It's a pain, but, well, the software is pretty bad.

Click to expand...

RD,

Thanks for the suggestion, however in this application that will not work. I need multiple copies to be able to run, and they cannot be set to Replace Mode, because they are very small individual displays that overlay a larger main display.

Here is the basic layout;

Main display contains a Treeview Control for Navigation of 7 Systems each containing several hundred process variables. When the user selects a node in the Treeview Control, depending on the node, between 1 and 14 of these displays are loaded each with a different Parameter File (variable set) along the bottom of the main display. When a new Treeview Node is selected the current displays are aborted, and new displays are loaded with different parameter files.

If I load the Main Display with a /DT to dock the display then I can execute an 'Abort All' and retain my main display with current navigation, and all Faceplate displays unload nicely. However, other displays cannot be placed "Over" a Docked display, because docking simply shifts the available screen real estate for the other displays.

If I Don't Dock the main display I can arrange the sub displays any way that I like wherever I want over the main display, but then I have to individually abort the subs to prevent losing the Main.

This is really a serious limitation of RSV/FTV in my opinion.

The real problem comes in when I have 4 or more of these displays loaded. They all appear to unload, but are actually still resident in memory. You can Break the program from the VBA window (In Debug Mode) and reissue the Abort command in the immediate window and watch the resident displays unload even though the graphic for said displays aren't visible. But if you execute this programmatically, the VBA code executes faster than the command processor can handle the requests, thus you end up with a few that don't unload, unless you slow down the code execution. But this begs the question, how much to slow it down, because it varies from machine to machine and from execution cycle to execution cycle depending on CPU and Memory load.

Rockwell should provide a callback from the command processor to indicate a completed command, but alas, as you said it is pretty bad.