In SketchUp, it’s possible to place the cursor on either the main scroll “thumb” or individual tool thumbs, and move it by rolling the scroll wheel. However, in LayOut, this functionality is missing. Instead, no matter what the focus of the cursor, the scroll wheel moves only the options WITHIN each tool category. I am so used to moving up and down the tray in SU to select material, layer visibility, entity info, style, etc, that when I’m in LO, I have to rethink how I work just to move up and down the tray there.
Do you mean like this? It works for me to scroll through the tray if I don’t have the cursor on a scrollable area within an individual panel. Easiest for me is to move the cursor over the tray’s scroll bar but it also works in the narrow area on the left side as well. Do you not see that same behavior?
Um, not precisely.
I don’t know how you’re using your mouse scroll wheel in your video example.
I also don’t know how to make cool videos like you do…but let me try to explain further.
On the very right side of your illustration is a slider thing, often called a “thumb” that if you put the cursor there, hold down the left mouse button and then move the mouse, the items to the left move, too.
In SU, it’s possible to merely place the cursor anywhere in that region, then roll the mouse scroll wheel (third button?) to accomplish the same thing, without ever moving the mouse.
In LO, however, it is necessary to use the previously described method.
This is just another difference between LayOut and SketchUp that should be eliminated, preferably for the more convenient, an therefore faster (and easier) solution.
The only thing I did was position the cursor over the scroll bar on the right (thumb?) and roll the wheel. At no time in my screen capture (done with a free app called LiceCap) did I even touch the mouse buttons. I only pushed the mouse around the desk and rolled the scroll wheel. When the cursor is over a field like the font list and size and the page of layer fields, then it scrolls in the field rather than scrolling the entire tray.
I see the same kind of behavior in SketchUp.
I see that now, after looking closer.
Sure doesn’t work with MY mouse … I mean, it does in SU, but not in LO.
In LO, my scroll wheel ONLY works if the cursor has first been left-clicked in the item region, Font, style, etc.
FWIW, I have all Dell equipment.
You are full of stumpers today, aren’t you?
So what makes it different between our computers? Your profile says you have both Win7 and Win10. Is this on Windows 7?
This is, yes. My Win 10 system is a laptop, which I use for presentations and little stuff.
Sorry about my stumpers. I seem to have little control over the vagaries of life.
Or of SketchUp . . .
I wonder if the OS is the difference. Can you try it on your Win 10 machine and see if you see different behavior?
Works on Win 10.
This is making me grumpy.
Well, grumpier than usual . . .
Maybe it’s time for some of that stuff you offered me.
I see some querkiness.
For me it works mostly as Dave describes. However, …
If the cursor is over the Typeface list (Text Style panel) the scroll wheel is ignored.
In the pages list (Pages panel) when ever the tooltip for a page item is displayed, the scroll wheel does nothing. I have to wait until it times out and disappears. (EDIT: Well, we can move the mouse a bit to get the tooltip to disappear and then scroll quickly.) Then I have to scroll multiple times quick enough to not allow LO to want to display a tooltip for items as they move under the mouse. If I scroll too slowly, then I get caught in “tooltip limbo” again.
I imagine same thing for the Layers panel and it’s list.
Weirdly, The patterns list (Pattern fill panel) has no problem scrolling when tooltips are displayed.
Yep. That’s what I see.
I am not at all ready to change this Win7 system over to Win10, regardless what Microsoft wishes. Win10 just is too weird for an old Luddite like me.
(And Dan, it’s quirkiness, for what it’s worth. )
Where does this sort of behavior get controlled? Clearly I can scroll in the typeface list without any problem but you can’t. Is this a mouse driver thing? Or is this an application specific behavior?
Why would a mouse driver allow scrolling to work in SketchUp but not in LayOut?
It is not driver. It is a combo of Windows system and the application framework (ie the GUI control classes.)
LayOut uses a different framework then SketchUp.
ADD: Often the instances of these GUI control objects can be tweaked with properties, and set scrollable or not. When not, then their parent window (control) would get the scroll message instead.
(Could be the Typeface listbox is set scrollable when it doesn’t need to be, which intercepts the scroll message and it doesn’t get passed back up the window/control hierarchy. So the whole panel stack (tray) doesn’t “get the message”.
Found another weird thing. When LayOut on my internal display doesn’t have focus (the browser on the external display has it,) … hover scrolling over the LayOut panels works much better because tooltips do not display.
I suppose making both modules use the same framework is an insurmountable obstacle . . .
Yea, I think so. LayOut uses a newer one I believe. I think SketchUp uses the very ol’ MFC.
EDIT: Let me change that. It is feasible that SketchUp could slowly be upgraded to use .NET WinForms like LayOut.
If you’d like another confirmation for Windows 7: I get “main” scrolling with wheel but sometimes it stops and I have to “drop” a panel for it to work again. Scrolling smaller fields such as font with the wheel is a complete no go. SketchUp works fine though.
Somehow I didn’t even notice until now.
Windows 10: all is working as normal for me.
No solution then…how disappointing. It’s extremely frustrating to have to modify my work habits when moving from SketchUp to LayOut.
Maybe one day, this will get fixed. One can only hope, apparently.