Power User rant...

[i2dx]

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.

This could be off topic maybe, but I want to ask some questions:

Why are there unwanted spaces (with the width of the scrollbars) at the bottom and on the right side, if you compile a VI? This was fixed with LV 6.1! Ok, you can set the panel size now in the "Window Runtime position" properties, but this are a lot of extra clicks for every VI.

What is that "defer decision" button god for, if the VI is not a subVI and I want to close it?

Why are Typedefs not marked as modified, if they are opened with a different platform? [This is a REALLY nasty bug!]

Why is there no tooltip with the coordinates, when you move the FP with the "hand" cursor?

Why is the "Front panel Position"-field missing in the "Window Runtime position" properties? This would make it easy to build a clean layout.

Why can't I decide on the sub panel itself, whether there are scrollbars, or not, anymore, instead I have to remove them at the inserted VIs, but they still appear for a tick in the IDE...?

and so on and so on and so on ...

BTW: where is the :throwLV8: smiley?

Maybe you think I am a defeatist, and maybe I am, but I'l like to annotate as a statement of defence, that I also am a perfectionist, and LV is far from an improvement compared to LV 7.1. My point of view is: why do I pay for a SSP when things become worse, my work is constrained and I am getting an active gastric ulcer?

please dont hesitate to flame me, if I am wrong;)

[Mike Ashe]

If you program with any high end tool and you expect (demand?) a lot out of it you will eventually get frustrated with some of it's shortcomings. Have you checked to see if 8.0.1 fixed some of the items you mentioned above?

Lots of us have ranted in the past, and there have been some real forest fires on Info-LabVIEW in years past, but we survived and still love the LV tools etc. Have you been programming in LabVIEW long enough to remember the days before UNDO? Many of us should have been issued purple hearts by NI. The ranting got so bad for so long it became a joke on the NIWeek t-shirt in 95.

[i2dx]

If you program with any high end tool and you expect (demand?) a lot out of it you will eventually get frustrated with some of it's shortcomings. Have you checked to see if 8.0.1 fixed some of the items you mentioned above?

Lots of us have ranted in the past, and there have been some real forest fires on Info-LabVIEW in years past, but we survived and still love the LV tools etc. Have you been programming in LabVIEW long enough to remember the days before UNDO? Many of us should have been issued purple hearts by NI. The ranting got so bad for so long it became a joke on the NIWeek t-shirt in 95.

no, I do not remember the days before UNDO - what a luck. And I have to admit - counted in Guru-years - I am still a newbie

[Grampa_of_Oliva_n_Eden]

no, I do not remember the days before UNDO - what a luck. And I have to admit - counted in Guru-years - I am still a newbie

Hi i2dx,

That is quite a shopping list you posted there!

Have all of those issues been reported to NI?

Ben

[Mike Ashe]

That is quite a shopping list you posted there!

Have all of those issues been reported to NI?

Here, here to posting shopping and Santa Christmas lists. One of my better posts on IFLV was a "thank you" (In Your Dreams ...) for features that didn't exist yet. It was a joke. Funny thing was, within 1-2 years most of them became real. (Thanks again to Greg M. and all the NI Elves, you guys are great)

If we're going to ask, let's think big!

[i2dx]

That is quite a shopping list you posted there!

Have all of those issues been reported to NI?

not all, I did not want to harass them ;-)

but at least ... I know allmost all AEs in the german support center. I am sure, they all wish they were in holliday, when I call again. One support request was open allmost 6 month, until they could reproduce and find a solution.

By the way: (I think I never posted it here ...) [and michael will kill me, because I do not keep the threads clean, again]

if you ever get an error -89130 on your PXI, when trying to route a signal to one of the PXI-Trigger-Lines, it means that your application has started before the DAQmx-driver has been completey loaded. But starting the Routing forces the DAQmx driver to load, so ingnore that error, reset the device and do it again (with maybe 10 seconds WaitTime) ...

[Phillip Brooks]

BTW: where is the :throwLV8: smiley?

You know this is LV8 because it's the project icon.

Care to add to the list Michael?

[i2dx]

You know this is LV8 because it's the project icon.

Care to add to the list Michael?

COOOOOL

[Mike Ashe]

You know this is LV8 because it's the project icon.

Care to add to the list Michael?

I second the motion! All in favor say Ale, er I mean Aye,

:beer:

[wwbrown]

I have concerns about many of your points - especially the typedefs. Also add the one about tip strips over case statement selectors that you cannot get rid of (they inevitably cover a comment you are trying to read). That one, however, has been around since LV7.0.

