This VI does not want to unlock!

[Giseli Ramos]

Hello folks,

I'm quite anxious here, because a strange thing happened here. I was working on my VI and closed, so appeared a message asking if I want to save. I clicked on OK and a message with the button "revert appeared". So I cancelled the Save, to close the VI.

When I reopened this VI, it is blocked! I cannot see anymore my block diagram! The funny thing is that I did not clicked on VI Properties -> Protection -> Locked (no password). When I try to unblock here, the dialog is disabled, so I can't click on Unblocked!

What I do? And any ideas of the cause of this "mysterious" blocking?

[crelf]

QUOTE (Giseli Ramos @ Apr 8 2008, 09:48 AM)

What I do?

Show us your code.

[Giseli Ramos]

QUOTE (crelf @ Apr 8 2008, 02:19 PM)

Show us your code.

I would like to show the code, but what to do if only the front panel appears? Well, anyway, I'm sending below the file VI. Don't mind if LabVIEW asks for subVIs (I would like to send the subvis, but I cannot and is not important for now).

I also tried to unblock programatically, using the method Lock State: Set, setting to Unblocked, but don't works too

[PJM_labview]

I am sorry to be the bearer of bad news, but the VI that you just posted do not have a block diagram. There is absolutly nothing that can be done. You have to either recreate it or use a backup copy (hopefully you are using a source code control)...

PJM

[Giseli Ramos]

I was afraid of this... but hopefully I have a backup copy here (it is a older version, but to recreate the new things....). I'm recreating and for now, I will backup every day.

Well, I really like to know where the block diagram has gone, but okay, let's go to recreate it

Many thanks for the feedback!

[crelf]

QUOTE (Giseli Ramos @ Apr 8 2008, 03:15 PM)

I was afraid of this... but hopefully I have a backup copy here (it is a older version, but to recreate the new things....). I'm recreating and for now, I will backup every day.

Loosing stuff is a great motivator

It *might* be some simple file corruption that NI could help you with - if you're really in a difficult place and can't recreate it without pain, contact them directly.

[Aristos Queue]

I have seen this situation once before. I have no idea how exactly to recreate it, but it goes something like this:

1. Assume you have the following VI hierarchy:
   Alpha calls subVI Beta calls subVI Gamma.
   
2. Open VI Alpha. This of course loads Beta and Gamma into memory. But LabVIEW doesn't load the block diagrams for these VIs because it doesn't need them right now. So those are still on disk.
   
3. Now, while you have Alpha open, copy another Beta.vi over the file on disk.
   
4. Now open Gamma and change its connector pane. Because Beta calls Gamma, changing the connector pane of Gamma will force a change on Beta. So LabVIEW will now try to load Beta's block diagram. But wait! The VI on disk is not the same as the VI in memory. We *can't* load the block diagram. At this point, LV throws up a dialog that asks if you want to revert the Beta in memory to match what is on disk. If you choose "no", then you keep the version in memory -- the one that has no block diagram. Now you save Beta. Congratulations, you just saved your VI without a block diagram.
   

I have no idea if you actually did these things, but you may have done something similar. The big no-no is changing a the file of a VI on disk while that VI is in memory. That's the only time I've heard of this situation coming up.

[crelf]

QUOTE (Aristos Queue @ Apr 8 2008, 05:07 PM)

I have no idea how exactly to recreate it, but it goes something like this:

Yeah - I can see how that'd occur. Answer = Don't manually screw around with files that are open (and that means in any application - not just LabVIEW).

[Justin Goeres]

QUOTE (Giseli Ramos @ Apr 8 2008, 11:15 AM)

I will backup every day.

May I suggest a http://tortoisesvn.tigris.org/' rel='nofollow' target="_blank">version control system?

[crelf]

QUOTE (Justin Goeres @ Apr 8 2008, 05:49 PM)

May I suggest a http://tortoisesvn.tigris.org/' rel='nofollow' target="_blank">version control system?

suggest insist on

[Mellroth]

QUOTE (Aristos Queue @ Apr 8 2008, 11:07 PM)

...The big no-no is changing a the file of a VI on disk while that VI is in memory...

QUOTE (Justin Goeres @ Apr 8 2008, 11:49 PM)

May I suggest a

version control system

?

We actually filed a bug report about this a while back (2003?), but found out that it was the way some users used ClearCase that caused the removal of the block diagrams (on VIs as well as controls/typedefs).

In our case some users had a lot of code opened in LabVIEW, then when a VI was modified they tried to save the VI, but to do so they had to first CheckOut the VI in ClearCase.

The CheckOut could then in some cases (e.g. if the cs-file was changed after the VI was loaded, so that a later version was selected), cause the change on disk AQ is mentioning.

My point is that even with a Version Control system, you have to be careful. You could still lose a BlockDiagram and be forced to do the work all over again.

/J

[Giseli Ramos]

I agree with you, about the control version. I will implement it NOW! I was thinking about it, but, at the beginning, the project was small, and after, growed a few... I don't have excuses to don't implement it now.

Aristos, well, I think that your explanations about the conditions to lose a block diagram makes sense. Because I was with some VIs opened, and appeared that message to revert. Duh, I was dumb and clicked on "no".

