LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
David_L

Make window scroll bars reflect actual contents of window...

Status: Declined

While I understand the desire here, the alternative is that without this "boundary", it is impossible to create more space without resizing the window, which is also undesirable.  The behavior being exhibited is intentional by design. 

This drives me crazy...  I've noticed that if I have some code on my block diagram (or controls on my front panel) the scroll bars indicate that there is more stuff outside the view of the window that can't be seen.  It would be nice if the scroll bars only activated if there was actually code outside of the screen to be found.  Every time I see this, my OCD kicks in and makes me try to move my diagram to show the hidden code, only to realize that LabVIEW is just messing with me...

 

Of course an image is worth 1024 words..

 

gotcha.png

13 Comments
Darin.K
Trusted Enthusiast
Hopefully the nice picture gives better results taming the runaway scrolling than my attempt.

 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Limit-Scrolling-with-wheel-to-Bounds-of-Panel-Diagram/...
altenbach
Knight of NI

>  It would be nice if the scroll bars only activated if there was actually code outside of the screen to be found.

 

That's actually a tricky one because I think the scrollbars should always be there. We might need them! In fact the scrollbars should have a larger dynamic range to what they currently have (see below)

 

Some scenarios:

 

  • Your code fills the screen nicely, but you want to insert a large snippet below it. How do you scroll the existing code out of the way to create an empty area if you currently don't see scrollbars? (Well, there is also the "pan" tool,  but when whas the last time you used it???)
  • Your front panel has some empty space to the left and top and you would like to align the 0,0 crosshair with the upper left edge of the window. Unless you also have stuff near or beyond the opposite boundaries, you cannot reach 0,0 using the current scrollbar mechanism. They hit their limit before you can get there! (This has bugged me since LabVIEW 4.0 and that's what I meant with dynamic range!).
David_L
Active Participant

Hi Altenbach, you make some very good points.  I agree it can be useful to get to parts of the screen outside of the window. However I think that using Ctrl-drag and ctrl-shift drag would allow you to get around this problem.  


If Ctrl-shift-drag is what you mean by the Pan tool, I use this every single time I program LabVIEW.  It makes it very easy to navigate a diagram or panel.  

 

I just think that the way it is now, it's very deceiving.

GregSands
Active Participant

I agree with David's idea, and further, that the mouse wheel should not scroll past existing code.  Even better if this works the same for horizontal scrolling.  But to partially address Christian's concerns, I'd go along with the Pan tool still being able to scroll outside the existing code, and perhaps also the scroll arrows on either side of the scroll bars. 

AristosQueue (NI)
NI Employee (retired)

Ctrl+shift+alt+anything is magic -- it isn't discoverable in the interface, which makes it hard for a lot of users to learn. I like the scrollbars for their findability and accessibility.

DJed
NI Employee (retired)

If scrollbars only showed existing code, it would be very difficult to ever write NEW code, like dropping new structures and such.

David_L
Active Participant

What if the arrows on each end of the scroll bar still worked to move left and right, but the position of the scrollbar displayed that it was all the way to the end.  I've seen this behavior in other programs, such as Excel and it's very intuitive.

 

I think that combined with the Ctrl-drag and ctrl-shift drag mechanisms would have all the bases covered for extending code outside the visible window.

AristosQueue (NI)
NI Employee (retired)

> What if the arrows on each end of the scroll bar still worked to move left and right, but the position of the scrollbar displayed that it was all the way to the end.

 

Not a standard behavior of scrollbars. You would have to do *something* to indicate that "these bars do not behave like the bars in every other application you've ever used." It might be a good idea to do that, but you can't just monkey with the behavior without changing the visual feedback that users rely on to know how things work. Any suggestions?

David_L
Active Participant

How about something like this:

 

scrollbar.png

 

It shows that the scrollbar is active, however there's nothing out there yet...

 

Looking at my Excel inspiration, it does not seem that they do anything special to indicate that you can go further beyond the scroll bar.  Anyone familiar with Excel would probably be able to pick up on it.  

 

Finally, I think this hurdle will only affect the most beginner of users, and only the first couple of times they try it.  Once you realize "hey, I can think outside the box" it shouldn't be too hard to remember how to move out there.

altenbach
Knight of NI

What if the scrollbars don't show a slider if there is nothing outside the current frame unless we hover over it with the mouse, at which point the scrollbar will appear centered and 1/3 the full width. Grabbing it will allow us to scroll the current code just outside of the borders in both directions. Releasing the scrollbar and leaving the area will either cause it to remain visible if code is now outside, or disappear if all code is still visible.