Unable to display the front panel of the VI

[kevin.key]

And even if it can't, you start with looking at the code that writes a vi to a file. And then where that code is called. The symptoms reported obviously give clues for what to analyze and debug.

But if it can happen when a person is using labview it can be reproduced. Setup some kind of automated test and find a way to reproduce it.

[Intaris]

It's not an idea that it can't be reproduced.  It's a result of trying.  Nobody is stating that it's impossible to reproduce, it's just proving very elusive.

If you can offer a project or VI which reproducibly shows the error, I'm sure NI will do their best to fix the problem.  I've also been on the wrong end of not being able to reproduce such problems. Personal proximity to a problem doesn't change the fact that without managing to observe a problem, you can't fix it.

[Intaris]

---

@kevin.key wrote:

And even if it can't, you start with looking at the code that writes a vi to a file. And then where that code is called. The symptoms reported obviously give clues for what to analyze and debug.

But if it can happen when a person is using labview it can be reproduced. Setup some kind of automated test and find a way to reproduce it.

---

This sounds simple but is unrealistic.  Code complexity scales exponentially with code length.  Once you go beyond a function or two the effort required for something like you say is simply not feasible without being able to at least localise a little where the problem is coming from.

[kevin.key]

So, once you hit three functions the problem could be anywhere? Are there no methods available for isolating problems? How could anyone expect NI to create a test that reproduces the problem or already have tests in place that should immediately eliminate certain possibilities?

I would imagine the number of functions that actually write a vi to a file to be a pretty small set of functions. Either those functions contain the problem or those functions are called with some kind of corrupted input.

I'm not saying this problem would take 10 minutes to fix, but I believe it can be fixed. Maybe I'm alone in thinking that.

[Intaris]

Of course you're not alone.  But you have already limited the scope of the problem to the functions which write files to disk.  Who says the problem occurs there?  There could be a multitude of sources for this problem (there were documented cases of Quick drop corrupting object data of a VI).

How do you know your localisation of the problem to the file writing functions is correct?  You correctly say that these functions could be called with corrupt data.  Correct, but perhaps THAT function also receives corrupt data.  After five or six steps we get to Kevin Bacon the kind of complexity I was mentioning earlier.

I have criticised LabVIEW's ability to "self-heal" or at least correctly identify when such a corruption takes place so that the damage doesn't spread.  I find the built-in object checks to be lacking a little bit.  I would love an on-the-fly "Insane Object" detection, but the complexity and possible performance hit int he IDE involved in such an undertaking is clear to me.

Shane.

[JÞB]

---

@kevin.key wrote:

So, once you hit three functions the problem could be anywhere? Are there no methods available for isolating problems? How could anyone expect NI to create a test that reproduces the problem or already have tests in place that should immediately eliminate certain possibilities?

I would imagine the number of functions that actually write a vi to a file to be a pretty small set of functions. Either those functions contain the problem or those functions are called with some kind of corrupted input.

I'm not saying this problem would take 10 minutes to fix, but I believe it can be fixed. Maybe I'm alone in thinking that.

---

Please provide steps to reproduce and an example where you observe the suspect behavior.

Spoiler

A bit harder than ranting that "It isn't fixed!" but probably more productive.

Sure, bugs happen and often workarounds can be found.  But, without more information the task becomes too difficult for even my (well calibrated) Magic 8-Ball (tm) .

[billko]

---

@kevin.key wrote:

I challenge the idea that it can't be reproduced.

---

Quantum physics says you can be at your desk and simultaneously be on a beach in Miami, but it's probably not going to happen within the lifetime of the universe.  Same idea here, but not quite so improbable.  😉

[Intaris]

---

@billko wrote:

Quantum physics says you can be at your desk and simultaneously be on a beach in Miami, but it's probably not going to happen within the lifetime of the universe.  Same idea here, but not quite so improbable.  😉

---

Any more questions....

[kevin.key]

I don't think this is an issue where the users will be able to give a set of steps to reproduce the issue, because it is so infrequent and you don't find out about the problem when it occurs but only once you've closed and re-opened the vi.

My biggest fault is I just believe too much. I believe NI can fix this issue.

[JÞB]

---

@kevin.key wrote:

I don't think this is an issue where the users will be able to give a set of steps to reproduce the issue, because it is so infrequent and you don't find out about the problem when it occurs but only once you've closed and re-opened the vi.

My biggest fault is I just believe too much. I believe NI can fix this issue.

---

I believe they already have.  I have never seen it happen in newer releases of LabVIEW.  I could never get it to reproduce reliably in 2011 either.  My magic 8-Ball thinks that may be why Jack started this thread in the first place.