Maybe Lummox could add some sort of window linking. So you can make one window that "floats" on top of another window, always moving with it. Would be useful for much more than just this. Sort of like a detached child/pane of sorts.
Though in the picture that guy posted, it looks like he could just set the BG color of whatever control that is to white <.<

wat o.O

Falacy wrote:

wat o.O

Ugh, look at my screenshot while you read that post.

Icon[base] go on box[tiny]. If icon have white background -> box covered.

Here's what he's doing.

He has a box (a 32x32 window containing an image) on top of the background image.

He wants the box (the one that's on top of the background, containing the image) to have a transparent background.

The 32x32 box will always cover up the smaller 24x24 image that makes up the background. That's why he wants the box to have NO background, and just hold the image.

There's basically no other way to do this.

A box? a window? I think those are horribly inaccurate terms =o

Same thing.
You obviously understand what I'm saying.

Not sure how you deduced that from what he provided but OK.

We are talking about the area with the half naked guy in it correct?
It doesn't look like setting a white BG there would cover anything.

No, but if you look at the image, you'll notice all the little dashes randomly all over the place. Those are all white boxes overlapping the background image, which is what he's trying to avoid happening by giving the boxes (controls) a transparent background.

So sad D:
Why the hell does it have to be impossible!!

Hulio-G wrote:

Toushiroa wrote:

So sad D:
Why the hell does it have to be impossible!!

Well I've seemed to have figured out how to solve this. Since grids cannot have transparency (and labels can't be used for mouse processes, which will be needed), I'd have to make each skill have a black box under it by default.

And then again since there is no transparency I'd have to space out every one of those black slots so backgrounds dont overlap, which basically means I'd have to redo the skill list, the hud and the inventory; I'd basically have to redesign the entire interface over this one little design flaw, awesome. I honestly didnt even think it was this much involved in my system untill it now.

I'm not sure I follow what you're saying there, but if you've found a decent way to exploit the limited transparency effects allowed in Windows, by all means have at it. If your own ingenuity has revealed as solution that works for you, that's terrific. Sometimes when faced with a limitation, finding a workaround you can live with is the best option.

It does seem the method is fairly convoluted, but then that's really at the heart of the problem regarding why there is no general implementation of this sort of thing. It is important to note that while Windows provides for limited transparency support for windows, it does not do so for controls within a window.

Why is it everytime someone reveals a byond limit theres around 8-10 of the same men who always say it's impossible?

Frankly, because usually there's around 80-100 people who've already encountered the same limit without doing a forum search to find out if their idea is feasible. Transparent controls are very much in this category. The unfortunate thing is that transparent/translucent controls aren't so much a limitation of BYOND but of Windows itself, so it seems like something that ought to be easy to do even though it isn't.

Transparent controls are something I've tried on several different occasions to achieve, without any true success whatsoever. I haven't kept count, but I believe it's something like four separate times Tom and I have put forth a concerted effort to track down any means of doing this. Each time it ends in frustration with the idiots in Redmond who should have at least come up with a game plan for this in Windows 98. We do have somewhat hacky support for transparent labels, and the bar control uses window regions (not quite the same thing, but also hacky), but for other controls we are limited by the fact that we do not control their paint processes or the Windows paint model in general. Note that among all the Windows programmers out there, no one has ever found a satisfactory solution to this problem that works in a dynamic environment; if they had, I assure you Tom or I would have found it.

The only solutions we did find were limited cases where the control was never meant to move, controls didn't overlap, and so on. These methods might well dress up an app with a hard-coded interface but they would be useless in an environment like BYOND. If anything these partial solutions have muddied the waters because you can find people left and right who will tell you transparent controls are possible, but who forget to mention that it only works in limited situations. After finding one of these methods I mentioned to the author of the article that it didn't work in several scenarios like moving or overlapping controls, and he said he'd be working on those cases next. Last I checked, he was still stumped; I firmly believe it's because he's chasing an impossible goal.

There is one spot of good news, in that Vista introduced a new paint model that uses off-screen buffering, which may potentially make something like this feasible down the road. The down sides are, it's not entirely clear that this actually would allow for transparent controls (the aforementioned legion of Windows programmers has not found a solution yet to my knowledge), and if it did it would only work on Vista or Windows 7 (assuming Windows 7 didn't revert the paint model). So this is something we can possibly revisit at some point if the technology has indeed made it possible. I just doubt we'll revisit it any time soon, because trying to tame transparency in Windows is the wildest of wild goose chases.

Lummox JR