Method signature is:

public static void SetZIndex(UIElement element, Int32 value)

The max value you can pass in is:

Int16.MaxValue – 1 = 32766

WTF1: You can pass out of range values without knowing.

WTF2: The max is one less than Int16.MaxValue.

 

Silverlight is a cluster of WTFs, but this is the most blatant I've ever seen.

 

Dare I ask what the minimum value you can pass in is?

 For when a pint glass isn't big enough for a pint...

 If you're in Switzerland for example, a pint in a touristy English pub is only 500ml. It'll cost you over £7 as well, the bloody cheek of it.

What happens if you pass in a too-big value? Exception or truncation? Also what's the MINIMUM value? Isn't that pretty important to know?

The "one less than Int16.MaxValue" doesn't seem like too big a deal... it just means they're using Int16.MaxValue as a flag or constant or something. Using Int32 in the function definition might mean the minimum value is Int32.MinValue = -2,147,483,648. For all we know.

This isn't a WTF, but it's a work around for a WTF in the CLR or maybe just C#: It doesn't like you working with integral types smaller then Int32.

Consider if it was an Int16 and you tried the following code:

SetZIndex(element, baseValue + 1)

Compilation error! baseValue + 5 is treated as in int, even if baseValue is a short.

Even if it's two shorts you're using, nope! The operator + is defined only on Int32 and not on anything smaller. C# will upcast shorts to ints all it wants, but won't downcast them implicitly. I learned this lesson working with some third party code (forgot which) that required me to use bytes and binary operations.

The takeaway: Don't muck around with shorts and bytes unless they're absolutely necessary. This is TRWTF, and why this example isn't a WTF by itself.

There are no IL opcodes that perform short or byte addition. This is why it get's upcast. I think the reasoning for not having those operands was because it was unlikely that they would ever be faster than the 32-bit equivalent- most processors work with at least 32-bit register, and while the CLR is designed as a platform independent specification, there is an implicit assumption that the platform is relatively modern- eg. uses at least 32-bit operations.

blakeyrat:

What happens if you pass in a too-big value? Exception or truncation? Also what's the MINIMUM value? Isn't that pretty important to know?

Exception, no documented minimum. But let's focus on the core issue - someone chose that max value, when it would have been trivial to just say the value is Int32, avoiding all the problems described in my first post.

GDI used to have limitations that windows couldn't be more than 32767 pixels wide, a holdover from win16. Of what value is a Z greater than that? Doesn't answer why the limit here is 2^16 - 1 as opposed to one greater, of course.

FrostCat:

Doesn't answer why the limit here is 2^16 - 1 as opposed to one greater, of course.

That's two off-by-one errors for the price of 2^1 - 1!

FrostCat:

GDI used to have limitations that windows couldn't be more than 32767 pixels wide, a holdover from win16. Of what value is a Z greater than that? Doesn't answer why the limit here is 2^16 - 1 as opposed to one greater, of course.

 

Possible that the last value is reserved for overlays / "always on top" or some other special case.

 

How is "always on top" conceptually different from "has the highest possible Z index"?

flabdablet:

How is "always on top" conceptually different from "has the highest possible Z index"?

 

I asked your wife that.

Apparently she doesn't know too much CSS.

flabdablet:

How is "always on top" conceptually different from "has the highest possible Z index"?

 

You're confusing the desired result with an implementation detail.

flabdablet:

How is "always on top" conceptually different from "has the highest possible Z index"?

Because "always on top" means just that. No other window can go higher than it. By contrast, two windows that are otherwise at the highest z-value would be at the same height.. That could be implemented by, for example, reserving Int16Max to mean "always on top."

FrostCat:

flabdablet:

How is "always on top" conceptually different from "has the highest possible Z index"?

Because "always on top" means just that. No other window can go higher than it. By contrast, two windows that are otherwise at the highest z-value would be at the same height.. That could be implemented by, for example, reserving Int16Max to mean "always on top."