[Yair]

Also add the one about tip strips over case statement selectors that you cannot get rid of (they inevitably cover a comment you are trying to read).

Actually, you can get rid of them. Just add the line showTipStringsOnDiagram=False to your Labview.ini file.

[wwbrown]

Actually, you can get rid of them. Just add the line showTipStringsOnDiagram=False to your Labview.ini file.

The wonders never cease!! Thanks Yen - this one has been bothering me for YEARS and no one I talked to at NI had a clue. How did you find this flag?

[Yair]

The wonders never cease!! Thanks Yen - this one has been bothering me for YEARS and no one I talked to at NI had a clue. How did you find this flag?

It was mentioned recently on Info LabVIEW. I agree, that one is definitely a "life saver".

[Aristos Queue]

What is that "defer decision" button good for, if the VI is not a subVI and I want to close it?

Hm... Well, the Defer Decision button only shows up when the VI is not going to leave memory. If the VI is not a subVI then I can only assume one of the following is true:

1) You have an open VI Server reference to the VI

2) The VI is part of a library and the library is currently holding its member VIs in memory

3) It actually is a subVI... check the VI Hierarchy

If you really can't determine why the VI is staying in memory, report the bug as best you can.

But tell me this... do you like the new Save Changes dialog better than the 7 button monstrosity that existed before?

[i2dx]

Hm... Well, the Defer Decision button only shows up when the VI is not going to leave memory. If the VI is not a subVI then I can only assume one of the following is true:

1) You have an open VI Server reference to the VI

2) The VI is part of a library and the library is currently holding its member VIs in memory

3) It actually is a subVI... check the VI Hierarchy

If you really can't determine why the VI is staying in memory, report the bug as best you can.

But tell me this... do you like the new Save Changes dialog better than the 7 button monstrosity that existed before?

hmm ... interesting. I was complaing about the defer decission button, because I am used to do e.g. the following:

if I have to implement a larger, more complex algorithm in a VI, I open a new VI, where I can develop and test smaller, simpler parts of that algorithm before I fit it all together in the "real VI". In LV 7.1.x if you press Strg-W on the FP you get the "default close dialog", shown in the picture:

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.

I don't think it's a bug - it's a well meant feature, but there should be some possibility to select how to use Strg+N in a project context. Maybe Strg+Shift+N opens a new VI in a "free" context, Strg+N opens a VI in the project context? Maybe this option allready exists? I haven't checked this yet ...

7 Buttons? Where? uhmh? hu? tell me more ...

thanks & regards,

CB

[Aristos Queue]

7 Buttons? Where? uhmh? hu? tell me more ...

The dialog whose picture you posted has 12 different versions depending upon conditions. One of those versions requires 7 buttons. Even the simple version that you posted caused many complaints about people who couldn't tell whether the VI was leaving memory or not (yes, the large block of text tells you, but for many, that text they read once and assume its the same every time). Then there was the fact that the buttons drifted around -- sometimes Save and Don't Save are vertically arranged. Other times they are side-by-side. Finally, that dialog appeared multiple times because we actually needed to ask different questions for different VIs -- a single close could result in multiple VIs closing, some staying in memory and others leaving memory. And then there was the complete lack of explanation as to why sometimes the Cancel button was grayed out. Or, if it wasn't grayed out, what exactly you were canceling. Were you cancelling Close All? or were you cancelling the close of one VI during the Close All? That dialog was the source of a huge number of complaints. Creating a UI that took all possible scenarios into account was non-trivial in the extreme.

[i2dx]

The dialog whose picture you posted has 12 different versions depending upon conditions. One of those versions requires 7 buttons. Even the simple version that you posted caused many complaints about people who couldn't tell whether the VI was leaving memory or not (yes, the large block of text tells you, but for many, that text they read once and assume its the same every time). Then there was the fact that the buttons drifted around -- sometimes Save and Don't Save are vertically arranged. Other times they are side-by-side. Finally, that dialog appeared multiple times because we actually needed to ask different questions for different VIs -- a single close could result in multiple VIs closing, some staying in memory and others leaving memory. And then there was the complete lack of explanation as to why sometimes the Cancel button was grayed out. Or, if it wasn't grayed out, what exactly you were canceling. Were you cancelling Close All? or were you cancelling the close of one VI during the Close All? That dialog was the source of a huge number of complaints. Creating a UI that took all possible scenarios into account was non-trivial in the extreme.

