Jump to content

Make more use of cursor keys, etc.


Recommended Posts

Back to the topic of front panel (and block diagram) layout, which I think is extremely important for a professional app:

I set the speed of my mouse to very high, so I'm not waving my arm around and/or wrecking my wrist while doing layout and wiring. Unfortunately, this means that fine movement i.e a 1 pixel resize can be a bit tricky. It also means that clicking on the border of an object to select it can result in an inadvertent resize due to slight mouse movement. It gets worse if you have the alignment grid enabled and it "snaps" to the grid increment, resulting in either movement or resize that is "locked".

I know you can undo or do a ctrl-shift-# (NOT ctrl# as stated in the menu), IF you notice it at the time, but it can be tedious. A simple indicator in the toolbar as to the status of the alignment grid would be nice too.

What I would like to see is the cursor keys enabled when you are doing resize functions, similar to the way you can use the cursor keys to move selected object(s) a pixel at a time.

Resizing an object would be a simple as mousing over the handle of the object, left click, and then simply hit the appropriate cursor key to get (or get rid of) that extra pixel dimension.

NI has done a great job of unifying and consolidating functions that have evolved over the years such as "show.../hide...", now unified under "visible items", and "create", but there are still some inconsistencies.

For example:

-Many items on the block diagram do not display the default label as "editable" i.e. all selected, when the label is made visible. Most notable are the while loop and for loop. I know it's a while loop, so giving me a label that states the obvious, that I can't just directly type over, seems a bit silly.

-Inserting certain objects automatically puts bends in your wires, when none are necessary.

"Remove whitespace" and "To lower case" are two good examples. Curiously, "To upper case" does not show the same behaviour.

-The practice of labeling wires is a good one, particularly on long runs, but moving all the labels, if the VI is modified is a real pain. When will we be able to attach labels to wires?

NI, and experienced wireworkers promote labeling, comments, clean layout and overall documentation. I agree and support them 100%. That said, it's pretty frustrating when various small and large items in LabVIEW prevent you from doing that easily, or worse implement bad practices automatically.

Seeing as how I'm on a roll now:

VI history is read-only. Why is this so? The user can add to it when the VI is saved, or he can erase it entirely so there is nothing sacred about it. This space could be very valuable if we could programmatically modify it, for example date stamping individual VIs when they were included in application builds, referencing build numbers, or if the same VI is used in different apps, flagging a potential problem if the VI is modified.

If read-only is there to maintain some sort of audit trail, then making it "append-only" would work almost as well.

IMHO, NI should appoint someone to track down all the little quirks that, by themselves are minor annoyances, but in total make up for many more keystrokes, mouse clicks and a slower development process.

It's not the sort of quantum improvement that would have LabVIEW 8 flying off store shelves, but it would be something that everyone would benefit from, and IMVHO, would not require a huge development effort.

Link to comment

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.

×
×
  • Create New...

Important Information

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