Update step fields after using an Edit Step

[CyGa]

When you use an edit step to modifiy the values contained in your step inputs/outputs, the fields are not updated with the new values. You have to close the step tree branch and reopen it to see the updated values. A good idea would be to refresh the step section after the execution of an edit step !

[dug9000]

Your substep must not be incrementing the file's change count. If you have the source code, you should add something like:

sequenceFile.AsPropertyObjectFile.IncChangeCount();

to the end of the code after the user has pressed ok on the dialog. If you do this then the variables view will get refreshed when your edit substep completes. Also the file will now be correctly marked as modified and undo will now work.

Hope this helps,

-Doug

[CyGa]

Indeed this helps !

Anyway, I think this should be done automatically without having to 'manually' increment the file's change count. If an edit step runs, I think TS could detect it and increment by itself the file's counter.

[dug9000]

The issue is that you probably don't want the file to be marked as modified and an undo item created if the user pressed the cancel button on the dialog. TestStand could potentially diff the step before and after the edit substep to see if it was modified though. But that then assumes the editsubstep only modifies the step that is active. It might modify other steps or settings on the sequence or sequence file. Perhaps TestStand could require that editsubstep code that modifies anything other than the active step must still explicitly call IncChangeCount(). That might be sufficient.

[CyGa]

An easy way to do this is to generate a "refreshUI" event each time a variable (local, global, station, step...) is changed when editing sequences (not while executing them of course)... That way, no change would be made to file's counter or other 'hidden' properties. A slow loop (250ms)checking the difference between well chosen variables should be enough to fire such event.

[tomhigh]

 I've encountered a simular isses. I have  many Custom Steps that change Step Variables and none of those changes are recognised by the sequence editor as a change to the sequence file that requires saving. These changes immediately show up in the step's "Property Browser", so TestStand knows that a change has occurred. This is documented in trouble call #7355028.

 I was given the work-around of adding the "sequenceFile.AsPropertyObjectFile.IncChangeCount()" code to my module code and it works OK, but I really would consider this a bug.

Even more interesting is that the step value changed with no change registered in the file, but if I hit CTRL-Z to undo the change, the variable will be restored to it's previous unchanged condition and the sequence file then thinks it has changed and needs to be saved even though it's now in the un-changed condition.

 I will admit that properly using the "sequenceFile.AsPropertyObjectFile.IncChangeCount()" call does properly sync the changes with the sequence file status, so the work-around does work correctly.

Thanks,

   Tom

[dug9000]

I suggest that everyone who has hit this issue should kudo the idea so we have some idea how common this problem is.

[Josh_W]

I ran into this issue.

But as Doug describes, we don't want the change count incremented in the case when the user selects 'cancel' from the edit step.We will have to modify our edit steps to do this, but the current behavior is sufficient.

[CyGa]

The current behavior is sufficient as long as the workaround is sufficient. Kudo-ing would be really helpful for those who are expecting this behavior to change ! Most of the time the number of kudos is not relevant on how important a change is needed... but it seems that it's NI barometer...

[பரத்_குமார்(bharathkumar)]

Does this  sequenceFile.AsPropertyObjectFile.IncChangeCount() work for step Name. Sequence editor doesn't reflect name. It does after editing once again 1 iteration lag(executes in the next edit click).

[WireWeaver]

I'm declining this idea due to lack of community support.