Error viewing variables tab after running edit UI

[JoshM77]

Hi,

I have a problem that seems to be somewhat like this:

http://forums.ni.com/t5/NI-TestStand/Error-viewing-variables-tab-in-Runtime-Operator-Interface/m-p/1...

The VI I am trying to run is an edit substep of a step type. LabVIEW checks to see if the "Step.Setup.ReadMeasName" property exists, populates a listbox with it if it does. Another listbox with all the available measurement names also appears on the UI. The user has an Add and Remove button to remove measurements from the "ReadMeas" listbox or add them to it from the "MeasNames" listbox. Multiple names can be added/removed at once depending on whats selected when the buttons are pressed. Once "Done" is clicked the VI writes the"ItemNames" property of the "ReadMeas" listbox to "Step.Setup.ReadMeasName", using a Set Property Value node which is passed the TestStand Sequence Context. If the property doesn't exist it creates it.

The only time I have any problem is when I try to remove items from the property after it is already initialized (i.e. not empty). In other words, if I run the VI from teststand, put several measurement names into "ReadMeas" click done, run the VI again (the names already added appear in the box when the UI comes up, LabVIEW reads "Step.Setup.ReadMeasName" ), and then remove some of the names. IF I had "ThisContext.Step.Setup.ReadMeasNames" opened in the step "Variables" tab when trying to remove the names this message appears in the Variables tab: "One or more errors have occurred. Please Save your work and restart the application." If I make sure not to have "ThisContext" expaded in the variables tab, but check the property before and after removing names from the list it does work properly and there is no error.

This isn't a big deal becuase I doubt the end-user will be checking to see that the property actually got populated, but I still would like to fix the bug if possible. I've installed the patch for TestStand 2010, and the .Net framwork 4.0. Anyone have any idea what could be going on here?

Thanks,

-Josh

[dug9000]

You are probably not incrementing the change count on the file after making your edits. You need to increment the change count because that is the way the sequence editor or UI knows you have made an edit in your edit substep and thus then knows to refresh its controls and add an undo item, etc.

One way to increment the changecount on the file is:

seqcontext.SequenceFile.AsPropertyObjectFile().IncChangeCount()

Hope this helps,

-Doug

[JoshM77]

Doug,

I have a feeling that you are right, the template I started this project on origanally did that but I removed it because I was getting an error. When I have time I will verify that this is a solution to the problem, thank you very much for the help!

-Josh

[JoshM77]

I used the method Doug posted to increment the change count each time the UI is closed. I watched the change count in the variables pane and confirmed that it was updating. I still seem to be getting the same error though. It's still triggered by removing items from the already populated list via the UI while having the step property open in the variables tab.

This error isn't a dealbreaker for my application, but I still would like to fix it if possible. If anyone has some more input that would be great. I may try running this VI on a differenct PC, I will update when I do.

Thanks,

Josh

[dug9000]

Are you running the code module as an edit substep or are you calling it directly as code module in a different step type? Where are you incrementing the change count? It should be done inside the edit substep before it returns. Can you reproduce this problem in a simple case you can attach to this forum post or describe?

-Doug

[Manooch_H · Accepted solution]

Josh -

It looks like you're running into a Known Issue 193751, which is documented in the TestStand 2010 and 2010 SP1 Known Issues List. This is an issue that we intend to fix in a future version of TestStand.

I hope this helps and am sorry for any inconvenience this issue may be causing you.

[JoshM77]

Thanks for clearing that up. It's not going to cause any problems for the end-users of the step types I am developing, just was a bit puzzling when I was debugging them.