Page up and Page down navigation of Block Diagram

[Intaris]

I find myself intuitively reaching for Page up and Page down when trying to move up and down through a Block diagram.

I think it would be cool if we coulf "scroll" up a window height at a time when pressing Page Up.  Of course this should work also for the FP, event hough the uses there are probably less.

And yes, the caveat that code shouldn't require this is till valid and proud we are of all of that but we allow block diagram sizes of what, 16k x 16k or something?  Wee could use this help.

Shane.

[PaulG.]

I've worked with enough oversized diagrams to last 10 lifetimes. Any idea that might encourage this practice is a bad idea. 

[X.]

Not mentioning that some diagrams extand horizontally rather than vertically...

[altenbach]

>> Of course this should work also for the FP, event hough the uses there are probably less.

Two comments before I think about this more....:

• PgUp|PgDown can be assigned for key navigation. Do you want it only in edit mode or also in run mode?
• I think half a screen at a time would be more functional to retain coherence between views. You can always get a full screen scroll by double-tapping. 😄

[Intaris]

Oh come on, this "We deny things because some idiots might see it as a licence to code badly" is rubbish.  People who code badly do it no matter what tools they have.  Some  even go to great lengths to program badly when programming well seems to be much easier.

I have some VIs which CANNOT be made much smaller without sacrificing functionality or readibility.  We do some extreme processing on RT systems for example where even sub-VI overhead is a factor to be reckoned with.

[Mads]

Kudos to Intaris' comment(!). The whole idea of trying to limit bad coding by not making available features more user friendly is flawed (it is currently blocking improvements for things like sequence structures, local and global variables, block diagram navigation etc.). As long as a feature has a valid use case it should be subject to development/improvements. If not, remove the feature.

[PaulG.]

Just the steady increases in monitor pixel size has made the practice of making larger and larger diagrams incrementally worse. Do we encourage manageable block diagrams or not? Do we start a holy war or do you learn how to use a scroll wheel? 

[Intaris]

Funny, my monitors are equipped with increasingly smaller pixels over the past years....

Scroll wheel is not an option for someonw suffering with carpal tunnel.  You know how sore it is to scross so often to get a full page of scrolling action done?  The Keyboard is so much easier in that regard.

Is Page Down linked to any action currently ont he BD?

[SteenSchmidt]

@Intaris: I program a lot of Real-Time as well, probably 80-90% of everything I do. I don't find any problems with keeping small block diagrams on RT - at least diagrams that easily fit inside ½-1 screen height and 1-1½ screen width.

SubVIs on RT work just fine. My RT-modules usually look something like this one:

You can split each loop into its own subVI earning compact size while maintaining determinism. SubVIs can be inlined, they can run as subroutine, they can run with timed structures and so on. You can do a lot to maintain determinism without experiencing a penalty due to some code being in a subVI. Just make sure you don't switch execution systems nor get hit by priority inversion. These are the two things you need to be good at to be a good Real-Time programmer; manage your resources well and don't pendle priorities. SubVIs don't have to be a problem. You gain much more by encapsulating your code than by having one big BD with (maybe) slightly less jitter.

On FPGA it's a slightly different situation since you often need to place many IO nodes on the top-level VI. These nodes cannot be embedded in subVIs so will sometimes blow up the top-level diagram size.

Cheers,

Steen

[Intaris]

Steen,

if I was writing the RT code myself from scratch all that would be no issue at all.

Inheriting legacy code from (originally) LV 7.1 makes things a lot more diffucult when you simply don't have the time to do a full refactoring.....

Even though your point may be valid I don't see why it should preclude the ability to scroll with the Page up and Page down buttons.....  I mean in a perfect world we wouldn't need police or army either....

[SteenSchmidt]

No, you're right. I didn't mean to imply that this idea shouldn't be implemented based on my arguments.

Cheers,

Steen