How is that different than having two windows that are "always on top"?

joe.edwards:

FrostCat:

flabdablet:

How is "always on top" conceptually different from "has the highest possible Z index"?

Because "always on top" means just that. No other window can go higher than it. By contrast, two windows that are otherwise at the highest z-value would be at the same height.. That could be implemented by, for example, reserving Int16Max to mean "always on top."

How is that different than having two windows that are "always on top"?

Because a window that's at the highest possible z-index isn't necessarily "always on top". It may be a normal window that just happens to be on top (and there are no "always on top" windows present).

OK, let's say we have two windows that are "always on top". We'll call the first one Unstoppable Force and the second one Immovable Object. You move Unstoppable Force to the same position as Immovable Object. What happens?

Now, repeat this experiment with two windows that are not "always on top" but just have the highest possible z-index. Does something else happen?

Do they behave differently with windows that do not have maximum z-index or "always on top" bit set? These two scenarios seem functionally identical to me.

Edit: I would note that the context of this is a Silverlight application, in which I assume windows don't change z-index unless you programmatically change the z-index (ie not as a result of user interaction).

joe.edwards:

OK, let's say we have two windows that are "always on top".

 

I'd have thought "always on top" was a property that could only be applied to one object, meaning nothing could overlap that.

joe.edwards:

OK, let's say we have two windows that are "always on top". We'll call the first one Unstoppable Force and the second one Immovable Object. You move Unstoppable Force to the same position as Immovable Object. What happens?

Raymond Chen writes another article for his blog, and a year or two later when it reaches the front of the queue the rest of us see it.

Scarlet Manuka:

joe.edwards:

OK, let's say we have two windows that are "always on top". We'll call the first one Unstoppable Force and the second one Immovable Object. You move Unstoppable Force to the same position as Immovable Object. What happens?

Raymond Chen writes another article for his blog, and a year or two later when it reaches the front of the queue the rest of us see it.

So... that already happened, nearly two years ago:

http://blogs.msdn.com/b/oldnewthing/archive/2011/03/10/10138969.aspx:

We already know that you can't create a window that is always on top, even in the presence of other windows marked always-on-top. An application of the What if two programs did this? rule demonstrates that it's not possible, because whatever trick you use to be on-top-of-always-on-top, another program can use the same trick, and now you have two on-top-of-always-on-top windows, and what happens?

 

DaveK:

So... that already happened, nearly two years ago:

...quoting the main article that he wrote 8 years ago on exactly the same subject....

Cassidy:

I'd have thought "always on top" was a property that could only be applied to one object, meaning nothing could overlap that.

I've never seen a system with that behavior. Everything I've ever used that allows you to mark a window "always on top" does nothing at all to the always-on-topness of other windows. The usual thing seems to be that any windows marked "always on top" get displayed over the top of any windows not so marked, and when multiple "always on top" windows conflict, they get stacked in order of gaining focus or order of creation or order of something - they don't just mash into each other.

I can't see how needing to work out which "always on top" window really is on top is any different from the need to work out which UI element wins in a contest between any pair that happen to share a given Z-index. So I still fail to understand why, in an API that allows for Z indexes, there needs to be any special provision made for an "always on top" state. What does that achieve that's different from simply using the highest possible Z index?

flabdablet:

Cassidy:

I'd have thought "always on top" was a property that could only be applied to one object, meaning nothing could overlap that.

I've never seen a system with that behavior. Everything I've ever used that allows you to mark a window "always on top" does nothing at all to the always-on-topness of other windows. The usual thing seems to be that any windows marked "always on top" get displayed over the top of any windows not so marked, and when multiple "always on top" windows conflict, they get stacked in order of gaining focus or order of creation or order of something - they don't just mash into each other.

I can't see how needing to work out which "always on top" window really is on top is any different from the need to work out which UI element wins in a contest between any pair that happen to share a given Z-index. So I still fail to understand why, in an API that allows for Z indexes, there needs to be any special provision made for an "always on top" state. What does that achieve that's different from simply using the highest possible Z index?

