22 replies to this topic

[Daklu]

As I've been working with Labview for the past year and a half I've noticed there are several trivial tasks I am *constantly* doing that don't matter much individually, but when taken as a whole become annoyances. For most vi's I write 98% of my time is spent on the block diagram. The following suggestions would go a long way towards lowering my irritation factor:

• Enhance the options for default position for labels. On sub vi's I typically put the control labels on the left and the indicator labels on the right. This leaves the wiring path unblocked and occupies less precious vertical space. I also like to put loop labels in the top-left position. Being able to have different default label positions for different types of block diagram objects would stop the constant repositioning.
  
• Free label word wrapping. When using free labels I prefer to use automatic word wrapping as opposed to a hard cr-lf. This lets me easily resize it to fit in the best location. What I end up doing now is typing out enough text to be roughly the width I want, clicking on the box and doing a slight resize to fix the width, then going back and finishing the text. It would be nice to have a keyboard shortcut that essentially says "I'm using automatic word wrapping but I want to stop growing horizontally now and wrap to the next line." Ctl-Enter puts a hard stop in the label; maybe Shift-Enter could be used for this.
  
• Working in the block diagram I'm baffled as to why there aren't controls and indicators in the funtion pallette. All the time I'm dragging constants onto the block diagram and then right-clicking to change them to a control or indicator. Why not use modifier keys to change the object being placed on the BD? For instance, if I hold Ctl down while dragging a boolean constant onto the block diagram it would drop a boolean control rather than a boolean constant. Holding down Shift could drop a boolean indicator.
  
• Block diagram zooming. I brought this up with an NI rep at a conference and the response I received was (to paraphrase), "We don't want people to create block diagrams more than one screen size." Bleh. Forcing the customer to adhere to your preconceived notions of coding style is a bad idea. Imagine if Visual Studio only allowed 25 lines in each code module because "functions should never be longer than one screen." What would happen? Aside from mass migration to other programming environments people would cram more code onto each line. Goodbye readability.
  Being able to zoom out to get a complete view of the block diagram is important for me to get a better understanding of what is happening. Yes, BDs *shouldn't* be larger than one screen, but sometimes they are. (We have one engineer who has dual 30" monitors at his desk. His vi's aren't larger than his screen, but they are certainly larger than mine!) I have also found that trying to limit the size of my block diagram actually makes it harder to follow. I squeeze wires and objects closer together in an attempt to make use of the limited space. Being able to zoom out would relieve me of the need to pack everything in. I could layout my objects in a way that is logical and allow more whitespace to ease reading.
  
• Integrated Development Environment. This is another request I made to the NI rep. He had an answer that sounded reasonable but I forgot what it is. The fact that fulfilling the wish is impossible doesn't stop me from requesting it. (Yes, please move that mountain 2 miles south so I have a better view of it.) Labview windows all over the place drives me absolutely nuts. I connect my laptop to multiple monitors at home and at work; it is not uncommon for me to open a vi and have the window be located completely off the screen!
  I might have 8-12 block diagrams (and by extension, front panels) open at any one time. Throw in additional windows for pallettes and contextual help and I feel like I'm stuck in 1995 coding in VB5. Labview really needs an IDE with dockable toolbars, tabbed code windows, etc.
  
• Front panel auto-home. The front panel has a home location indicated by the large dot on the grid. Sometimes front panel objects get shuffled around such that the home location is either covered by an object or way off the screen somewhere. How about an easy way to automatically return the home location to the top left corner of the FP window?

[Michael Aivaliotis]

I agree with all of your comments. I can help with #2. You should read the tips and tricks wiki page.

http://wiki.lavag.or...ht_while_typing

So, shift+enter works.

[Daklu]

Shift-Enter works for string constants but not for free text labels which is where I would like to see it. I suppose I could comment my code with string constants but that seems so... wrong.

[Michael Aivaliotis]

QUOTE(Daklu @ Nov 21 2007, 01:34 PM)

Quote

Shift-Enter works for string constants but not for free text labels which is where I would like to see it. I suppose I could comment my code with string constants but that seems so... wrong.

Ah, yes. They got merged in my mind as one and the same... so you're right I guess there's no solution there.

[Yair]

Some of these points already have possible solutions you can implement yourself or answers:


QUOTE(Daklu @ Nov 21 2007, 09:59 PM)

Quote

Block diagram zooming.

Not that it helps that much, but LabVIEW has the zoom window which displays an image of your entire diagram and allows you to pan it. Not as nice as a zoom, but it works.

QUOTE[indent]Integrated Development Environment. This is another request I made to the NI rep. He had an answer that sounded reasonable but I forgot what it is.[/indent]

Are you refering to this?

QUOTE[indent]Front panel auto-home[/indent]

You can write a simple VI which will be accessible through the Tools or File menu and will set the Origin property on the VI you call it from to [0,0]. To do this, you need to put the VI in the LabVIEW\Project folder and then use a specific property. You can see in example here.

