Strings [var1,var2,var3,var4,var5] instead of icons

[dbyers3]

Well, My picture didn't show up. Here is a VI descriping what I am talking about. Look at the diagram.

[crelf]

QUOTE(dbyers3 @ Feb 20 2008, 12:58 PM)

Well, My picture didn't show up. Here is a VI descriping what I am talking about. Look at the diagram.

Looks like you're after imperative programming instead of dataflow programming?

[Yair]

You could start by disabling the terminal icon view. This is both an environment option and an option specific to each terminal. Then, you can clean up your diagram and it will be smaller.

You should also note that the terminals are not equivalent to variables. The closest thing to variables are the wires coming from the terminals, which you can't get rid of. You might wish to use an array of strings and use the Array to Spreadsheet string primitive to save some space in this example.

[Ton Plomp]

QUOTE(dbyers3 @ Feb 20 2008, 06:58 PM)

Well, My picture didn't show up. Here is a VI descriping what I am talking about. Look at the diagram.

What is it that your after, and what is your problem exactly?

http://lavag.org/old_files/monthly_02_2008/post-2399-1203578461.png' target="_blank">

Ton

[dbyers3]

QUOTE(tcplomp @ Feb 21 2008, 01:21 AM)

What is it that your after, and what is your problem exactly?

http://lavag.org/old_files/monthly_02_2008/post-2399-1203578461.png' target="_blank">

Ton

That was just a small example of how much realestate strings take up. expecailly if you have to use local variables like I do. Then you have something like "Raw Image From Target 101". Several Local variables of that size take up to much realestate. I usually have a lot string variables that I have to deal with.

[Ton Plomp]

QUOTE(dbyers3 @ Feb 21 2008, 04:21 PM)

That was just a small example of how much realestate strings take up. expecailly if you have to use local variables like I do. Then you have something like "Raw Image From Target 101". Several Local variables of that size take up to much realestate. I usually have a lot string variables that I have to deal with.

You could store all the variables inside one cluster (just like a C struct) and use bundle and unbundle by name to get the items you need a specific point.

Ton

[dbyers3]

QUOTE(tcplomp @ Feb 21 2008, 10:38 AM)

You could store all the variables inside one cluster (just like a C struct) and use bundle and unbundle by name to get the items you need a specific point.

Ton

True, but if you can use a local variable, why can't you just put that local variable name in brackets in a text format? I think it would be much easyier. I understand the dataflow issue. But we do have local variables, which negates the dataflow paradigm anyway.

[Yair]

QUOTE(dbyers3 @ Feb 22 2008, 04:27 PM)

why can't you just put that local variable name in brackets in a text format?

At first I thought this might not be a bad idea, but then I gave it a bit of thought and here are a couple of potential issues:

• Local variables are basically secondary access points to controls. They are not variables. Proposing to explicitly use them as such is a problem.
  
• Presumably, such an interface would have to have all the safeties and niceties LV currently has (e.g. selecting from a list, like Intellisense, making sure you are talking about a specific control even if there are other controls with the same name, etc.). That means that NI will have to put some work into it to get a proper UI and IDE experience. How far do we want to take LV down this road, which essentially brings it closer to IDEs like Visual Studio and Eclipse instead of making its own strong points stronger.
  

By the way, I'm not against text on the diagram. The .NET and ActiveX hierarchies are probably a place where a text node would be useful (although I understand 8.x helped with that somewhat), but for most places, LabVIEW has a specific style it was designed for and text is not a part of that style (nor are local variables).

[dbyers3]

QUOTE(Yen @ Feb 24 2008, 02:49 PM)

At first I thought this might not be a bad idea, but then I gave it a bit of thought and here are a couple of potential issues:

• Local variables are basically secondary access points to controls. They are not variables. Proposing to explicitly use them as such is a problem.
  
• Presumably, such an interface would have to have all the safeties and niceties LV currently has (e.g. selecting from a list, like Intellisense, making sure you are talking about a specific control even if there are other controls with the same name, etc.). That means that NI will have to put some work into it to get a proper UI and IDE experience. How far do we want to take LV down this road, which essentially brings it closer to IDEs like Visual Studio and Eclipse instead of making its own strong points stronger.
  

By the way, I'm not against text on the diagram. The .NET and ActiveX hierarchies are probably a place where a text node would be useful (although I understand 8.x helped with that somewhat), but for most places, LabVIEW has a specific style it was designed for and text is not a part of that style (nor are local variables).

I disagree. Example Formula nodes have no "Intellisense". And they are very handy. The WORST part of Labview is dealing with strings. It's time they did something about it.

[Yair]

QUOTE(dbyers3 @ Feb 25 2008, 05:44 PM)

It's time they did something about it.

If you feel strongly about it, you can try NI's product suggestion center, but I wouldn't hold my breath if I were you.

[Justin Goeres]

QUOTE(dbyers3 @ Feb 25 2008, 08:44 AM)

The WORST part of Labview is dealing with strings.

I think that's a vast overreach. "Dealing with strings" probably wouldn't make the Top 5 in my list of "Worst Things About LabVIEW."

I agree that string handling can take up a lot of screen real estate, but this can be mitigated a great deal by encapsulating more of your code into subVIs to hide (or at least contain) the messy parts. I also question whether you "have to use a lot of local variables". I used to think I had to use a lot of local variables, too. I didn't -- it was my general approach to coding that was wrong. And once I started using better G coding styles & techniques, a lot of other problems went away, too.

All that having been said, I do sometimes wish the Local Variable node was smaller. In the (exceedingly rare) cases where I do actually need to use one, I find myself wondering if NI made them absurdly large to discourage their use .

[PJM_labview]

QUOTE(Justin Goeres @ Feb 25 2008, 12:44 PM)

...I find myself wondering if NI made them absurdly large to discourage their use .

Hmm, interesting tought...

Now that you mentioned it, I wonder if there is a similar purpose behind the "ridiculously" large class icon...

http://lavag.org/old_files/monthly_02_2008/post-121-1203994107.png' target="_blank">

PJM

[Rolf Kalbermatter]

QUOTE(Justin Goeres @ Feb 25 2008, 03:44 PM)

I think that's a vast overreach. "Dealing with strings" probably wouldn't make the Top 5 in my list of "Worst Things About LabVIEW."

I agree that string handling can take up a lot of screen real estate, but this can be mitigated a great deal by encapsulating more of your code into subVIs to hide (or at least contain) the messy parts.

I take LabVIEW's string handling at anytime instead of things like Perl's obscure and very compressed string manipulation operators. I do always get headaches trying to figure out what the result of such expressions would be whereas in LabVIEW I can fairly easily tell what the operators do.

It's using real estate, but hey as you say we have subVIs and they should be used for sure.

Rolf Kalbermatter