Labels, labels, labels... and controls in the functions pallette

[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:

1. 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.
   
2. 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.
   
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. 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.
   
5. 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.
   
6. 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.org/Tips_and_tricks#Stri...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)

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)

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

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.

Are you refering to this?

QUOTE

Front panel auto-home

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)

Are you refering to http://forums.ni.com/ni/board/message?board.id=features&view=by_date_ascending&message.id=209#M209' target="_blank">this?

Yes he is.

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

[crelf]

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

Are you refering to http://forums.ni.com/ni/board/message?board.id=features&view=by_date_ascending&message.id=209#M209' target="_blank">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)

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 http://community.ni.com/examples/palette-api/' target="_blank">.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)

For 3 you could quite easily (with scripting and the http://community.ni.com/examples/palette-api/' target="_blank">.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)

1. 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.
   
2. 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.
   
3. 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, http://www.microsoft.com/windowsxp/downloads/powertoys/xppowertoys.mspx' target="_blank">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)

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:

http://lavag.org/old_files/monthly_11_2007/post-2992-1195788273.png' target="_blank">

[JDave]

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

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)

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)

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)

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

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)

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)

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)

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)

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)

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)

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

[Aristos Queue]

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

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!

It took me a while to figure out what you meant here. LV does have an integrated development environment, a very complete integration. When I'm told "there's no IDE for this language", I think of a case where someone edits their code in a text editor and then goes to a command line to do a compile.

What you're asking for is a MDI (Multiple Document Interface) for the IDE. That was attempted in LV8.0 and beta users killed it quickly. Very quickly. Since then we've had internal teams continuously researching different environment options. If you look at the LEGO Mindstorms NXT product, you'll see one MDI environment for LabVIEW. The LEGO environment didn't need front panels, which solved one of the major headaches of MDI. Major issues of window management include the context help, the palettes, probes and reentrant VI clones. None of the MDI environments attempted thus far has been as good as the current scenario of individual windows.

The handling of VIs moving from a machine with monitor specs XYZ to another machine of monitor specs ABC is a separate issue, one that has also been addressed in the last couple of releases and is continuing to be worked on.

[TobyD]

QUOTE(Daklu @ Nov 21 2007, 11:59 AM)

We have one engineer who has dual 30" monitors at his desk.

Where do you work!?! I had to fight for months to get one 24" monitor!

As far a zooming goes, I do think it would be nice to be able to zoom out for readability in some cases (none of my code of course ) but I don't see any need to zoom in any further. I would even be OK with the idea of allowing editing only when the block diagram is in standard zoom (fully zoomed in). This would effectively make the zoom "feature" nothing more than a navigation and viewing tool.

-Toby

[Daklu]

Late response, but what the heck...

QUOTE(robijn)

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.

True, the comparison is not perfect. Keeping procedures and block diagrams smaller than one screen are both considered best practices. However, the nature of sequential text languages means having to scroll through code is not as much of a hinderace as scrolling through a block diagram.

Text is easy to digest in pieces. Reading a book isn't difficult even though the text is split across 400 pages. Images are difficult to digest in pieces. Imagine trying to play a game of chess with the restriction that you can only view a 2x2 block of squares at any given time. The game gets much more difficult. The graphical and data flow nature of Labview requires a better understanding of the entire vi--you need to have a better grasp on the "bigger picture" so to speak.

Generally speaking the consequences for violating this best practice are more severe in Labview than in text languages, which equates to Labview effectively enforcing a specific coding style.

QUOTE(robijn)

I think this feature would be considered by many as an invitation for

satelite view programming

... That would result in even worse block diagrams than what I've seen sometimes.

The current limitation doesn't stop people from writing bad code. It can certainly make understanding bad code harder though. I suppose the question ultimately comes down to whether you think the language should enforce coding conventions. Personally I don't think it should.

One other area zooming would help me is when I'm changing my block diagram layout. Often once I get a VI to be functionally correct I see ways to change the layout to make it more readable. Having to scroll around the screen to find my code segments as I'm repositioning them makes this more difficult.

QUOTE(TobyD)

Where do you work!?! I had to fight for months to get one 24" monitor!

Currently contracting near you on the east side of the lake. This particular coworker actually brought in his own monitors. He also brought in two of his own computers, his own binocular microscope, his own Metcal soldering station, and various other personal tools. I guess that's a benefit of being 45+ and single... too much disposable income. :laugh:

QUOTE(AQ)

None of the MDI environments attempted thus far has been as good as the current scenario of individual windows.

I appreciate the difficulties you mentioned in the previous thread and certainly believe you. Let me refine my request by saying I'd like to see *much* better window management. Perhaps instead of throwing icons all over the taskbar there could a "Windows" tab in Project Explorer with a with a twist down "Show Project Explorer" button on the toolbar.