Jump to content
Sign in to follow this  
dbyers3

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

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 :).

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.