I assume that you are involved in the development process for this part of LabVIEW , so first of all I'd like to thank you for taking the time to care about my concerns. As always (that's the disclaimer...), my review about this topic is just my humble opinion. I fully believe that you did your best and NI did and does a very good job and I fully understand that the save dialog needed some refreshment. My criticism on

[Aristos Queue]

What I'd like to have is the possibility to close and remove VIs from memory, if I don't need them any more.

The Defer Decision button appears ONLY when a VI's front panel is closed and the VI *cannot* leave memory. There are fundamentally three reasons why a user VI cannot leave memory:

0) It's front panel is open

1) It is a subVI of another VI and that other VI is not leaving memory

2) There is an open VI reference to the subVI

3) A special case involving VIs in untitled libraries -- I forget the details of it -- but it basically is the same as reason #1, only instead of a caller VI, it's the owning library holding onto the subVI.

When you close the front panel of a VI, that removes reason #0. If the VI has unsaved changes, that's when we prompt. And the VI is either able to leave memory (none of the other reasons apply) or it is not able to leave memory (one of the reasons does apply). If it cannot leave memory, you'll get Defer Decision.

We did consider adding a Revert button to the dialog -- so you would have the option to "close and keep changes in memory" or "close and reload VI from disk so in-memory changes are lost" -- but, first, adding another button was exactly the opposite of our goal and, second, we'd have to gray out that option under a lot of conditions because the subVI was in use.

If you can find a case where a VI is giving you the Defer Decision option and you know that none of the above reasons apply, I'd like to know about it.

Oh, and regarding criticism of LV -- I'm the one showing up to read an independent user forum. I've gotta expect that the reality doesn't match the marketing literature. If it ever does, well, LV will be complete and I'll have to go find a new job. Just make sure to post a bit of the pleasure with the pain -- so I know what features not to tinker with. ;-)

[Yair]

There are fundamentally three reasons why a user VI cannot leave memory:

1) It is a subVI of another VI and that other VI is not leaving memory

One subset of this which easily confuses users is if you've Ctrl-C'd some VIs.

Even if you close the calling VIs they would still remain in memory (in the clipboard, also visible in the VI hierarchy window), but it would not be clear that they are. This could actually be quite a common use case. I don't know whether LV 8 with the project and the seperate application instances did something to change this.

[Aristos Queue]

One subset of this which easily confuses users is if you've Ctrl-C'd some VIs.

Even if you close the calling VIs they would still remain in memory (in the clipboard, also visible in the VI hierarchy window), but it would not be clear that they are. This could actually be quite a common use case. I don't know whether LV 8 with the project and the seperate application instances did something to change this.

This is still true in LV8.2. The clipboard is a caller that can hold VIs in memory. A bit odd, yes, but I can see how it got this way. If the clipboard didn't hold in memory, if it just recorded name/path of VI, then doing "ctrl+X" on a diagram to remove some VIs, you might be prompted to save those subVIs. And when doing the paste, you might get a conflict with another subVI of the same name already in memory ... did you mean to paste the previous VI of that name or the one you loaded between cut and paste? It gets tricky.

Suggestions?

:!: [About an hour later...] I was working with a graphics program. I closed the program. It asked me if I wanted to keep the data on the clipboard when exiting. Maybe that would be a good idea for LV if you close a VI and that VI is still on the clipboard. ???

[i2dx]

If you can find a case where a VI is giving you the Defer Decision option and you know that none of the above reasons apply, I'd like to know about it.

ok, I tried to reproduce that, and - oops - I found out that it is not that easy:

As far as it concerns only one VI, all the points you described above are true. The problem comes up, if you have unsaved VIs in memory, which is used in an unsaved VI as a SubVI - which exactly meets condition 1). Now let us assume the following: during a long development day you have created lots of "test VIs" (I described that in one of my last posts ...), lets say 10 VIs, used 5 of them used in 5 other VIs as SubVI. Because they were "test VIs" you didn't save them in your project, but you defered the decision. On the end of the day, you have to close them all (or save them), with the "known" result, I was complaining about.

The problem is, you can't close the SubVIs, because they are SubVIs (1.) and you can't close the callers, because they contains unsaved SubVIs. All you can do is to defer the decision and collect them til the closing time, where you have to uncheck the "apply to all" checkbox and close those VIs one by one.

So far so good. Now what can be done about this? umh ... I don't know. All proposals I have so far are half-baked resp. to hard to implement resp. tons of work noone want's to do ... but I hope I could make clear, where the "issues" are?

cheers,

CB

[Yair]

