I’ve had a really weird issue for the last few weeks that I’ve just put up with instead of asking the glorious hive mind about, and I decided to come to my senses. When I use Layout, I have it filling one screen, and I have the default tray detached and placed in another screen to give maximum screen fill. I do the same thing with SU. 8/10 times when I try to interact with (click on) any of the windows or buttons on the default tray, it (for lack of a better term) jumps as if scrolled a few times, leaving me far away from the options I wanted to change, and forced to scroll back to where I was. Often times, it will jump again even after I’ve clicked in the tray and scrolled back to where I wanted to be.
I don’t have this issue with the SU tray when I’m using it in this fashion (and at the same time), so it has to be something specific to Layout. It’s a minor complaint, except that it’s now eating up a lot of time in me chasing the menu around the place and causing what must seem like a fit of tourette’s to my coworkers. Any insights?
Wouldn’t a driver issue affect the SU tray as well? I did notice today that SU’s tray creates a separate window bar at the top, but the Layout tray retains its “in program” header bar. Almost like it doesn’t know it isn’t docked.
I did not even think about that.
My SU trays are quite docile on the other monitor. The Layout trays are impossible to dock after they have been moved off site. I have to close them and do a rebuild. ( mine are set up with tabs )
Always had an issue with LO trays when moved onto my external monitor… have never behaved properly… not life threatening just another LO annoyance symptomatic of the clunky user experience…
the trays never position where the cursor is, mysteriously always offset by about a tray width so I can never position them on the edge of my external monitor…
different monitors , resolution settings and graphics drivers through the years have never resolved it!