[Michael Aivaliotis]

QUOTE(Yen @ Nov 21 2007, 01:53 PM)

Quote

Are you refering to this?

Yes he is.
All I have to say is... Nobody asked me. :thumbdown:

[crelf]

QUOTE(Yen @ Nov 22 2007, 07:53 AM)

Quote

Are you refering to this?

I remeber seeing a mock-up of this years and years ago, and I've got to admit that I was pretty excited by it. I can understand Stephen's comments, but I wonder if it can be revisited?

[Ton Plomp]

QUOTE(Daklu @ Nov 21 2007, 08:59 PM)

Quote

3. Working in the block diagram I'm baffled as to why there aren't controls and indicators in the funtion pallette. All the time I'm dragging constants onto the block diagram and then right-clicking to change them to a control or indicator. Why not use modifier keys to change the object being placed on the BD? For instance, if I hold Ctl down while dragging a boolean constant onto the block diagram it would drop a boolean control rather than a boolean constant. Holding down Shift could drop a boolean indicator
4. Zooming[...]

For 3 you could quite easily (with scripting and the .mnu toolkit) create merge VIs that would contain the items you need.

About 4, as Yen mentioned there's the overview, but that is a navigation window, what did you want to do in a 10 times zoomed window for programming, please enlighten me since I don't see the point.

Ton

[Yair]

QUOTE(tcplomp @ Nov 22 2007, 09:35 AM)

Quote

For 3 you could quite easily (with scripting and the .mnu toolkit) create merge VIs that would contain the items you need.

I knew I forgot something. I was thinking of merge VIs as well, but for the issue raised in item 1 (styled loops).

[bono02]

QUOTE(Daklu @ Nov 22 2007, 04:59 AM)

Quote

• Block diagram zooming. I brought this up with an NI rep at a conference and the response I received was (to paraphrase), "We don't want people to create block diagrams more than one screen size." Bleh. Forcing the customer to adhere to your preconceived notions of coding style is a bad idea. Imagine if Visual Studio only allowed 25 lines in each code module because "functions should never be longer than one screen." What would happen? Aside from mass migration to other programming environments people would cram more code onto each line. Goodbye readability.
  Being able to zoom out to get a complete view of the block diagram is important for me to get a better understanding of what is happening. Yes, BDs *shouldn't* be larger than one screen, but sometimes they are. (We have one engineer who has dual 30" monitors at his desk. His vi's aren't larger than his screen, but they are certainly larger than mine!) I have also found that trying to limit the size of my block diagram actually makes it harder to follow. I squeeze wires and objects closer together in an attempt to make use of the limited space. Being able to zoom out would relieve me of the need to pack everything in. I could layout my objects in a way that is logical and allow more whitespace to ease reading.
  
• Integrated Development Environment. This is another request I made to the NI rep. He had an answer that sounded reasonable but I forgot what it is. The fact that fulfilling the wish is impossible doesn't stop me from requesting it. (Yes, please move that mountain 2 miles south so I have a better view of it.) Labview windows all over the place drives me absolutely nuts. I connect my laptop to multiple monitors at home and at work; it is not uncommon for me to open a vi and have the window be located completely off the screen!
  I might have 8-12 block diagrams (and by extension, front panels) open at any one time. Throw in additional windows for pallettes and contextual help and I feel like I'm stuck in 1995 coding in VB5. Labview really needs an IDE with dockable toolbars, tabbed code windows, etc.
  
• Front panel auto-home. The front panel has a home location indicated by the large dot on the grid. Sometimes front panel objects get shuffled around such that the home location is either covered by an object or way off the screen somewhere. How about an easy way to automatically return the home location to the top left corner of the FP window?

"We don't want people to create block diagrams more than one screen size."

I agree with you, zooming would be better. It's painful by dragging the slider right and bottom, also by using navigation window, we still have to click on that
small window, a shortcut would be better!

For writing comment I usually did shift+right click, and choose the Text icon (I think this is a standard one), why do you need string constant?

Also the front panel, sometimes in the Back Panel I create a ctrl or indicator, then when I switch to FP, I have to -again- drag the slider to find the control/indicator
which has been created

And another one, for XP user maybe you can consider of installing a free add-on from Windows, Powertoy the alt-tab replacement, you can click on the small-screen when you are switching window using alt-tab.


Bondhan
~Another Certified LabView Newbie

[Justin Goeres]

QUOTE(bono02 @ Nov 22 2007, 08:08 PM)

Quote

I agree with you, zooming would be better. It's painful by dragging the slider right and bottom,

I do almost all my scrolling by using the draggy-hand-tool (does it have a real name?).

I mean the thing you get by doing shift-right-click, then selecting the draggy-hand (as distinct from the pointy-hand). Then you can click+drag to scroll the diagram (or front panel) around. It saves trips back & forth to the scroll bars, and is a pretty easy dance to perform once you get used to it. I do wish there was a slightly easier way to activate it (like ctrl+shift+drag or something).

