Labview 8.5 prompts me when I change a subvi

[wb2nvy]

With v8.2.1 and earlier I could work on a main vi and make changes to its subvis & save them & continue on with no glitches. NOW with v8.5, when I change a subvi and save it I later get the attached message, and the only options are REVERT and CANCEL, and I don't want to do either one. Usually when I make a selection, Labview starts to shut down and I get the 'send a message to Microsoft?' prompt, which I don't want to do because I'm usually not online, and then Labview crashes. I'm not positive of the exact sequence of events but it seems I can't modify subvis like I used to without bad things happening. Anybody else have this problem, or is there a way to avoid this message?

[Stephanie B]

Hi,

I created a very simple VI in 8.5, made it into a subVI, created a caller, and tried to reproduce this error to no avail. Could you possibly post your code or a smaller piece that reproduces this error? Were these VIs you upgraded to 8.5 or created in 8.5? Any special VIs/modules/toolkits you are using? Thanks!

Stephanie

[wb2nvy]

This continues to be very frustrating. These vi's have all been updated to 8.5. To describe the problem more clearly, I have a calling vi and a subvi. Within the calling vi block diagram, I double click on the subvi, makes changes, save the subvi with the same name, exit this subvi, then if I doubleclick that subvi, the "changed" message pops up. I thought maybe the unchanged vi was still in the block diagram, so I "replaced" the subvi with the same (changed & saved) vi from my directory, double clicked on it and got the "changed" message again. I clicked on the CANCEL button.  I then executed just the subvi, stopped it, and again the "changed" message popped up. The options are REVERT and CANCEL and I don't want to do either one! I want to use THIS MODIFIED subvi! If I select REVERT I get the Revert message, which I dont' want to do. And after enough putzing around with these messages, I get the message about Labview having to shut down.

If I click REVERT and look at the block diagram, it does contain the recent changes I just made... it DOESN'T revert back to the original subvi.

Can anyone explain to me what conditions must exist that will CAUSE these messages to pop up?

[MeghanK]

I am also unable to reproduce your issue in LabVIEW 8.5.  If you create a new, simple VI with a subVI in it and make the same changes to the subVI, do you still receive these error messages, or does this only occur with the original VI you are working on?  If you could post a simplified code that produces the same issue, we would have a better ability to troubleshoot this error.  Thanks.

Meghan M.

[wb2nvy]

This problem NEVER happens with new code generated with 8.5; only with some old code generated with 8.2 or 8.21 and subsequently updated to 8.5 when using 8.5. My calling vi is kinda large. I can't make this happen repeatably.

Let's approach this problem with logic:  'what conditions must be met to make these messages appear?' Stated another way, When is it appropriate for these messages to appear?', or another way, What can I do to make these message appear IF I WANTED TO? Answering one of these questions might give me a clue about what I'm doing wrong.

Let's look at the first message "The VI socketcheck.vi has changed on disk since last saved or loaded by Labview. "(I KNOW THIS BECAUSE I JUST CHANGED IT AND SAVED IT.) "If you load its block diagram, it will probably be inconsistent with the parts of the VI already in memory, resulting in a corrupt VI." IT WILL NOT BE INCONSISTENT BECAUSE I MADE CHANGES WHICH ARE CONSISTENT WITH THE VI ALREADY IN MEMORY. 

Let's assume I DO WANT to use this "mysteriously" changed vi from the disk. The prompts don't allow me the option to use it!

 It seems like Labview thinks someone else made the change and I didn't know it, so it's warning me and it won't let me use the changed vi. Although when I click on REVERT and then click on DISCARD, one would think all my changes would be gone and I'd be working with the unchanged vi, but such is not the case. The vi in place IS the changed vi.

[AristosQueue (NI)]

> Stated another way, When is it appropriate for these messages to appear?

