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?

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.

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.

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




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.



Are you refering to this?



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.

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

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?

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

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

"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

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:

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