Screen menus do not honor Windows 10 custom scaling.
The ribbon menus response properly to this setting. Screen menus should as well.
Could you post a screenshot of what you see.
Custom screen menus should appear as the size defined by the view in the dgnlib and scaling shouldnt be applied.
On a standard 27" 2560 x 14490 ~110 DPI
The screen menus buttons are much larger than the ribbon buttons.
On a 4K 15" 3840 x 2160 ~285 DPI Windows scaling set to 200%
The screen menu buttons are much smaller than the ribbon buttons.
The size of the screen menu is determined by the named view that you specify in the command. A workaround would be to make different named views for different resolution screens.
Hello Barry,
Thank for the suggested workaround but in my case I don't think is very practical. This is the first level of a 2 - 3 level 15 key system. 15x15 = 225. Thats the minimum number of views I would have to recreate and relink for just one type of screen resolution scenario, of which there could be many. Then customize each computer, independent of user, to point the appropriate menu system.
A more practical approach would be to have all menu systems honor the same scaling factor the ribbon uses.
I was quite excited to get this 4k Windows machine but is been a disappointment on the interface side. Not just Bentley but in general Windows implementation of ultra high resolution displays has been disappointing compared to the seamless implementation I've experienced with Apple products.
I hope you see my point and make try to make the user interface usable without all the IT overhead.
Best Regards,
David G
David,
When we save a named view, we save two pieces of information about its sizing - the rectangle relative to the size of your top level window, and its actual pixel rectangle. Currently, in our screen menus, we use the actual pixel size because it is a more controllable, but that is why you see the size different (in inches) on a 4K screen. We could make it an option to use the relative size instead, and that might work better for your case. The reason that we can't simply use the scaling factor as you suggest is that we don't store that scaling factor in the named view when the named view is saved, so we wouldn't know the right factor to apply when the menu is displayed. For example, if you authored the screen menu on a 4K display, you would want it scaled down on a regular display and drawn actual size on a 4K display, but if you authored it on a regular display, you would want it scaled up on a 4K display and drawn actual size on a regular display. But we don't save that info (and it isn't practical to change the information saved in a Named View at this stage), so we couldn't do it right.
The "relative rectangle" I mentioned above comes close, but it depends on whether you have MicroStation's top level window taking up the whole display or not. If we sized the screen menu based on the relative rectangle, and you set up your top level window to use the top left quadrant of your 4k screen (for example), then the menu would come out half the size as it would when you set your top level window to take up the full screen.
I would appreciate your opinion as to whether it is worth implementing the "relative rectangle" approximation.
Barry