When LabVIEW loads a VI into memory, it doesn't load the entire VI. It only loads the parts it needs and assumes that it can go back to the disk to get the other parts if they're needed. One of those parts is the front panel.  The dialog in question appears when LV goes back to disk to load one of those parts and discovers that someone *other than LabVIEW* has changed the file on disk. Perhaps source code control is being used to update files on disk. Or maybe some misbehaving virus checker is updating the timestamps on the file. Whatever the case, LV is looking at the timestamp of the file that it loaded into memory and the timestamp of the VI on disk and saying, "Hey, these don't match."

> Let's assume I DO WANT to use this "mysteriously" changed vi
> from the disk. The prompts don't allow me the option to use it!

The "Revert" option means "throw out what I have in memory and use what is on the disk in its entirety." So that is the option that let's you use what's on disk. The "Cancel" option means "keep what I have in memory -- since the VI in memory doesn't have a front panel, I'll just cancel the request to open the front panel."

> one would think all my changes would be gone and I'd be working with the unchanged
> vi, but such is not the case. The vi in place IS the changed vi.

This would be true unless the only change that the other program made to your VI was to update the "last changed" timestamp (as would happen if someone had used the "touch" command or had read the file and then written back exactly the same file). In that case, LV would think the file had changed, and when it reverted, the VI would be exactly the VI you're expecting.

You state that all the edits being made to this file are being done by LabVIEW and there isn't any other program involved. I can only think of one way to make this situation happen in that case. You open a VI, which loads its subVIs. Those subVIs only load their code portions, not their panels. Then you create a VI that reads one of those subVIs from disk as a binary string and then writes the subVI back to disk as a binary string. LabVIEW's own load/save system didn't get involved, and all it sees is a timestamp that is different from the subVI in memory. I realize that you probably aren't doing this, but there's nothing else I can think of that only involves LabVIEW that would trigger this dialog.

Message Edited by Aristos Queue on 10-25-2007 02:35 PM

[AristosQueue (NI)]

> Within the calling vi block diagram, I double click on the subvi, makes
> changes, save the subvi with the same name, exit this subvi, then
> if I doubleclick that subvi, the "changed" message pops up.

Oh, wait ... I suspect there's a key phrase here that NI folks over looked. I marked it in bold face.

Let me clarify...  you open your caller VI. You open a subVI and edit it. Then you close the front panel and save the changes. The subVI, at this point, is still in memory.

You then double click it. ... Are you double clicking the subVI call on the caller VI? Or are you actually double clicking the VI out in the file system? I'm going to bet that you're doing the latter and the NI folks have been doing the former.

[wb2nvy]

Thank you. That explains a lot. I think I understand now that I'm not doing something wrong. However you speak of a vi not having a front panel, or loading the block diagram, then going back to get the front panel. In my case, all my vis and subvis have front panels, which are always loaded first, which is a bit of a pain, because I always want to work with the block diagram. It would be nice if, whenever I load a vi it would load just the block diagram, then load the panel IF I need it.

I think you've addressed my problem. I'll have to see what weird things are going on with my computer. Thanks again.

Keith

[wb2nvy]

Good catch. I'm double clicking the subvi icon in my calling vi, and that's what causes the prompts.

[AristosQueue (NI)]

There's a difference between having a front panel and having a front panel in memory.

When you open a caller VI, the caller VI loads its code segment, its front panel, and the code segments of all subVIs. Thus the subVI is in memory but its panel and diagram are not.
When you double click on a subVI node, LV goes to disk and gets the panel and diagram -- and that's when it is discovering that the file timestamp has changed since the time that the code segment was loaded.

I thought you might be clicking out in the file system. If you're clicking on the node in the diagram then we're back to square one in diagnosing this.

Tangent: You mentioned wanting the diagram instead of the front panel... there's a shortcut that you might not know about. If you ctrl+double click on a subVI node, the diagram will open in front of the panel instead of the panel in front of the diagram. Not quite the same as only opening the diagram, but it might speed your development.

Sorry -- I gotta run and may not see this thread again for a while... I'm not an AE, just a developer who happened to see this thread and knew a bit about that dialog. I do hope one of us NI folks is able to come up with a solution for you.