LabVIEW scripting replacing sliders

[Intaris]

I ran into some interesting (i.e. frustrating) behaviour today:

I have written code to parse our old software and replace the old controls with a new version according to out new UI style.  This is obviously an edit-time operation.  This has been working well (utilising the scripting method "Replace".  I can even create sliders with different numbers of sliders (using the SLider.Add and Slider.Remove methods).

Problems seem to occur when replacing a slider with more than one slider with a slider with only one slider.  If the control exists in a vacuum (no property nodes, no linked references) things go fine but if I try to replace it in working code LabVIEW throws a fit and disappears on me.  No goodbyes no parting kiss, just vanishhing.

Of course the workaround is to have some sliders with different numbers of indices ready for replacing with but I was just wondering if this is known or whether this has been fixed in later LV versions?

Shane

PS when restarting LV it mentions that LV encountered an fpsane error.  I'll post the line number next time I get the error.

PPS It seems as though the reference returned by the "Replace" function is actually invalid in this case.  The exact same code works fine for other control configurations (same number of sliders  or other controls, Digital, String etc.)

[DFGray]

I have not seen this error in my scripting adventures. My quick and dirty check below could not reproduce it (LabVIEW 2013SP1f5) Could you post some example code so I can file a CAR? There are several different ways you could be doing this. Thanks!

A possible workaround is what we used to do before we had Replace - drop the new control, position the FP control and BD terminal, connect terminal to old terminal, delete the old control. This may end up crashing, as well, but may be worth a shot to get you moving.

[Intaris]

Hmm, not really an option because we need to retain tab order as well as many linked refnums, locals (I know, I know) and so on.  Creating a new control won't work.

I have thought of actually modifying the "new" control as a new "control" VI, then saving it as a temporary file before replacing it with this newly adapted file.  This should work but is a bit of work to implement.  So I would have a kind of pre-replace adaptation of the control.  Of course this only works when the control I wish to replace with isn't either a typedef or a strict typedef but that's a different story.

I'll have a look to see if I can whip up an example when I have time.