ID:113046
 
Applies to:Dream Maker
Status: Open

Issue hasn't been assigned a status value.
tl;dr having an "on move" command for windows, that works in the same way as "on close", could allow transparent skin objects to work.

We've been hearing a lot about people wanting skin transparency for a while now, and I think I may have a solution for this, it's simple but it could be effective.

If there is a way to call a command when a window is moved (in the same fashion a command is called when a window is closed) then we can include transparent skins.

What designers have been doing lately is they've been creating two windows, the main window and a window specifically for transparent skin objects. The background color for the second window is set as the transparent color. They then remove the title and status bars and move it around with winset().

This works for transparent skin objects, however if the main window moves then the transparent windows will become offset.

If there can be an "on move" command that is called when a window is moved it could be used to realign the transparent windows to match the main window with winset.

This can be done now, with the current engine, however without an "on move" call, the check for the transparent windows position has to be called extremely frequently for sake of continuity.

This would allow for more attractive output/input boxes and much more. I hope you consider this and if it's impossible or too detrimental to be productive then I apologize and I thank you for taking your time to read this.

If you'd like an example of a system that works in the way I've described I'd be happy to write up a quick project that matches what our current capabilities are with this transparency issue.

This can also work if client.MouseUP() would return the name of the window for "control". Currently if you click the map and release the mouse it will return "[window].[map]" however if you release the title bar of the window there is no call to MouseUp() at all. I'm not sure which would make more sense to do but those seem like the available options.

either
A: Call MouseUp() from anywhere on the skin, instead of what seems like only the map or,

B: add a command to be called when a window is moved.

Like I said before if this is impossible/redundant/not feasible then I'm sorry if I've wasted your time and I thank you for taking the time to read this.
An on-move command is definitely a possible feature, but using this for simulated transparency is quite hacky and won't produce results anywhere near as good as true transparency. For instance, ClearType will interfere with the one-color all-or-nothing transparency used by transparent-color (a feature that also forces software rendering).
True, but it would probably keep people off of your backs while you're working on your own method. It's up to you what you want to do, I'm just g;ad you took the time to consider the idea.
We're not working on another method. At this time transparent controls are untenable due to limitations inherent in Windows.

Nevertheless on-move wouldn't be a bad thing to have.
I'd like to bump this - mostly due to the "on-move" aspect of this request. It'd fit right in with on-size.
Well, with maptext most people won't need it for the hacky transparency idea I had, but, on-move would still be nice. Personally I'd probably use it for a "snap to border" system that allows you to neatly snap byond windows to fit next to one another by using on-move as a sort of "drop" function for the dragging and dropping of windows.
I would really like the on-move aspect native. It'd help with a lot of things I'm planning on doing in the future.