Unable to display the front panel of the VI

[gsussman]

---

Yes, it should.  It's possible that you could get all the way back to the GSW and LabVIEW still hasn't thrown out your VI.  That would be a bug, but it's possible.  Perhaps, after you hit this problem, you could close everything, get to the GSW, then create a new VI, drop a property node to get all VIs in memory and see if the problem VI is listed.  It would at least be interesting to know.

---

I will test that the next time it happens, however if you close all LabVIEW projects back to the GSW, I know that LV does not release all file handles. Trying to delete or rename a directory that LV just had open results in a "Directory Locked" error message from windows explorer

[dhedges]

---

gsussman wrote:

---

...however if you close all LabVIEW projects back to the GSW, I know that LV does not release all file handles. Trying to delete or rename a directory that LV just had open results in a "Directory Locked" error message from windows explorer

---

Actually, that's a separate problem.  In fact, even while VIs are in memory, LabVIEW does not keep the file handle open.  But even so much as clicking on an LLB in a shell explorer or dialog can cause that "locked" error message.  Man, I hate that.

I just thought of something, though.  The "All VIs in Memory" property node does not extend to projects.  So if the VI you're interested in was open in a project, and you close the project, and you run the property node that's not in the project, then it won't even look for your VI.  I need to figure out a way to get all VIs in memory including other projects.

[JackDunaway]

It happened to me again for the first time on my new installation

This time, the perpetrating VI was flushed out by a build failure. I exited the top level VI but left the project open, after which point that VI would properly open! (Previously, it was required to do a full restart of LV, even exiting the GSW). With the VI currently working, I immediately initiated another build and a separate VI had the same problem. This time, a full restart (including exiting GSW) was necessary.

I will mass compile the appropriate folders, and report back on if I see the problem anymore.

By the way, R&D, any success on reproducing this issue CAR 234040?

[dhedges]

---

@JackDunaway wrote:

I will mass compile the appropriate folders, and report back on if I see the problem anymore.

By the way, R&D, any success on reproducing this issue CAR 234040?

---

Mass compiling should not help, because if the VI were not already saved in the correct version, it would not throw out its heaps and you would not have this problem.  But you might as well try it.

We have made no progress reproducing the issue.

[Sean-user]

I just wanted to mention that I am getting this problem too. It is quite obnoxious. I have had it throughout 8.6 and into 2009 SP1. I have not yet observed it in 2010, but that may be because I don't have a major project developed under it yet.

Just curious, I use Global Variables to pass some basic data around (simple low speed data like temperature). So far, I have only seen this issue on those projects. It may be merely coincidence. I reduced my use of globals in favor of queues for many things (except for some globals to carry control references) but just got a 'locked' VI.

One other observation: closing the project fixes the problem. You don't need to close LabView entirely. The getting started VI can remain open between closing the project and reopenning. It makes me think it is some aspect of the way I coded my VIs in the project. Perhaps that is why NI has had difficulty in replicating it.

[JackDunaway]

Since this thread began, I have been keeping tabs of every VI that reports this error. Certain VI's are prone to this error - of the 10 VI's or so that throw this error, many of them have repeated the error up to half a dozen times over the past 3 months.

All error-prone VI's have one thing in common: a FP array of typedef'd clusters that have a "large" (~a few dozen or a few hundred elements) amount of data "Set as Default". This could be a red herring, or could be a key to the underlying issue.

[RRRRSSSS]

I just had this issue happen in LV2011

pretty simple vi , open file, close file, find file positon, write text .

data written was just a few strings

when I closed labview it did indicate something errored and sent NI the info..

[Jeff-P]

Hi RRRRSSSS

can you give a bit more information about your vi and maybe post an image of your block diagram? It sounds like what you are trying to do is pretty standard, have you taken a look in the example finder (help->find examples) at the examples for writing to file?

[RRRRSSSS]

Can't open the front panel or block diagram..I deleted the Vi

I'm not having issues writing to file..

I'm just posting I had an issue with this type of error others have reported and was looking for a solution, does not look like NI has found or fixed the issue in labview 2011

[kevin.key]

I've been seeing this issue relatively frequently with LabView 2011 as well, and it's a good way to lose a lot of work. Luckily, SVN has saved me a few times so I didn't lose much, but still this issue should go away.