Workaround: Try putting a Begin Transaction call before the call to the method and an End Transaction call after the call to the method.
I call it a workaround, but it may not be a bug. Here's the fundamental problem that scripting faces: Should every method/property call return the VI to a runable state? Should every method/property re-evaluate the brokenness of the VI? If you're going to be calling a whole lot of scripting operations in a row, the answer is "no" because you don't want to waste the time redoing good/bad state tests, redoing type prop and redoing compile between every meth/prop call. But if you're only doing a couple of functions, that overhead is less significant and you may not want the bother of a Begin Transaction/End Transaction pair. And, since the transaction wrapper means that your edits are now undoable on the VI, that may also be undesirable.
Most scripting functions were created by a developer who needed them for a reason. It is only in recent years that we started saying, "Everything you can do from the editor should have a method/property to let you do it programmatically." As a result, a lot of functions were added by developers for a particular edit, and some of those edits couldn't waste time with the various "update the VI" procedures. So, to make them faster, they don't do it. Adding them now might make for a more consistent scripting API, but it might slow down those VIs beyond unusable, and LV has no way of knowing who is using that API, so we'd have to build a new meth/property to incorporate the "update the VI" functionality.
You can see why we resisted releasing scripting all those years. The amount to be cleaned up is huge.
