OS: XP 5.1.2600 (i.e. no SP)
LS: LS 0.24.7B4
ckVWM: 1.35
desktop module: jdesk 0.70

Bug:
VWMAlwaysOnTop does not work. When this setting is added to a theme what appears to happen is that ckVWM starts acting like a normal window, i.e. if clicked on, it comes to the foreground. (Thankfully this 'normal window' behaviour doesn't occur if VWMAlwaysOnTop is not used.) At any rate, ckVWM certainly does not stay always on top when VWMAlwaysOnTop is set.

Reproduce:
Find any theme using ckVWM and jdesk, and add the VWMAlwaysOnTop setting to it.

Solution1:
Fix the bug. ;)

Solution2:
Switch to rabidVWM. :P

(I have sent ilmcuts a copy of this bug report since he's the last active developer. Minus the 'solution' bits of course. ;)

A my themes ltd-eXPlorer 2, ... VWMAlwaysOnTop works. I Only have to load ckvwm.ddl as first and the then the other modulles. I don't know wy but it seems to work when I load this module first. Using ckvwm 1.3.2.0

ohhhh, thanks for the tip. :)

i will try that, though i don't really like the idea of loading things before a desktop module.

thx for the tip wtrtje, i've narrowed it down a bit. i tried loading ckVWM first, didn't help.

turns out (for me anyway) module order makes no difference - the key is the desktop module... with jdesk-0.70 ckVWM refuses to be on top. with desktop2.dll from the latest indie, it works fine. :|

i've got to send another email to ilmcuts. :P

what desktop module does your theme use wtrtje?

it could be the known (forgotten? neglected? *shrug*) zOrder issue with jdesk; see 00.09.18, jugg's original explanation...

(edit: d'oh, didn't read everything above, so maybe not)

thx tnl...

well, i wouldn't know either way. :P

based on what I've found though, there's another option:

Solution3:
Use indiestep's desktop2 :P

tnl: It actually does sound a lot like that, and ckVWM-1.3.5 doesn't quite have it right looking at the source, but I have no idea why switching to desktop2 would fix it. That is very curious. (but then I don't really understand all of the reasons behind jugg's magic zOrder method...)

*blink* if it was understood, it wouldn't be magic now, would it? :)

Loading the offending module before jDesk should have fixed the problem however. Although it would reapear if you tried toggling the zOrder while running.

Anyway, I'd have to dig back into it to refigure it out, it has been too long to remember. :) But it is all documented in MSDN as well (owner/parent relationships with owned/children) It doesn't really have anything to do with setting "ontopness" except that how the child/parent relation is handled can affect the ontopness when switching things around. Hrmm or something like that, anyway.

The sure fire way of having things work correctly, is destroying the window each time you want to change the parent/owner and re-creating it with the new settings. Might not always be feasible though.

Oh yeah, I think I've seen that at MSDN...

Anyway, destroying and recreating it won't work if you're going to create a layered window (for true alpha transparency). Then you have to create it always on top (or floating?) and switch it to on bottom later. At least, in my experience bad things happen otherwise.

(oh hey, that's in MSDN too: "Note that this [WS_EX_LAYERED] cannot be used for child windows.")

One thing I'd like to see happen, is that we quit calling it "on bottom". There is no such thing. :) You have 'on top' and 'floating'. Then you can dock a window to another window. Also, even when docked to another window (say the desktop) your ontop/floating settings should still have an effect relative to sibling windows within the dock. But saying 'on bottom' just makes things confusing I think. :)

So when you said "... you have to create it always on top and switch it to on bottom later..." I think you meant create a non owned WS_POPUP window, then after the window is created, set that window's parent to the desktop. ? Anyway... :P

"on bottom" = same coordinate system as on top, but stay below all application windows. I think it's sensible to have a simple, intuitive term for this effect. Whether or not the code literally works that way shouldn't really matter if you ask me. :)

Just docking to the desktop will break systems with extra monitors in negative space. Well, unless everyone messing with module positions is intimately aware of how the desktop window works, how docking works, and how multimonitor coordinates work. (with no motivation, I might add, since the vast majority of themers have only one monitor)

Ok, probably a small issue for most people, but when it comes to breaking horribly for a small percentage of people vs. working perfectly for everyone, I'll go for working perfectly. :)

How does the terminology break multi-monitor systems? :) That is all I was talking about, not implementation (which I don't see a difference for either).

In any case, I tend to try to give the most options and if that means making it slightly less intuitive... well we are using text configuration files, so hopefully a term change isn't too complicated for people. Heh, I look at peoples use of RabidVWM and am completely confused with all of that special symbol stuff :P So, I'm not too sure I'll go along with your simple, intuitive term argument. heh.

But that isn't my point. What I like to allow is a floating/ontop option seperate from the docking option.

But that isn't possible using the term AlwaysOnBottom, and the term AlwaysOnTop. Because that would make it confusing, even though with how things are implemented, it is completely valid. When docked to the desktop or something else, one should still be able to control the floating/ontop state. This allows placing one module's window under another, without having them fight for zorder.

Ok, I feel like I'm beating a dead horse. So, I'll quit before it starts to stink. :) No worries RabidCow, its all good, and I doubt I'll have my way. Tradition is tough to fight, especially when I'm not controlling things anymore. :)

As I see it, if you're just docking then the origin is at the upper-left corner of the window you are docking to. In the case of a desktop window on a multimonitor system, logically that would excluding the necessary adjustment to move the origin back to the start of the primary monitor. (unless the desktop was magical, but then you might as well call it "on bottom") I'm just being picky tho. :P

IMO floating/ontop is a really lousy way to control z-order between modules. What if you want to layer three modules? I suppose two levels is usually enough though, it just seems strange to me. :/

The ^@#$%^ stuff in RabidVWM is really nasty, I've been meaning to change that over to something more sensible for a while, just haven't gotten around to it. :/ But still, they don't interfere with simpler settings. You can use them to switch desktops on clicks, but there's still the simpler setting that doesn't require that icky stuff.

So I guess what I'd suggest is to keep onbottom and allow floating/ontop with docking as well. In fact, I might start doing that. :)

mmm, dead horse burgers...