I like TiTou's new signature! :^)

[Ray.R]

---

@tst wrote:
And if you want to read an NI explanation, you can do it here (it starts at reply #14).

---

Thanks tst..

I see that I'm not alone..  Neither is TiTou...

Quote from LAVA:

"Power User Rant:  I am swearing like a trooper every time I have to use LabVIEW. Especially the PDA Module really drives me crazy.

I find it extremely hard for a power user to get used to the new "features". And after 3 month I have to admit, I really hate it.

...

BTW: where is the :throwLV8: smiley?"  

😄

(I'm gonna get in trouble for this -icon-)

LOL!!  After all, this IS the Breakpoint forum..  Wish Molly was around to see this... She'd get a kick out of it..

I hope people don't mind my copying their words over... I'll post a thread to this one..

I do like the comment / explanation in post # 15.  It describes what I have been trying to say. 

Quote:  "If you hit "close" there, the VI is closed and removed from memory. I experienced in LV 8.0.1 that - when working with a project - Strg+N opens a new VI, which is integrated in the project tree and you can not close that VI until the project is closed, but you get that defer decission button instead. If you have lots of such "test VIs" you don't really need in the project - those defered decissions can really drive you crazy. "

[shoneill]

Must resist the urge to post......

Aaargh, failed.

Personally, I welcome the change in syntax because I actually programmed for quite a while in LV before I realised the huge problems which can happen if small changes are closed without saving (yet residing in memory).  This can lead to major headaches especially when working without SCC.  I've never used SCC in my life, I don't even quite understand how it works.  I would however welcome the fourth button (or is it already a fifth?) to close the VI and DISCARD all changes, thus reverting to the "original" VI.  This is very valuable for failed experiments in Sub-VIs.

For idiots like me, I welcome the extra "Whoa, this might mean something" effect could reduce the number of silly mistakes.

On the other hand, why not allow each user to choose what's on his close dialog.  The others could be made visible via a button, but hiding the ones that annoy us might be interesting.  Well, if you're going to program M$ style, you might as well do it fully.. 🙂

Shane.

[Ben]

"On the other hand, why not allow each user to choose what's on his close dialog. "

I love the idea!

I want a "Finish Wiring What I Had in Mind" button.

Ben

[Ray.R]

Hey..

hitting the middle mouse button made my message dissappear..  oh well..  Maybe it was way too long..

Reader's Digest Version: 

"Shoneill,

Until I read the LAVA post (from tst) I didn't realize that there were many versions of a simple close.  It adapts based on the situation.  I just tried a scenario and obtained what I was used to.  I was simply unaware of the multiple scenario and the fact that the text in the dialog may change based on the situation.

It simply boils down to using it and getting used to the new features."

BEN!!!

Don't open another can of worms with a request for more features!!!  😉

😄

[Ray.R]

Now I know what David was referring to in posts 46 & 49 of this thread.

Please bear in mind that I have little experience with LV8.2. 

- need a caveman icon - 😉

[tst]

---

@Ben wrote:

"On the other hand, why not allow each user to choose what's on his close dialog. "

I love the idea!

---

I "hate" the idea. Customizing the environment means that you would have to it in every single computer where you will work (think back to the "how can I get the old style palettes" discussion) and would confuse other users. LV should be consistent. I'm also guessing it will be almost impossible to develop, but that's already the problem of LV R&D.

---

I want a "Finish Wiring What I Had in Mind" button.

---

I do like that one, though. I'm sure Greg is already hard at work on the MRK (mind reading toolkit).
The first sign of this can be seen in the auto tool which "knows" what you want to do.

[shoneill]

Or another crazy idea,

What about an "Application.VI close" event to allow us to intercept the "close VI" thingy and write our own dialogs.  Just think of all the horrible things we could do with our code.  We wouldn't need any more 8.20 bugs, we could introduce our own!

On a more sane note, perhaps a single dialog with all buttons present in all options visible but greyed out as neccessary would be an improvement.  At least the user is then presented with the same dialog in each situation.  Seeing the same dialog with some buttons greyed out would (for me) help explain what's going on.

Shane.

[tst]

---

@shoneill wrote:
Or another crazy idea,

What about an "Application.VI close" event to allow us to intercept the "close VI" thingy and write our own dialogs.  Just think of all the horrible things we could do with our code.  We wouldn't need any more 8.20 bugs, we could introduce our own!

---

That already existed even in your beloved 6.1! It's a VI event called "Panel Close", which also got a filter equivalent in 7.0.

---

On a more sane note, perhaps a single dialog with all buttons present in all options visible but greyed out as neccessary would be an improvement.  At least the user is then presented with the same dialog in each situation.  Seeing the same dialog with some buttons greyed out would (for me) help explain what's going on.

---

I just hope something like that wouldn't be too confusing when you have just a single VI you want to close. Sometimes it's good to have more than one dialog. I just hope NI does enough work and testing on this to find the useful version.

[shoneill]

Tst,

If you look extra-carefully, you'll see I was wondering about an "Application.VI close".  The "Application" i.e. the LV development environment makes all the difference.  I'm aware that individual VIs have the option to monitor panel closes, but this requires the VI to be running when it's closed, something which is hardly practicable.

If we had a global event (Thus the "Application") then we could have a single dialog-intercept VI running in the background which could then take over the close dialog option.  My beloved 6.1 only has "Application closing" and "timeout" available on a global level.

This is NOT in LV 6.1, and I don't think it's in the later versions either.

Why should a single dialog be confusing?  I have to admit, I haven't seen this list thing for VIs which may need to be saved which has been mentioned, so perhaps the single dialog would be larger and uglier than I think, but I would have thought a single dialog would be less confusing.....

Shane.

[altenbach]

Just a few pennies worth of my mind....

I have no problem with the "defer decision" option, it is clearer what it actually does than in the previous incarnation of the dialog.

Sometimes I wish however that there was an additional button in the cases where I definitely need to keep that changed VI in memory, but I am already sure that I dont want to save the changes when I am done with the toplevel . In these cases I would like to make that decision right now instead of much later when I close the toplevel VI. So how about an additional button like "treat VI as readonly" or similar.

In addition, I would like an additional layer of protection for any subVI located in vi.lib, the example database, or anywhere else in the National Instruments program folder. Anything that ships with LabVIEW. Sometimes I open a system VI for toubleshooting of my main VI, make some quick mods (such as placing a chart on the FP for troubleshooting, disconnecting the error out, or disconnecting an input control and force a value with a diagram constant, etc...). There should be an additional barrier if one would accidentally try to save over a system VI. (e.g. a "slip of the mouse" on the toplevel menu could turn a "save as.." into a "save all" with serious consequences, breaking the entire LabVIEW installation). System VIs need to be protected such that a serious warning appears whenever someone tries to change their file on disk.