I like TiTou's new signature! :^)

[Jaegen]

To be honest, I don't understand all the flap about the "Defer Decision" dialog.    Here are my $0.02:

For one, the behaviour has not changed at all from LV 7 - "Don't Save" (I think that's what it said) is now "Defer Decision", which, though an unusual phrase for a software program, is more accurate than "Don't Save".  If you close a VIs front panel, but a caller of the VI is still open, the VI must stay in memory.

For two, I use this all the time - here's an example: I recently moved some classes from openGOOP to dqGOOP.  I did this by creating a new folder with the dqGOOP class in it - a peer of the old openGOOP class.  If I've done everything correctly I should be able to switch between the two classes simply be renaming the two folders - so I do this, then open my project.  In order to check things, I open a few VIs.  Most likely, due to relinking/recompiling, some of these VIs are going to show up as modified.  If I discover something's wrong, I sure don't want to save these VIs - I want to "Defer the Decision" until I close all the VIs (or quit LabVIEW altogether), when I'll select "Don't Save - All", so I can go correct the issue in the class without affecting my project until it's really necessary.

Here's another example:  I want to test some concept which involves creating and calling a subVI, but it's only going to take me 2 seconds and I don't want to bother finding somewhere to save the VIs - so I build the 2 VIs (caller and callee), and to get the subVI out of the way I close it's front panel - I'll select "Defer Decision" then too.

And another: I open up my project on a PC in the lab.  As I'm looking at VIs on this new PC, I notice some asterixes (sp?) in the title bars.  It seems I have a different version of NI-DAQ, or some other toolkit, installed on this PC, which is causing VIs to appear modified (the polymorphic VI one gets me all the time).  If I save these VIs, then they'll show up as modified when I go back to my desk.  If I'm using SCC, this gets really complicated, and I might end up having to check out/check in for no reason other than LabVIEW decided a VI has changed, when really it hasn't.  In fact, if I select "Save", and I don't have the VI checked out, it will tell me I can't save because it's read-only.

And yet another:  I want to try out a simple change to a subVI, which can't have its front panel open before running the top-level VI (it's modal, or it's being used in a sub-panel, or some other reason I can't think of).  So I make the change, close the FP ("Defer Decision"), and run the program.  If it works, I might go back and save the VI - if it doesn't, I might go back and make more changes.  Again, this procedure is actually a necessity if you're using SCC and don't want to bother checking out the file (it's a simple change remember).

I realize all of these examples aren't necessarily "every day" operations, but having to do even one of them requires there to be a "Defer Decision" option - what would you do if it wasn't there, and you had to either save the VI or leave it open?

That's probably more than $0.02,

Jaegen

[Ray.R]

Thanks Jaegen for the explanation.

Yes, I understand that.  I was venting earlier.  Hummm... How to describing this without openiong another can of worms....

.... hummmm.....

.....

I'll simply say this:  Whether in the older versions or in the new..  Keeping unsaved changes in memory is a dangerous thing.  There might be 10 sub-vi's opened (or more), you get a phone call from another customer, you had some unsaved changes in some vi's, and you do not want them... but the other customer is on the phone, so you want to close this project (or all opened files in LV7.1 & earlier), and then OOpps... did I just save some unwanted changes??  Too late.. You have to deal with the customer on the phone..

Maybe the issue is having to deal wit

I don't know... maybe it's just me.  I like to keep things simple.  You don't save a file & close it.  You should have to worry about what's in memory.  Maybe it's old age..  🙂  or insanity 😮  or both 😄 😄 (ok.. where the crazy icon?) 

Or maybe I'm completely missing the point... 

Here is my personal scenario.  I want to close a vi or sub-vi.  I do not want any residue in memory.  Do I have to close LV completely to avoid a future mess? All I want to do is close the bloody vi.. that's all.. No defering decisions... heck isn't that procrastination? 😄 😛  Closed vi..  so simple...

I think the effects of cafeine ran out..  Hopefully the developers at NI will at least get a laugh from this.

- time for bed -

JLV

[Jaegen]

---

@tst wrote:

...

I think that this should all be a single (resizable) dialog ...

---

Amen to that - few things drive me more crazy than a teensy-weensy little non-resizable dialog box full of information.  Microsoft is great at this:


~80 fonts in one tiny little box


Look at the size of the scroll bar slider!!!

This is one of the reasons I love Gnome - just about everything's resizeable.

Jaegen

Message Edited by Jaegen on 09-20-2006 08:57 PM

