Is there a method for forcing a window to be always on the bottom, even when activated?
I tried using SetWindowPos relative to HWND_BOTTOM during every WM_ACTIVATE message, and it works... but only after the window has been redrawn over the screen. So it causes flicker.

I wish there was a WS_EX_BOTTOMMOST style. ;)

Posted on 2004-03-28 19:26:53 by iblis
Hi Iblis,

Do you need input with the window ? If not then try this, set up for a dialog, if you need input remove the WM_MOUSEACTIVATE stuff but you will have to work out the caption click yourself...


cmp D[wParam],TRUE
jne >
invoke SetWindowPos,[hwnd],HWND_BOTTOM, 0, 0,\
invoke SetWindowLong,[hwnd],DWL_MSGRESULT,FALSE
jmp >>.EXIT
invoke SetWindowLong,[hwnd],DWL_MSGRESULT,TRUE
jmp >>.EXIT

Posted on 2004-03-28 20:12:24 by donkey
Thanks Donkey.
I'll give it a try. Will setting DWL_MSGRESULT have any effect if the window isn't a dialog? Can I omit it?

And yes I do need input. I basically want to emulate the explorer desktop window.

I've googled around, but surprisingly found next to no information on any standard method of forcing a window into the background.

I'll mess around with it a bit tomorrow.
Posted on 2004-03-30 02:55:44 by iblis
Hi Iblis,

Just leave it out for normal windows. The thing is that dialogs only expect FALSE or NOT FALSE (not actually TRUE which is 1) as return values, you use DWL_MSGRESULT to return the proper values to Windows regardless of what you return in the dialog callback. With a normal window you just return the value in EAX.
Posted on 2004-03-30 03:19:52 by donkey
Yeah I know, I was just wondering if maybe that was part of a trick or something that you learned to get it to work right, even on non dialogs.
Posted on 2004-03-30 18:55:45 by iblis
Hi Iblis,

Nah, no special trick, just that I only ever use dialogs. I find the visual designing speeds up development and if you handle them right they are almost as fast as windows. Since it is just the GUI in most cases the slightly slower reaction is not even noticable. The only place where there is a significant difference is in the resizing but if you write a good routine you can negate that difference. But mostly I'm just too lazy to calculate and test every control position.
Posted on 2004-03-30 19:07:00 by donkey
Somewhat out-topic (but I guess it's okay since the original question was answered): I was wondering what you guys think about the use of dialog units instead of pixel positions? It's probably good for visually impaired people, but I've never needed it for the purpose of large fonts, even with resolutions like 1280x1024.

Also, with CreateWindows* applications, is it a requirement to respect the dialog unit settings if you want windows logo certifications? If not, I feel tempted to create my own dialog format and "dialog player", both to get a somewhat smaller dialog data, but also to facilitate the construction of a custom windowing class model ...
Posted on 2004-03-30 19:49:39 by f0dder
I don't know enough about the Windows Logo approval thing so no comment on that.

I prefer pixel positions. With dialog units I'm never quite sure how the window is going to look on different systems and in certain cases I need to know exactly how big or small the window will be and I don't want to bother translating the values. However I suppose by using dialog units you're providing the user with something they are 'comfortable' with and for commercial software that can be a big plus.

I've thought about implementing my own custom dialog format in the past but I just don't have the time to mess with it. But it would be nice to be able to quickly implement dialogs directly from the source code without having to compile it separately.
Posted on 2004-03-31 19:38:59 by iblis

Dialog units to pixels are calculated based on the metrics of the dialog's font. If you specify a font when you build your dialog the pixels sizes will always be the same. The only exception is on screens of something other than 96dpi, then the dialog will be resized to look identical on that system.
Posted on 2004-03-31 19:46:02 by donkey
I usually just let it use the default font, whatever that might be. But that's good to know.
Posted on 2004-03-31 20:37:39 by iblis

Well I figured it out and the solution is pretty easy.

Handle the WM_WINDOWPOSCHANGING message and set the .hwndInsertAfter member of the WINDOWPOS structure pointed to by lParam to HWND_BOTTOM. Works like a charm.
Posted on 2004-04-04 18:20:30 by iblis
how does litestep do it?
Posted on 2004-04-04 20:35:09 by comrade