ive noticed this several times since updating… i’ll go into the right pallet to grab something and when i return to my score, the pallet has moved beyond my laptop screen. Windows 11.
Please search before you post if you can!
Sometimes searching does not yield the right results if yet unmatching keywords are used - the term “extend” wasn’t mentioned in the other thread at all, save for the now created link to this thread.
Right i did search but this didnt show up. Sorry bout that.
id say this is most def a bug. only started happening in 6
It’s not a bug. The informational read-out in the status bar now has more details in it, so it takes up more room. Use the right-click menu on the context bar to control what appears.
I wouldn’t call it a bug either, but mainly because I think it’s too harsh a word for this. On the other hand, I suppose it was not intended for the Dorico window to potentially overfill the screen by this. Could some sort of limitation function as to how many bits of information can be enabled for the status bar be an option for a future update to avoid this?
if its not a bug, its really sad programming. The only way to restore it is to grab the top windows bar, pull it back and then resize it. not a bug??? silly. is there a way to share a screen shot here?
Hey now, could you please calm down a little bit? I do understand your frustration, but this tone doesn’t help at all.
As for a screenshot, you can use the snipping tool: ⊞+Shift+S, then click the third button (between the video camera and the closing X) and select “full screen”. After this, Ctrl+V it right into your post here.
im totally calm and i know how to make a screen shot thanks 
i just think ya’ll re wrong and this is a bug that needs to be tended to. Here is the right side of my screen when this happens:
As noted in the thread that Daniel linked to, what you should do is right-click on the status bar and deselect some of the bits that are displayed there. That will make the minimum size of the status bar smaller, and the window will stop expanding past the edge of your monitor.
Usually, a bug is when something happens in software that’s not supposed to. In this case, the software is behaving as designed – it’s trying to show you all of the things you asked for in the status bar, and the only way to do that is to make the status bar (and the window) longer.
1 Like
Yes, but I think what Barry is referring to is that it may probably be not intended for the window to break the screen boundaries (at least not when it is running in full screen, which it does in his screenshot, indicated by shape of the resize button in the upper right corner) - thus, my suggestion to implement some sort of limiter taking current effective screen width into account and just refusing to have more items checked when the available space is occupied.
and i did that - reduced info in the status bar to stop it happening. How about a UI bug? I just don’t think its suppose to work like this. If that’s how it was designed to work, that’s poor design in my opinion. But call it what you want. It makes no sense, but … ok
1 Like
Then insisting it’s a bug is just collecting scalps. Pointing out the situation once would be enough to prompt any change the Development Team considered necessary.
Well, the thing is this: No application running in fullscreen mode should ever break the screen’s boundaries, unless explicitly told to do so by some special, native function of that software (or in the rare case a screen with insufficient resolution is used, which cannot display the complete UI even at 100% desktop scaling - speaking of the latter, there is no minimum resolution defined for Dorico in the official system requirements on the Steinberg website). A function like the status bar which isn’t explicitly an overall width control function, should always either crop the information, invoke a scroll bar or refuse to enable more info while in fullscreen mode.
When in window mode (non-fullscreen) however, applications are allowed to break the boundaries to enable easy repositioning by the mouse. This also applies to dialogs opened as windows by their mother application running in fullscreen. (The daughter windows should initially open in such a way that every relevant function is immediately accessible and not off-screen though.)
Interestingly, I could reproduce what @dspreadbury describes as intended behaviour only while in window mode, as I presume it is indeed intended, but when in fullscreen mode, my Dorico never broke the screen’s boundaries, both on my Surface Pro’s inbuilt screen (2880p width scaled at 200%, thus having 1440p effective width) as well as on my 34" ultrawide. In fullscreen mode, an overflow of information on the status bar resulted in pieces of that information being cropped, as I would expect it to, so all is fine on my machines regarding the status bar’s behaviour.
That said, I do not question the issue described by @Barry_Chabala being persistent, as it does seem to occur on his machine even in fullscreen mode, which is certainly not an intended behaviour (at least I cannot imagine it to be). To me this is reminiscent of something that I described some time ago regarding the Project Info dialog, but of course I can’t know if these two phenomena are in any way related within the code.
Barry, can you provide us with your screen’s pixel width and the desktop scaling ratio you are using?
1 Like
I’m curious if this happens without zooming (i.e. 100%). Zooming can often present challenges. No excuse not to handle it but knowing if it’s related to that could be helpful.
I remember this to be the trademark resolution of the Surface Pro, generations 4 to 7+. If Barry’s computer is one of those, he has that on a 12.3" diagonal, resulting in 267PPI pixel density. Believe me, you wouldn’t really want to use that at 100% desktop scaling unless for very rare use cases.
1 Like
Just to be clear, I wasn’t suggesting it as a workaround, just a bit of diagnostics.
1 Like
Understood.