Why do LV classes often ask to save after everything else has asked

[Aristos Queue]

I was asked this question today in e-mail, and I figured others might like to know the answer.

Question: Why do LV classes often ask to save after everything else has asked to save? If I close a VI's panel, I'll frequently get a Save Changes dialog for the VI and its subVIs, and then a second dialog box for LabVIEW classes. Why can't you offer just one Save Changes dialog for everything that is leaving memory together?

Answer: When you close a VI, we know all the subVIs that will be unused as a result of closing that VI, so we can ask about them all at once. Classes, however, cannot leave memory until all data instances have left memory, and we can't know whether closing any given VI will actually close out the last instance of data. A VI might not have any reference to the class in its code, but it might still have an instance of the class stored in some variant somewhere. If all VIs were idle, we could search every terminal value, every control/indicator, check inside every variant, including the VI's tag table, and a couple other places where VIs store data, and determine how many instances of the class will leave with this set of VIs and see if that accounts for all the instances of the class remaining in memory. Then we would know that the class is leaving memory with the VIs and we could ask about the class in the same Save Changes dialog as the other VIs/libraries. But if *any* VI is still running, the number of instances can be constantly fluctuating. And while VIs are running, data can be hiding in impossible-to-search locations, such as a queue or notifier, and these extra spaces only get disposed when the VI goes idle. And a running VI might create new instances in locations that we already checked. So it is basically impossible to count instances while the VIs are running. Since we don't abort running VIs until after we have asked whether or not to save the changes, we can't yet know if the class will be leaving memory. I said that if all the VIs were idle, we could do the search for data. But that search is extremely slow, and since it doesn't work in the cases where any VI is running, we just don't bother doing it in any case. Thus, when you close a VI, the classes frequently end up getting their own Save Changes dialog box.

The only time when we can fold classes in with everything else and offer a single Save Changes dialog box is when you're closing the project. In that case, because every VI in the project will be closed down, we know that means all the data instances of the class will be disposed without having to account for them all.

[Omar Mussa]

QUOTE (Aristos Queue @ May 2 2008, 12:35 PM)

But if *any* VI is still running, the number of instances can be constantly fluctuating.

I think this problem would be fixed if LabVIEW would allow you to save a VI while it was not 'Idle'.

[Aristos Queue]

QUOTE (Omar Mussa @ May 2 2008, 03:29 PM)

I think this problem would be fixed if LabVIEW would allow you to save a VI while it was not 'Idle'.

How would that fix the problem? We're not talking about saving or not saving. We're talking about whether LV should *ask* you to save before the item leaves memory. This is a question of calculating whether the class will be leaving or not. For running VIs, we can calculate which ones will be leaving memory. For a class, we cannot make that calculation until after the VIs are halted *and* already removed from memory. So those VIs have to have already asked about their unsaved changes before we even know if the class will be going or staying.

[Omar Mussa]

QUOTE (Aristos Queue @ May 2 2008, 01:33 PM)

How would that fix the problem? We're not talking about saving or not saving. We're talking about whether LV should *ask* you to save before the item leaves memory. This is a question of calculating whether the class will be leaving or not. For running VIs, we can calculate which ones will be leaving memory. For a class, we cannot make that calculation until after the VIs are halted *and* already removed from memory. So those VIs have to have already asked about their unsaved changes before we even know if the class will be going or staying.

I was not reading it too carefully I guess. For the record, I've seen strange instances where LabVIEW does not 'save' my VIs even after I hit 'save all' or 'save this class' and I'm in too much of a hurry to figure out if this is the same case at the moment.

[Aristos Queue]

QUOTE (Omar Mussa @ May 2 2008, 03:42 PM)

I've seen strange instances where LabVIEW does not 'save' my VIs even after I hit 'save all' or 'save this class'

Hm... I don't have any CARs on anything like that at this time. If you can replicate it, please post it on ni.com so it gets CAR'd.