The addendum I made to my last post was because it occurred to me that they might have meant always-on-top is either a) a sticky bit that says "don't let the user decrease my z-index (by focusing another window)" or b) reserved in the sense that user interaction cannot raise the z-index this high.

I actually doubt it works this way though; rather, it seems more likely each distinct z-index value has a corresponding stacking context, and the z-index remains constant while the window gets shuffled around within this stacking context. In this case, always on top is the same as maximum z-index.

flabdablet:

Cassidy:

I'd have thought "always on top" was a property that could only be applied to one object, meaning nothing could overlap that.

I've never seen a system with that behavior.

 

No? Most graphical desktop systems have it: there can only be one window/dialogue in focus, the mouse can only lie in one region at a time, an ID in HTML must be unique, only one application can receive keyboard/mouse input (okay, not strictly true) but there are many systems where specific behaviour is treated as prime. (singleton behaviour?)

Whether or not "always on top" is the right term to refer to this property, I don't know.

flabdablet:

What does that achieve that's different from simply using the highest possible Z index?

I'm kinda with you on that, except that I feel only one object can take that value. When selecting another object, the values must be swapped to ensure that the one with the highest possible Z-index is still identifiable.

 

 

 Wow, it's like none of you have ever worked with always-on-top windows before.

 Try windows task manager, and enable it in something like a media player -- those usually have the option.

Alway On Top is not some kind of well-defined mathematical concept that you can analyze with pure thought. It works in whatever way the OS author wants it to work. It just puts windows always on top of others. If two windows have always on top, they just interact like normal windows.

DaveK:

http://blogs.msdn.com/b/oldnewthing/archive/2011/03/10/10138969.aspx:

We already know that you can't create a window that is always on top, even in the presence of other windows marked always-on-top. An application of the What if two programs did this? rule demonstrates that it's not possible, because whatever trick you use to be on-top-of-always-on-top, another program can use the same trick, and now you have two on-top-of-always-on-top windows, and what happens?

 

"Sometimes I'm in a hurry, and I want to make sure I am the next person to get served at the deli counter. To do this, I find whoever has the lowest number, knock them unconscious, and steal their ticket. But sometimes somebody else comes in who's also in a hurry. That person knocks me unconscious and steals my ticket. My plan is to set my watch alarm to wake me up periodically, and each time it wakes me up, I find the person with the lowest number, knock them unconscious, and steal their ticket. Is there a better way?"

Cassidy:

No? Most graphical desktop systems have it: there can only be one window/dialogue in focus, the mouse can only lie in one region at a time, an ID in HTML must be unique, only one application can receive keyboard/mouse input (okay, not strictly true) but there are many systems where specific behaviour is treated as prime. (singleton behaviour?)

Whether or not "always on top" is the right term to refer to this property, I don't know.

 Generally, it's not the right way to think of it; "always on top" means (in the absence of other "always on top" windows) that window is above all other windows.  To demonstrate, you can arrange things so that a window that has the focus is hidden behind other windows.  It's not particularly easy to do, but you can certainly do it.

FrostCat:

Generally, it's not the right way to think of it; "always on top" means (in the absence of other "always on top" windows) that window is above all other windows

 

Was my thinking, yup.

FrostCat:

you can arrange things so that a window that has the focus is hidden behind other windows