:!: [About an hour later...] I was working with a graphics program. I closed the program. It asked me if I wanted to keep the data on the clipboard when exiting. Maybe that would be a good idea for LV if you close a VI and that VI is still on the clipboard. ???

You should note that I only brought this up as one case where a VI stays in memory, but for which there is no indication. I do not say this is necessarily a big problem.

Currently, copying LV code and attempting to paste it in any other application (including other instances of LV) results in the bitmap being pasted. When you close LV, it gives you the dialog for choosing whether to save or discard the VIs and only keeps the bitmap in the clipboard. This strikes me as reasonable. I would definitely expect LV to give me the chance to save all unchanged VIs in memory before closing it.

How about adding another viewing option to this dialog, where you get a list of all the VIs and you can select what to do for each. Maybe something like the VI settings window we would get when building an executable (where you can modify the options for each VI in the build) or maybe something where you can check one or more of a few columns for each VI to decide what to with it. In any case, this should probably also leave you the option of handling individual VIs (e.g. tell it "discard these VIs, save those, and let me look at that third group so that I can decide for them").

[i2dx]

The Defer Decision button appears ONLY when a VI's front panel is closed and the VI *cannot* leave memory. There are fundamentally three reasons why a user VI cannot leave memory: [..]

If you can find a case where a VI is giving you the Defer Decision option and you know that none of the above reasons apply, I'd like to know about it.

create a Project, create new, blank VI and close it immediately: you'll get the defer decision button. If you remove the VI from the project later, then you can close and remove it from memory. But that are more steps to take then I "like" . A "close and remove from Project" button would be fine in this situation. Ok, that could become difficult, because of e.g. unsaved SubVIs, etc, but I think, that "solution" is worth thinking about?

Oh, and regarding criticism of LV -- I'm the one showing up to read an independent user forum. I've gotta expect that the reality doesn't match the marketing literature.

as former-employee I still feel as "a part of the family" - my oppinion isn't that independed - but on the other hand, I am here to talk about problems, issues, bugs with other experts and not to tell how much I like LV. I think that is prooven by the fact, that I 1) use LabVIEW and 2) sell LabVIEW code to my customers , 3) tell everyone in my courses: use LabVIEW and forget 3rd party hardware, because NI hardware + NI drivers + NI LabVIEW is the fastes, best and most convenient possibility to get your measurement tasks done, etc. Visit one of my courses and you'll feel like in one of theses ">>turbo cutter supersharp<< developed by the NASA" shows

If it ever does, well, LV will be complete and I'll have to go find a new job. Just make sure to post a bit of the pleasure with the pain -- so I know what features not to tinker with. ;-)

with LV 7.1.1 you were close to that ...

[Aristos Queue]

create a Project, create new, blank VI and close it immediately: you'll get the defer decision button. If you remove the VI from the project later, then you can close and remove it from memory. But that are more steps to take then I "like" . A "close and remove from Project" button would be fine in this situation. Ok, that could become difficult, because of e.g. unsaved SubVIs, etc, but I think, that "solution" is worth thinking about?

:headbang: ARGH. That. Is. Not. Supposed. To. Happen. I really thought that had been tested.

If the VI is truly a virgin VI, then closing it should automatically remove it from the project. Now, if you've added it to a library, then it isn't virgin any more because its name has been changed and the library maintains a link to it. But if it is just New>>Project, followed by New>>VI, and then you close the VI, that's just supposed to disappear. Are you sure you didn't do *some* edit to it?

[i2dx]

:headbang: ARGH. That. Is. Not. Supposed. To. Happen. I really thought that had been tested.

If the VI is truly a virgin VI, then closing it should automatically remove it from the project. Now, if you've added it to a library, then it isn't virgin any more because its name has been changed and the library maintains a link to it. But if it is just New>>Project, followed by New>>VI, and then you close the VI, that's just supposed to disappear. Are you sure you didn't do *some* edit to it?

REALLY STRANGE. I was *allmost* sure, that I did no editing. Just to be really sure, I restartet my WorkingPC with LV 8.2 and tried to reproduce it. It worked as it is supposed to happen: The VI is closed, removed from memory and removed from the project tree.

Now I don't now exactly, what I did today in the morning, and how to get that reproduced. Hmm ... on the other hand ... I don't know if I really want this "effect" back, but I am sure, I'll get it back if I don't want it OK, I'll keep my eyes open. It seems, this behaviour has something to do with my own workflow. So I'll find out what happened, and tell you more if I know more ...

thx,

CB