LabVIEW breaking my XControl without my help

[MarkBowles]

Hi, all,

I'm using LabVIEW 14 to build an XControl that contains a row of buttons, and a tab control (HMIChartTab).  The tab control has 6 pages, and each one of them contains subordinate XControl, that displays a chart (HMIChart). The buttons cause the tab control to change pages. The assembled package looks like this:

The functionality of all this is brand new, but working satisfactorily.

HMIChartTab is doing its own resizing, as its ultimate container will be a window.  When it gets a Pane Size event, it calculates the change in height and width, and adds this to the XControl:ContainerBounds for each of the 6 HMICharts (it also does the same thing for the tab control's Tab Control Pane Dimension). The code snippet for adjusting the sizes of the 6 HMICharts looks like this:

My problem is this: if while developing this functionality, I edit a small change in the appearance or the code of HMIChart, LabVIEW changes this code snippet in HMIChartTab to this:

But -- this code is broken, because the Bounds property is not writable. I can cope with this simply by changing the code back to the way I had it -- and everything's fine until the next time I change HMIChart.

What is happening here?  Why would LabVIEW change the properties in my code this way?

More generally, where can I read up on the dynamic relationship between call-er and call-ee libraries, like XControls? As I work on the two XControls, making small changes and improvements, they lock up in ways that I'm sure make sense, but not to me!  What exactly does "Apply Changes to Instances" do in the library shortcut menu -- I suspect this is where the code breakage is occurring.

Thanks,

-- Mark

[paul_cardinale · Accepted solution]

You shouldn't expect anyone to be able to do anything with those microscopic images.

If things change on the BD by themselves, the VI is probably corrupt.  Try a mass compile.

When you unlock a library for editing, all the instances of it in memory are disconnected (and hence their owning VIs are broken).

When you apply changes, those instances are reloaded with the new version of the XControl.