A window in focus isn't necessarily the one that's always on top (that's two different things) but my "there can only be one window/dialogue in focus" still fits in with the "only one can have this property at a time" paradigm.

 

Cassidy:

FrostCat:

Generally, it's not the right way to think of it; "always on top" means (in the absence of other "always on top" windows) that window is above all other windows

 

Was my thinking, yup.

FrostCat:

you can arrange things so that a window that has the focus is hidden behind other windows

A window in focus isn't necessarily the one that's always on top (that's two different things) but my "there can only be one window/dialogue in focus" still fits in with the "only one can have this property at a time" paradigm.

 

 

The real thing here though is that on most os's like Windows, "Always on Top" really just means "Always on Top of normal windows".  Which is obviously a property that multiple windows can have.

 

Curiously, there appears to be two different types of "always on top" in Windows 8.
There's the first kind with media players/etc, and then there's Task Manager.
It somehow manages to sit above literally everything else, including the start screen, win8 apps and other "always on top" windows.

Salamander:

It somehow manages to sit above literally everything else, including the start screen, win8 apps and other "always on top" windows.

 

No, it does not.

Salamander:

It somehow manages to sit above literally everything else, including the start screen, win8 apps and other "always on top" windows.

 

Then - evidentially - those windows are not "always on top".

Clearly, I'm just imagining this then:

Salamander:

Curiously, there appears to be two different types of "always on top" in Windows 8.
There's the first kind with media players/etc, and then there's Task Manager.
It somehow manages to sit above literally everything else, including the start screen, win8 apps and other "always on top" windows.

 As Raymond Chen's linked articles point out, "what if two windows did this" shows that you can't, in general, guarantee any given window can really be absolutely topmost.  Obviously, Microsoft can make one particular window always be topmost.  You also have to check the menu item to force Task Manager to act that way, and I believe it's off by default in Win 8.

Salamander:

Clearly, I'm just imagining this then:

 

I suppose VLC then uses a "not really always on top", because when I do the same in foobar2000, task manager nicely drops behind foobar.

 

Salamander:

Clearly, I'm just imagining this then:

 

No, you're looking at a window that claims to be "always on top" but clearly isn't.

Only one can be topmost at any one time, so TRWTF is the term "always on top" not actually holding a true meaning.

Cassidy:

Salamander:

Clearly, I'm just imagining this then:

 

No, you're looking at a window that claims to be "always on top" but clearly isn't.

Only one can be topmost at any one time, so TRWTF is the term "always on top" not actually holding a true meaning what I think it should mean.

I don't know about you, but my monitor only displays things in a 2D format, so I could never understand why "always on top" didn't just tile the desktop in the obvious manner.

Just because you want something to disobey reality doesn't mean that it can or even that it was meant to.

boomzilla:

Just because you want something to disobey reality doesn't mean that it can or even that it was meant to.

 

You've never met Steve Jobs then?

Cassidy:

No, you're looking at a window that claims to be "always on top" but clearly isn't.

Only one can be topmost at any one time, so TRWTF is the term "always on top" not actually holding a true meaning.

 

For pete's sake, who cares? It's an option, not a platonic ideal.

 

dhromed:

Salamander:

Clearly, I'm just imagining this then:

 

I suppose VLC then uses a "not really always on top", because when I do the same in foobar2000, task manager nicely drops behind foobar.

 

I swear I had foobar on top of the task manager yesterday, I really do, but now I can't repro.

 

YOU WIN THIS ROUND, SALAMANDER. *shakes quivering fist*

 

dhromed:

For pete's sake, who cares?

 

Kindly stop diffusing our pedantic argument with your level-headedness.

Anyone would think you a moderator, or something.

Cassidy:

boomzilla:

Just because you want something to disobey reality doesn't mean that it can or even that it was meant to.

You've never met Steve Jobs then?

Of course I haven't. But we were talking about you. And Apple's falling market cap is evidence that he was only really able to do that while he was alive.

boomzilla:

But we were talking about you.

 

Yeah, I can dream....

Cassidy:

Only one can be topmost at any one time, so TRWTF is the term "always on top" not actually holding a true meaning.

On Windows Always on top means a layer that's above the regular windows (but not above menus) - until Windows 8, there were 3 layers: regular, always on top, menu, each with it's own Z-order. Windows 8 apparently introduced another layer, which is above the menu layer, but only accessible to Task Manager (or maybe only to immersive processes - Task Manager seems to be one of them).