Control + Right-Click mouse to activate the Navigation Window and Scroll Window Tool for stationary pointer scrolling (+ Shift for fast scroll)

[HIL_Tech]

Provide an intuitive way to activate the Navigation Window (besides memorization of yet another keyboard shortcut ) and add scrolling features with a stationary pointer.

Holding down the Control key plus holding down the right-click mouse button activates display of the Navigation Window and changes the mouse pointer to the Scroll Window tool.  The mouse pointer remains fixed at the location where the action was invoked and any movement in the mouse causes the block diagram to slow scroll toward the direction of mouse movement.  Additionally, hold down the shift key to activate fast scroll.

Also provide option (under "Tools" >> "Options") to turn off this feature altogether or just to turn off the display of the Naviagtion Window in response to the keyboard/mouse button press combination.  Fresh LV installation would have both features enabled by default to more intuitively introduce users to availability of the Navigation Window/Pane.

[RavensFan]

So you want to come up with a keyboard/mouse shortcut to memorize so that you don't have to memorize "yet another keyboard shortcut"?

I don't see the benefit.

[jcarmody]

It should be hard to navigate a block diagram where a "fast scroll" feature would be helpful.

[HIL_Tech]

Using the control key is hardly a keyboard combination shortcut.  Control is very commonly used in conjuction with mouse actions in most graphical applications.  In that sense it is more intuitive than another Ctrl-Shift-letter combination.

[JÞB]

Let me add my two cents - HARSHLY.

I am dead set against this idea!  Ctrl+Shift+N opens a window that enables poor developers to write bad code.  Making the Navagation Window more readilly available would be the equivallent of open bar AA meetings- Yes it might increase attendance but, at what cost?

NI Owes it to the community to help us develop LabVIEW encouraging best practices.

When do I use the Navagation Window?

1. to get blown-up images of primitives
2. To transit through bad code.

Why make writing bad code easier?

[HIL_Tech]

Jeff.  Thank you for pointing out this potential peril of encouraging degenerate acts of sipping away on poor LabVIEW coding .  This is a very valid point, to which I agree ~almost~ completely...

When writing straight-up LabVIEW, there are so many ways to develop cleanly and keep your code on screen to where there is no excuse for growing it off into the the weeds. 

However, with LabVIEW FPGA (at least in 2011), I quickly found much cause to keep all code in the block diagram flat.  I have to admit, in FPGA domain, my code spills down the street and into the bar in the next town.  Multiple reasons for this.  1) FPGA code is mostly parallel.  2) Compilation: for one example, passing an array into a sub VI is a zero FPGA resource maneuver, however there seems to be (at least in 2011) potential for hang-ups in the quality of the intermediate files that get generated.  This in turn causes the Xilinx compilation to fail late in the game, if an array passing subVI is used much at all on the block diagram. 

Since FPGA re-compiles can take a huge chunk of time out of the work day, and I didn't have time to put toward experimentation with compile efficiency, I made a conscious decision to move forward with using only flat coding.

[Intaris]

I agree that while we should definitely ENCOURAGE keeping all code on one monitor screen, there are ALWAYS cases where it's not feasible or not beneficial.  I cannot get behind the rather vocal members who want to burn large diagrams at the stake.  They exist and will always exist.

As long as LV ALLOWS large diagrams, we need better support for working with them.  Repression doesn't work.  Rewarding better coding will.  How to do this? No idea but I DO know that making it hard to work with big diagrams doesn't suddenly make ANYONE think "Gee, maybe I should re-design my application".  It rather provokes the thought "LabVIEW sucks".  I've been guilty of the latter more than a few times, and justifiably IMHO.

BTW, this is all not related to this actual idea, which I actually don't support.  I just find the reasoning against it to be sometimes a bit too evangelical for my experience.

[JÞB]

Shane,

I did not (and would not) advocate for removing the Navagation window.  And, I don't think Crtl+Shift+N is exceptionally painful just, a developer needs to know about it.  Advanced developers do know about it- they should have the expertise to understand where such flat diagrams are beneficial.  ALBIET, with the proper use of "inlined sub-vis" you may have a hard time convincing me the navigation window provides a benefit to large block diagrams since, the call overhead of an inlined sub-vi is gone and the code becomes more readable.   There may be other cases where a large, flat block diagram can outperform a smaller, readable Block Diagram that properly inlines sub-vis.  If you have an example (and I freely admit you might!) I'm all ears.

[Intaris]

I have plenty of examples and before I get burned at the stake, I've inherited tham as part of a much larger application.  this means that I can't just refactor them all because I'd be out of a job before I was finished.

Whether they outperform or not is a moot question in my opinion because once the code is there it's there.  My previous post was less directed at this idea itself (I actually never use the navigation window) but rather at the growing sense that we should force people to avoid large diagrams.  I agree that smaller diagrams with a good architecture is correct but I see the way to get there as being very different to removing or avoiding features.  I would rather NI stopped telling people who have no idea of programming that they're suddenly programmers when they buy a copy of LabVIEW.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.