LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Losing changes in LabVIEW 8--bug report

Don't know if this has been reported yet or not but it was driving me crazy making my coding changes evaporate until I started realizing it wasn't me.

To reproduce:

  • Create a blank project and a new VI
  • Add FP.Open VI Property node with a False Constant
  • Run the VI
  • All changes will be LOST

After nearly going mad and tracking down the root cause, I find the newly added note:  "National Instruments recommends using the Front Panel:Open [or Close] method instead of this property."

So you can try that too if you want, which has the same results:
  • Create a blank project and a new VI
  • Add FP.Close Method
  • Run the VI
  • All changes will be LOST
*POOF*  If the VI was an Untitled new VI that hadn't been saved, it will just vanish from the project list.

0 Kudos
Message 1 of 7
(2,645 Views)
I don't think this is a bug. I think it's working the way it's suppose to.

What you are doing is closing the front panel of an unsaved VI which removes it from memory. Closing a VI using a Property or Invoke Node does not bring up the automatic Save dialog like you would get if you just closed it using the "X" in the upper right of the window. This is how we close instances of VI templates opened to avoid the Save dialog.

If I first save the VI, everything in the VI gets saved and nothing is lost.

Ed


Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
Message 2 of 7
(2,638 Views)
I already save my files religiously--I hope you're not inferring that the solution is just to save every file every time right before you run it, in hopes of averting disaster if the front panel gets closed via the BD.  Your statement would be a lot easier to swallow if if I hadn't lost my work multiple times due to this new improvement (should I call it a "feature"?)

There are two reasons I'll stick with calling this a bug.

1) Behavior is different from LV7.1, which would always always always ask you to save if there were changes.  Once again the maxim holds true, if it aint broke, don't fix it.

2) I have yet to find a way to close the FP for my VI's programmatically without potentially losing changes during development.  Point #1 might be negligable if an appropriate method had been (or is) designed to mitigate this effect.  Even an "Auto-save all on run" option would suffice, but my point is, this is a feature that got changed without properly vetting the idea before it was implemented.
0 Kudos
Message 3 of 7
(2,610 Views)
You're correct. I forgot one step to make the, "This is how we close instances of VI templates opened to avoid the Save dialog." statement true. The VI must open a reference to itself and pass that to the Node to avoid the Save dialog. 7.1 does indeed pop up the Save dialog if you just have the Node set to close.

So now the question is, did NI intentionally change this or not. I've found other changes that I thought were bugs that they intentionally changed. See this thread for one of them.

I'll see if I can get the attention of an AE to look into this.

BTW, I do hit (Ctrl+S) before I run anything because I've had LabVIEW dissapear when I hit Run. Smiley Sad

Ed

Message Edited by Ed Dickens on 05-03-2006 03:56 PM



Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
0 Kudos
Message 4 of 7
(2,601 Views)

The sticky point here is how the VI reference gets opened.  In the case of explicitly opening a VI reference, the behavior properly obeys the 0x04 flag.  Explicitly opening a reference to a VI with the 0x04 flag should address point (2) above.

The discrepency (and what I still need to look into) is the behavior change in this regard with the implicit VI self-reference.  I'm not sure if this was intentional or not, or if it was intentional, why the change was made.

I've attached a VI saved in 7.1.1 that you can use to play with this, and you can see the only mode that differs in behavior between 7.1 and 8.0 is the implicit one.  Just open the VI, make a modification to it (one that doesn't make the VI broken), pick a mode, and run it.

Message 5 of 7
(2,566 Views)
Thanks for looking into this Jeff.

Let us know what you find out.

Ed


Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
0 Kudos
Message 6 of 7
(2,554 Views)

Upon looking into this, it turns out that the fact that you got prompted to save with an implicit self-reference in 7.1 was an unintended consequence of a less robust method of closing VIs.

Generally, the philosophy is to not prompt the user in situations where we normally would, if the event that would cause the prompt is the result of a programmatic operation.  If you want to be prompted to save unsaved changes to a VI when closing it using VI server, you must explicitly open the reference with the 0x04 flag.  This is the way it was supposed to work in 7.1, and it is the way it correctly works now.

Message 7 of 7
(2,539 Views)