Jump to content

Barrie

Members
  • Posts

    80
  • Joined

  • Last visited

    Never

Everything posted by Barrie

  1. Geez Michael, is this kind of like a "come as you are" party? I just got a new dev machine so I just have 7.1 and I'm trying to keep it that way. I try to encourage (force?) my customers to keep their systems current. My screen is kinda boring 'cos it's new and hasn't had time to collect all the odd-ball stuff.
  2. 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.
  3. If that's not the worst piece of code I've seen, it's gotta be close :thumbdown:
  4. This may sound simple but I could really help in FP layout. Even better, I think it should be really easy to implement. When using the selection tool, add the coordinates of the tool's position, relative to the front panel, in the same way that it is used to resize or move objects. Second, when the sizing tool is "left-clicked" to draw a box, switch the coordinate display to show the dimensions of the selection box. Why? When laying out a front panel, sometimes it's difficult to judge spacing and balance, particularly on a large FP. This feature would allow the selection tool to be used as a "Ruler" to quickly measure spaces and distances. Grid snap has made FP layout much better, (Thanks NI), but this new feature would make these old eyes much happier.
×
×
  • Create New...

Important Information

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