Get your questions answered by LabVIEW developers.

[tst]

I understand this is supposed to better covered in 8.0, and that it's possible that the beta requirements may make discussing this impossible, but still:

I would like to know what NI's position is about moving LV in a more project oriented direction, having the ability to design a program\project (big\small) from scratch in LV and have some wizard help in the process of building it  (example: State Diagram Toolkit, GOOP).

Also, how about a more convenient way to perform recursive algorithms?

Oh, and those custom controls also sound nice.

[Gurdas]

Hello!

I would like the following to be addressed:

1) Comment tags in the block diagram. I now do it by typing text but at times this gets wieldy

2) Ability to zoom in and zoom out of my block diagram

3) Ability of the front panel of my application to robustly handle different monitor sizes and resolutions. Howsoever much I try (by setting the VI Properties > Window Size and Window Appearance pages) it still gets distorted when run on another size/resolution.

4) An inbuilt code maintenance utility. A common scenario is multiple developers working on same project with each handling one area.

5) Provision for the user to reset the default value of a control IN THE .EXE

Thats all for now.

Thanks,

Gurdas

[Stuart_R]

Just out of interest, why do you need to zoom in/out of the block diagram?

[shoneill]

I don't actually think anyone needs it, it's just the way the human mind works.  If you feel limited by the size of your screen (or your wallet :)), then you just want to squeeze everything in.

Personally I like programming on an old 15 inch monitor running at >gasp< 1024x768 because this FORCES me to have tidy code.  OK it doesn't always work, but things would be so much worse if I had a bigger screen.

I agree with the previous post of nonsense automatic connections on the block diagram.  They're ridiculous.

I repeat my wish for a text-based approach / option to some common LV programming techniques like ActiveX.  Although this may be linked to my 15 inch monitor.....

I would also like to know why some VI server properties aren't available as EXE.  This can really mess up a project if you miss one during development.

Perhaps my biggest wish is an improved HELP system.  Sometimes the help is simply useless, or even contradictory.  Bear in mind I have LV 6.1, so it may already be a bit better.

The "Open/Create/Replace file.vi" is really annoying because every time I want to save an entire project to sick, I can't because the "/" is an illegal filename character.  I always have to create a copy with "-" instead of "/".

I'll stop now before I start ranting.

Shane.

[rogerowens]

I would like to see a discussion and possible implementation on the usefulnes of introducing an EXIT action inside each kind on iterative (and even alternative) construct provided by LabVIEW. I'm sure some purists think it's unwise to use EXITs inside "good code," but I would certainly argue for their usefulnes, especially when error conditions occur at the beginning or middle of a WHILE or FOR loop. It wastes precious amounts of time (sometimes) iterating, doing almost nothing, 'till the normal end of the loop is obtained. This is not a big deal in WHILE loops since an OR of the terminating condition can be added, but in FOR loops (with N wired or not), there's no way to stop iterating prematurely, or at least no way of which I am aware.

I've always disliked using auto indexing in FOR loops because the FOR loop must have code inside it to skip "everything," when for some reason, it becomes no longer neccessary to iterate. This is unfortunate since using auto-indexing saves quite a bit of programming time.

In many other languages you can exit the present structure and "goto" (excuse the use of this, but the "exiting" is very much controlled by the compiler!) to the next outer construct. In fact, some langauges allow an exit from case/switch and even if statements. c, for instance, calls this "break."

What do you think?

[rogerowens]

I wholeheartedly agree with James R's request to allow us to select code and comment it out.

I have always used the case statement too to accomplish this, but there's got to be a better way. Also commented out code could have it own color or grayed out look.

I don't know about you folks, but for mature products, when changing code, we almost always, leave the old code in cased out, so if we or the customer changes our minds, we can re-implement it very quickly. Some think this is wasteful of memory. storage, and loading/compiling times, but I say, the computer does all the work!

[rogerowens]

Concerning Gurdas' request to add comment tags, I agree that would be nice--with the ability to designate an object to which the tags belong and moves with.

However, you already that in a way...

I believe, "you should" always consider, showing the label (right click on border and make the label a visible item) on every construct (with complex code inside it, anyway) and placing your comment there. That way, it moves with the construct. e.g. the label for a Case structure might be the expression in English, e.g., replace "Case Structure" with something like "If we're not all out of items to correct and condition 2 exists, then fix the item otherwise just ignore the item." Comments like these make take a while for you to type in, but years later, someone or an "much older you" will be able to tell exactly what you were doing. Or you could use for the label a paragraph number if you're coding from a spec, etc.

My suggestion here, is that, making the label visible should be the default setting or at least an Option. Don't you agree? That way we're reminded to type something useful there as soon as we create the construct.

[BJK]

I would like to have some sort of shift-register for a case structure! Not passing data from the right to the left (like in a while-loop), but passing data from the left to the right!
Now you have the option "Use default if unwired", but make an extra option: "Use current value if unwired". And then it looks like a shift-register of a while-loop but with the arrow pointing in the other direction.

Let me explain:
When you are using/making a state-machine with a lot of states and you want to pass data from one state to an other state, you need a shift-register (you can also use LV2-style globals, but which is better? Or is there no difference?).
But you have to wire it in every case/state, even if you don't use it in the case/state. When you have a lot of states it is a lot of work!
And when you have or add more shift-registers......

I know it is a kind of laziness, but is to make life easier!

BJK

[Gurdas]

SR,

So that I can quickly reach my desired area of code instead of having to extensively use the vertical and horizontal scroll bars.

One might say that usage of subvis should address this but then there are times when subvis are not desired and the code simply becomes a series of screens.

- Gurdas

[tst]

7.1 is supposed to have a feature that allows gives you a minimized view of the diagram which you can use to quickly move around.