Jump to content


- - - - -

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


22 replies to this topic

#21 Aristos Queue

    LV R&D: I write C++ so you don't have to.

  • Members
  • PipPipPipPipPipPip
  • 2,245 posts
  • Location:Austin, TX
  • Version:LabVIEW 2010
  • Since:2000

Posted 27 November 2007 - 05:22 PM

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

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

#22 TobyD

    The 500 club

  • Premium Member
  • 648 posts
  • Location:Arlington, WA
  • Version:LabVIEW 2010
  • Since:2006

Posted 27 November 2007 - 05:51 PM

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

Quote

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
Toby Dayley

#23 Daklu

    Learning LabFu Daily

  • Members
  • PipPipPipPipPipPip
  • 1,423 posts
  • Location:Seattle
  • Version:LabVIEW 2010
  • Since:2006

Posted 20 February 2008 - 05:42 PM

Late response, but what the heck...

QUOTE(robijn)

Quote

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)[indent]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.[/indent]
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)[indent]Where do you work!?! I had to fight for months to get one 24" monitor![/indent]
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)[indent]None of the MDI environments attempted thus far has been as good as the current scenario of individual windows.[/indent]
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.
Certified LabVIEW Architect
Good software is an investment. Bad software is an expense. Choose wisely.

Dak's First Law of Problem Solving: If the solution looks simple, I don't know enough about the problem.

There are two secrets to success:
Secret #1 - Never tell everything you know.