We do disable the scrollbars when your document is truly smaller than the window. We consider a certain whitespace border around your objects to be part of the document. The size of the whitespace border depends upon the size of your window... the larger the window, the larger the whitespace border. This whitespace border greatly facilitates adding additional code during development -- it provides visual feedback that the diagram (or panel) can be expanded in that direction, something that a disabled scrollbar does not indicate, leaving newer users very confused about how to expand available diagram space. Although the ideal is a diagram fits on a single screen, growing off screen in a single direction is often useful for a given VI.
I am NOT going to ask that this idea be closed. Even though the current design is deliberate and considered, if there is a groundswell of kudos, we would look at changing the behavior. As of right now, though, we believe this to be a valuable feature of LabVIEW's user experience. My intention in posting this is to make everyone aware of the value of this feature. It may be that you can suggest an idea that retains this value while also meeting the concern you have -- which I suspect is simply knowing whether or not you have code off screen. That may be something that we could indicate in another way rather than disabling the scrollbars, perhaps by annotating the scrollbars.
The mouse wheel will still allow the scroll even though the scroll bars are disabled. Not sure if this fact actually influences anything.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions Unofficial Forum Rules and Guidelines "Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
crossrulz: it really doesn't. Discover-ability is part of the UI design. A disabled scrollbar does not give any feedback to a user that the scrollbar will do anything. It's like keyboard shortcuts that are not in the menus (like ctrl+click on the conpane to swap terminal connections) -- nice if you're an expert, but used by very few people because there's no way to discover the trick on your own short of reading copious documentation.
while also meeting the concern you have -- which I suspect is simply knowing whether or not you have code off screen
It is. This is a regular annoyance, in both the FP and the BD. I don't have any good ideas which won't involve modifying the default behavior of controls other than what's already suggested here.
@AristosQueue (NI) wrote: We consider a certain whitespace border around your objects to be part of the document. The size of the whitespace border depends upon the size of your window... the larger the window, the larger the whitespace border.
Is there a way to twiddle this, like the auto-diagram cleanup tool? (LabVIEW.ini?)
Something experienced users can tweak to their preferences, while allowing useable defaults for n00bs?
We consider a certain whitespace border around your objects to be part of the document. The size of the whitespace border depends upon the size of your window
Ok then i personally feel the white space is a bit misleading.
This bugs me as well, but if I need to drop a parallel while loop, then I need the ability to scroll vertically to draw it.
Maybe disabled is a wrong word i used. The idea is ultimately to give you a rough feel of how much offset you are with respect to coding in a single screen. When you want to extend the screen horizontally or vertically then the scroll bar can get activated .