EDIT: Here's what I mean:

[JDave]

QUOTE(Justin Goeres @ Nov 22 2007, 07:21 PM)

Quote

I do almost all my scrolling by using the draggy-hand-tool (does it have a real name?).

I mean the thing you get by doing shift-right-click, then selecting the draggy-hand (as distinct from the pointy-hand). Then you can click+drag to scroll the diagram (or front panel) around. It saves trips back & forth to the scroll bars, and is a pretty easy dance to perform once you get used to it. I do wish there was a slightly easier way to activate it (like ctrl+shift+drag or something).

The "draggy-tool" (is it the 'Pan' tool perhaps?) can be invoked by ctrl+shift+drag if you have the auto-tool on.

[Yair]

QUOTE(JDave @ Nov 23 2007, 08:32 AM)

Quote

The "draggy-tool" (is it the 'Pan' tool perhaps?) can be invoked by ctrl+shift+drag if you have the auto-tool on.

And creating a comment is as easy as double clicking an empty part of the diagram and typing.

That's two points in favor of the auto-tool which are not immediately apparent.

P.S. Yes, I would agree that it's called "Pan".

[Justin Goeres]

QUOTE(JDave @ Nov 22 2007, 11:32 PM)

Quote

The "draggy-tool" (is it the 'Pan' tool perhaps?) can be invoked by ctrl+shift+drag if you have the auto-tool on.

WTF? That totally isn't happening on my machine, and I definitely have the auto-tool on. Ctrl+Shift+Drag just expands the diagram (or front panel) like I'm not holding shift at all. Weird.

QUOTE(Yen @ Nov 23 2007, 05:35 AM) [indent]And creating a comment is as easy as double clicking an empty part of the diagram and typing.[/indent]
I wish, however, that it would create a System Label instead of the regular label it creates.

[Yair]

QUOTE(Justin Goeres @ Nov 23 2007, 04:58 PM)

Quote

WTF? That totally isn't happening on my machine, and I definitely have the auto-tool on. Ctrl+Shift+Drag just expands the diagram (or front panel) like I'm not holding shift at all. Weird.

Works fine for me in 7.0 - I never saw any problem with that and I've been using it quite a bit for at least a couple of months (I knew about it before, but for some reason didn't use it). Did you try both sides of the keyboard? I assume you would notice if your shift key didn't work. Also, I assume you made sure you pressed shift before you dragged.

[Justin Goeres]

QUOTE(Yen @ Nov 24 2007, 09:54 AM)

Quote

Works fine for me in 7.0 - I never saw any problem with that and I've been using it quite a bit for at least a couple of months (I knew about it before, but for some reason didn't use it). Did you try both sides of the keyboard? I assume you would notice if your shift key didn't work. Also, I assume you made sure you pressed shift before you dragged.

Hmmm.... OK, it works for me in 7.1.1 and 8.2, but not in 8.5 . I can't find anything in the Options dialog that looks like it would be related, nor do I know of any suspicious INI keys.

Can someone else try it in 8.5 on their machine to confirm whether it's just me, or whether the shortcut is just missing in 8.5?

[Michael Aivaliotis]

QUOTE(Justin Goeres @ Nov 24 2007, 11:04 AM)

Quote

Can someone else try it in 8.5 on their machine to confirm whether it's just me, or whether the shortcut is just missing in 8.5?

It works for me in 8.5 too. What's wrong with you?

[Justin Goeres]

QUOTE(Michael_Aivaliotis @ Nov 25 2007, 04:53 AM)

Quote

What's wrong with you?

Truly, that is one of life's greatest mysteries. If you solve it, do let me know. :ninja:

In other news, turning the autotool off and then back on solved the problem for me, so the draggy-hand-pan-tool shortcut works now.

[Justin Goeres]

QUOTE(Michael_Aivaliotis @ Nov 25 2007, 04:53 AM)

Quote

What's wrong with you?

Truly, that is one of life's greatest mysteries. If you solve it, do let me know. :ninja:

In other news, turning the autotool off and then back on solved the problem for me, so the draggy-hand-pan-tool shortcut works now.

[robijn]

QUOTE(Daklu @ Nov 21 2007, 08:59 PM)

Quote

• Imagine if Visual Studio only allowed 25 lines in each code module because "functions should never be longer than one screen." What would happen? Aside from mass migration to other programming environments people would cram more code onto each line.

I don't get the comparison. Visual studio does not have this limitation, neither has LabVIEW. The view of both are limited by what fits on the screen. You have to scroll in both if the code is too large.

I think this feature would be considered by many as an invitation for satelite view programming. Like with Google Earth you zoom in on the part of the block diagram you want to see. That would result in even worse block diagrams than what I've seen sometimes. I hate the auto resizing structures as they also resize when you don't want them to. And even worse, this resizing messes up other parts of the block diagram. No, a subVI is definitely much more than just a part of the code that could have been present in the main VI.

Joris