[Jaegen]

---

@JoeLabView wrote:

... (ok.. where the crazy icon?) ...

---

Here you go:
 

and at the risk of exposing my very limited knowledge of French:  "Chacun à son goût!"

À demain,

Jaegen
 

Message Edited by Jaegen on 09-20-2006 09:04 PM

[Ray.R]

LOL!!

I like it!!!

[RayFarmer]

'Defer Decision' / 'Dont Save' they are doing the same thing, ie You are not saving any changes.

So lets get back too some sensible labels on button. If you have two buttons one of which say 'Save' whats the other going to say if you dont want to save any changes, doh! "Defer Decision"

Ray.

[Ray.R]

Thanks Ray,

That is exactly what I've been trying to say in too many words.

Do you want to save?  Yes or No?

Or more exactly...

You are closing..  Do you really want to close?  If so, do you want to save?  Yes or No?

Thus: Save, Close, Cancel.

Message Edited by JoeLabView on 09-21-2006 06:58 AM

[tst]

I see this is really troubling people.

---

@JoeLabView wrote:

Do you want to save?  Yes or No?

Or more exactly...

You are closing..  Do you really want to close?  If so, do you want to save?  Yes or No?

Thus: Save, Close, Cancel.

---

Unfortunately, it's not as simple as that and it never was. If you made changes to a VI YOU will have to decide whether to keep those changes. NI could set it up so that closing the FP does not trigger the dialog if the VI remains in memory, but then you would still need to decide later.

As Jaegen mentioned there are reasons for changing a bunch of VIs and waiting before saving. For example, I have a serial device which I talk to through a TCP/IP converter, so I use the TCP VIs (I would rather avoid using VISA for this). Now, I want to temporarily change this to work with a serial connection directly, so I will have to replace all the TCP functions with VISA functions. Even assuming this is done a single VI, then after I make the change, I want to close the VI, I do want to keep the changes (so that I can connect the device to the serial port), but I don't want to save it, because it will overwrite the existing file, which I want to keep, So I need the "Defer Decision\Close\Don't Save" option. From those three, "Defer Decision" describes the situation most accurately, even if it's hard to understand.

Perhaps what NI needs to do is add a "Revert VI and close" button to this dialog? Personally I think that it would make the dialog more complicated and would rarely be useful. Other people might think differently, though. In any case, changes caused by recompiling and relinking will still cause LV to ask you if you want to save the VI when you do finally remove it from memory, so in that case such a button would have no real meaning.

This dialog definitely needs work. I think we all agree on that. I would expect that LV R&D, who definitely spent more time and thought on this than we did, would have realized the problems with this dialog (or maybe the beta users), but maybe they just haven't gotten around to dealing with it?

In any case, I don't find "Defer Decision" to be harder to understand than "Don't Save". I think that if the entire dialog was modified it could be made to convey more clearly which choices you have to make at each point and (more importantly) give you better tools for making those decisions.

[tst]

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

[Ray.R]

LOL @ tst,  (good post)

I'm not disagreeing with you or Jaegen.  Unfortunately, the way I described my thoughts in my post probably give you that impression.

I understand how it works.  I think in my case, the fact that I mostly still use LV7.0 & LV7.1 with customers, my sub-conscious mind knows how to react to the old "close vi"... Now with 8.x, something new catches my attention.. And my attention is drawn to something with is foreign.. a "Defer Decision".  Then my reaction is..  "hey..  I don't want to save these changes!!! Oh my God!!! What's going on!!!!!"    Even though I obviously know what's going on in the previous version, this time, it's more "in my face"..  Hey... there are some unsaved changes still in memory.. be careful..!! 

It's probably like the 1000's of other changes in LV8.x  It's simply a matter of time to adjust to them. 

Actually, maybe we should do our own poll.  How many of us go back & forth with LV versions because of customers..  And how many of those people have a "harder time" adjusting..  Or did old age catch up to me??    But I doubt I'm the only one..  I mean seriously.. Looking at TiTou's signature makes it rather obvious..  Or is he also going ... ??? 

I do understand why it's there and how it works.  And I'm not disputing that.  I do have a question:  "Will LV9.x call the same feature something else?"  ANd then we discuss it all over again??

At least it's a great way to boost our post count... 😉 

😄

- time for more coffee -

Or is it is the result of our own design?  We wanted / needed this type of feature to offer more flexibility while testing the code.  And I DO understand,,, It is not an easy feature to implement..