I have a backup copy, so, no great pain to recreate it, hopefully. But good to know that NI can help if the things really goes hard!

It was important to learn that have much ways to lose VIs....

Many thanks!

PS: Sorry for my english...

[jpdrolet]

I think a solution to avoid this would be that LabVIEW keeps VI files opened (deny write) while they are in memory. That effectively locks the file in the filesystem. Many applications do that.

Are there better reasons for not doing so in LabVIEW?

[crelf]

QUOTE (JFM @ Apr 9 2008, 01:51 AM)

In our case some users had a lot of code opened in LabVIEW, then when a VI was modified they tried to save the VI, but to do so they had to first CheckOut the VI in ClearCase.

I know we've hijacked the thread, but this isn't an issue that we should rely on LabVIEW to handle for us - it should be fixed in proceedure we use day-to-day. You shouldn't try to edit a file that you don't have permission to - LabVIEW has the setting to treat read-only files as locked, and it's a really important setting to use if you're using SCC (you should be able to have your SCC system have all locked files read-only). So, yes, if you're not following standard operating proceedures, you can get into the situation of loosing block diagrams - the answer is to follow standard operating proceedures.

Sorry - I know that wasn't my most lucid post, but I haven't had my morning beverage yet

QUOTE (jpdrolet @ Apr 9 2008, 09:20 AM)

I think a solution to avoid this would be that LabVIEW keeps VI files opened (deny write) while they are in memory.

Great idea!

[orko]

QUOTE (Aristos Queue @ Apr 8 2008, 02:07 PM)

4. Now open Gamma and change its connector pane. Because Beta calls Gamma, changing the connector pane of Gamma will force a change on Beta. So LabVIEW will now try to load Beta's block diagram. But wait! The VI on disk is not the same as the VI in memory. We *can't* load the block diagram. At this point, LV throws up a dialog that asks if you want to revert the Beta in memory to match what is on disk. If you choose "no", then you keep the version in memory -- the one that has no block diagram. Now you save Beta. Congratulations, you just saved your VI without a block diagram.

Personally, I think the above behavior is evil. Sorry, but I don't care if it makes sense that it happens procedurally... can someone tell me why in Pete's sake I would ever want to select "no" in this situation...? Am I missing something or is this situation programatically detectable/avoidable? If so, why can't we just get rid of the evil dialog that corrupts our VI?

Like Chris, I am still pre-caf at this point... so perhaps there is something I'm not thinking of.

[Aristos Queue]

QUOTE (jpdrolet @ Apr 9 2008, 08:20 AM)

I think a solution to avoid this would be that LabVIEW keeps VI files opened (deny write) while they are in memory. That effectively locks the file in the filesystem. Many applications do that.

Are there better reasons for not doing so in LabVIEW?

Yes. But I can't remember what they are. :-) This was very seriously discussed. If you use LV 8.5, you'll notice that there's a lot more file monitoring going on when you have a project open -- we know if you change a VI listed in the project even if that VI isn't itself open. We took that route instead of locking, but I don't recall why.

[Mellroth]

QUOTE (crelf @ Apr 9 2008, 03:38 PM)

So, yes, if you're not following standard operating proceedures, you can get into the situation of loosing block diagrams - the answer is to follow standard operating proceedures.

Sorry - I know that wasn't my most lucid post, but I haven't had my morning beverage yet

Nothing like a hijacked thread before first cup of coffee...

I agree with you, in the end it is up to the user to understand how to use the tools.

QUOTE (orko @ Apr 9 2008, 04:19 PM)

Personally, I think the above behavior is

evil

. Sorry, but I don't care if it makes sense that it happens procedurally... can someone tell me why in Pete's sake I would

ever

want to select "no" in this situation...?

What really bugs me is that there is no information that you might loose your block diagram if you select no.

The choice of Yes or No is like to ask if you want to keep your orange or get an apple, but there is no information telling you that if you select the orange the only thing you'll get left is the peel.

/J

[Rolf Kalbermatter]

QUOTE (Giseli Ramos @ Apr 9 2008, 06:52 AM)

I agree with you, about the control version. I will implement it NOW! I was thinking about it, but, at the beginning, the project was small, and after, growed a few... I don't have excuses to don't implement it now.

Aristos, well, I think that your explanations about the conditions to lose a block diagram makes sense. Because I was with some VIs opened, and appeared that message to revert. Duh, I was dumb and clicked on "no".

I have a backup copy, so, no great pain to recreate it, hopefully. But good to know that NI can help if the things really goes hard!

Well NI could theoreticaly help, but for various reasons will only do so in very rare circumstances nowadays, IF and ONLY IF the VI is only corrupted. If the VI is saved without diagram resource however, they can't do anything about that anymore. Something that has been gone can't be recreated.

It's like compiling a program and then throwing away your source code. With the difference that there are readily available tools to disassemble a compiled program and at least see the assembly code, while for LabVIEW disassembly is basically a no no.

The only people that might still be able to do something here are those guys like from Seagate where you send in your harddrive to recover lost data from. Chances would be dim though, since the rewriting of the file has a high chance to destroy the actual data of the previous VI version on harddisk.

Rolf Kalbermatter