@JORGE

further to the great info you mailed me on menu's, that got me to thinking how you have already designed a lot of things. So regarding the dynamic Vertical button section of the menu, I thought about good ideas you have already implemented.

I do not know if Microsoft has completely blocked this idea from ever occurring, but is it possible in the button section of a menu, to have an overlay? That would definitely get rid of the image stretching on dynamic menus. As I mentioned, I have no idea if it is possible but it would definitely work.

No, menus currently do not support overlays... and, even if they did support static non stretchable overlays, have you thought about the case where the menu length is too short (i.e. has too few elements in it) for the overlay to fit completely?

Hello Jorge,
A long time ago, in the "button" section, I proposed and requested the ability to overlay a static, non-stretchable image. The lack of this feature limits menu design, it has really bothered me and forced me to create simple menus without incorporating images.
It would be great to include this option; the skinner could then choose whether or not to use it regardless of whether the button is 40, 100, or 300 pixels high but the option would be there.
When I wanted to include an image in a menu, I had to do my own calculations for example, choosing a 40-pixel "AS and IS" button, limiting myself to 11 lines (including separators), and creating a 440-pixel high image (40 x 11). But that was just for me, when someone else downloads the theme, they shouldn't be forced to stick to 11 lines just to get a clean, consistent image. They should be free to do what they want—like adding 15 or 20 lines without the image getting distorted, which might lead them to think the theme itself is poorly made.
This can lead to frustration for both the person downloading and installing the theme and the skinner who created it.
I think BassdudeNZ is facing the same problem and frustration as I am feeling partially restricted and having to make compromises.
I won't compare Winstep to WindowBlinds, as the programming and theme construction are completely different; the latter uses five distinct parts rather than vertical stretching. WindowBlinds isn't really my cup of tea, but it doesn't have this issue.
In my view, adding this feature would offer more freedom and improve the theme-building process. It would be up to the skinner whether or not to use it.

Of course I thought about it. Consider that me, Picco and many others have probably done enough that even if we did not get it right first time, we definitely would eventually. Overlays follow modules they do not stay there or that would defeat the purpose. This is why I asked because unlike 'normal' Windows menus, Winstep menus can be dragged. So I asked and you answered

Can this not be done in a separate process? It already is because the Windows button will bring up the win11 menu? I certainly am not asking you to reinvent the wheel and forgive me for thinking if there is a will that there might be a way.

EDIT: To me it would be no different to working out how the overlay worked with the Disk module. While I certainly have not got it perfectly, I understand how it works and get better each time I do one (hopefully). "IF" the menu could be done, I am sure it would have its own idiosyncracies, but that's all part of learning it isn't it? ALSO - "IF" it could be done, in skinning I think you'd likely need to have a line something like OverlayIsRelative=True/False, so it would either move relative to the top of the button section or be absolute.

Jorge I thought of another 'possible' workaround that might work. Is it possible to write code to say that if a SubMenu exists, then dragging any menu clicked from the MainMenu will only show the submenu and not revert back to the main Menu? If a submenu exists, a person doesn't really need multiple versions of the main menu anyway??? This would do two things. The second menu/SubTheme is easy enough to scale and it would also free up the ability to get creative with the Mainmenu in the vertical section, because it would only show in the Main menu and never rescale because only the submenu after clicking and then dragging would show? So basically the Mainmenu would not be put in a position where it might rescale? Just looking at other ways.

I've split the topic so we don't go back and forth on the other topic, sending hundreds of notifications to everyone whomever posted there.

I still haven't had time to look properly into what you guys wrote after my last response, well get on it ASAP.

Ok, menu height must remain dynamic because it depends on content, and the skinner cannot - nor should he - control that. This means a menu may be too tall - or, conversely, too short - for a static fixed-width/fixed-height image.

If the menu is tall enough to accommodate the fixed-size overlay bitmap, there is no problem: it is simply overlaid on top of the menu at the specified position.

If the menu is too short, however, there are two possible approaches: either crop the overlay bitmap to the available menu area, or - which probably makes more sense - give the menu a minimum height large enough to accommodate the full overlay image. Any unused area below the actual menu buttons would simply remain transparent.

The same principle could also be applied horizontally if the menu is too narrow for the overlay.

In fact, Picco, native Winstep dock skins already support this type of fixed-size overlay, but I don't think any of you have actually used that feature yet, which is really a pity because, AFAIK, no other dock supports overlays - much less fixed-size overlays.