Hi f0dder,

The Windows help file specifies that the default path is that one, hard coded (see Dr. Watson options). If it is not present or available then the path will be in the registry key. I seem to remember that a hex dump of DrWatson also had that path hardcoded. But I admit that I didn't pursue the matter much as I abandonned the project as unworkable in the context of programming (where you would normally have a JIT instead).

;) Also if you read the original DrWatson post:

I have put together a test program for people to try on their machines
Posted on 2004-03-14 13:06:34 by donkey
Well, appearantly DrWatson does "the right thing" and uses the registry lookup instead of doing hardcoded paths :) - the writers of the help file probably just thought it was shorter to write it that way, instead of "the DrWatson folder in the 'common documents folder'" - and that it would be easier for the user to figure out what they mean. Or perhaps the helpfile is localized for all windows versions...

Anyway, doesn't matter much as long as you do 'the right thing' in your other apps ^_^
Posted on 2004-03-14 14:01:28 by f0dder
Yeah, I probably would have adjusted it in the final version but I never got past the test stage. It does demonstrate how to handle resizing though, it has virtually flicker free resizing in a dialog, the results would be even better in a window, though in reality a normal window is dumped into a dialog-like modal loop during a move/resize operation anyway so the gain is not as significant as you would expect. This is one of the many reasons I have pretty much given up on windows and use dialogs instead, with proper handling they do everything windows can do but I can build them in a graphical editor.
Posted on 2004-03-14 14:17:48 by donkey
...and that was the thing that was important here :) - catching & nulling WM_ERASEBACKGROUND is generally a pretty good idea when you have the entire client area covered with child controls.

I wish I had a whole chunk of available spare time... building windows "by hand" (CreateWindow* etc) is annoying, but I don't like the idea of dialog units very much. I also don't really like the RAD tools around for HLL's, but - oh well.
Posted on 2004-03-14 18:06:05 by f0dder
ok, i tried it and it works, but there's a problem,
it doesn't update the main window
i only noticed when i changed the size of the listbox which was covering the whole area,
any ideas ?
Posted on 2004-03-15 04:33:02 by someone
Hi someone,

As a rule, I always cover the entire client area when I make a sizable window, the trick will only work on windows where the client area is filled with child controls. About the only thing I can suggest if this is not the case is to handle WM_ERASEBKGND yourself and subtract the regions of the child controls from the update region of the window then paint the resulting region. Create regions for each of the child controls
invoke GetWindowRect,[hChild],offset rc

invoke CreateRectRgnIndirect,OFFSET rc
mov [hRgnChild],eax
invoke CombineRgn, [hRgnChildren], [hRgnChild], eax, RGN_OR

and combine them then to subtract them you use
invoke CombineRgn, [hRgnNew], [hRgnWindow], [hRgnChildren], RGN_DIFF

Then fill the resulting new region with your background brush.
invoke GetClassLong,[hWindow],GCL_HBRBACKGROUND

invoke FillRegion,eax,[hRgnNew]

I haven't done this but it will be something like I have shown.
Posted on 2004-03-15 07:32:42 by donkey
ok, thanks donkey, i have the whole area covered with a listbox anyway, so it won't be too much of a problem, but now i know i wasn't doing it wrong, thanks again
Posted on 2004-03-16 00:01:28 by someone
Hi Donkey,

I am facing this problem too, with the window resizing and flickering. I am writing a dialog based application, I make the dialog with DialogBoxParam from a resource, without registering a certain WindowClass.

Until this time I handled the WM_SIZING message, but when I saw this post with WM_GETMINMAXINFO, I immediately changed/"corrected" my code.

I would like to ask that, why my dialog box is not flickering, if I resize it? I have 2 listview, 2 editbox and 1 button control. And it works fine. I did not put any code for handling the WM_ERASEBKGNG, EM_ENTERSIZEMOVE and EXITSIZEMOVE. It's a little bit weird.

And one more question: when is recomended to set the CS_HREDRAW and CS_VREDRAW styles in the WNDCLASSEX.style? I assume that setting these two styles contributes to the flickering of window when resizing.

Posted on 2004-04-07 14:50:56 by bszente
Hi Donkey,

I have another question: in the case of the WM_WINDOWPOSCHANGED message how can I now, if my window is sizing or just moving?

I would like to stretch my controls when the main window is resizing, that's why I would like to know in this message what is happening: sizing or moving.

Posted on 2004-04-08 09:22:11 by bszente
I don't think there's anything wrong with using WM_SIZE to react to window resize? As long as you don't use it for enforcing window dimensions.
Posted on 2004-04-08 09:36:26 by f0dder
Yes f0dder,

but this whole thread speaks about not to use the WM_SIZE and WM_MOVE messages. So I wanted to use instead of WM_SIZE the WM_WINDOWPOSCHANGED message to update the controls size and position in my dialog box.

I tought to the following solution:


mov [IsSizing],TRUE
[B]; the problem here is that I don't now explicitly if
; the dialog is sizing or moving[/B]
.elseif eax==WM_EXITSIZEMOVE
mov [IsSizing],FALSE
.if [IsSizing]
... [B]; resize common controls in dialog[/B]
.elseif ...

Any solutions?
Posted on 2004-04-08 09:59:29 by bszente
Hi bszente,

Have you tried to check the flag member of the WINDOWPOS structure, the enter/exit size move messages does not distinguish between resizing or moving. If the flags are not set you must check the cx/cy members to see if the size of the window is being changed and set the IsSizing flag based on that.
Posted on 2004-04-08 11:33:55 by donkey
Hi Donkey,

yes I tried to check the flag member of the WINDOWPOS structure, but I don't know which is the correct flag to test for. The problem is that in MSDN the WINDOWPOS structure is defined when I want to pass the structure for a winapi call, not for the case when I get the structure from system.

When you have to move/to position controls or child windows, you move them in the WM_WINDOWPOSCHANGED message? And regardless of the main window has been only moved and not resized?
Posted on 2004-04-08 12:25:43 by bszente
Posted on 2004-04-08 12:27:03 by donkey
Hi Donkey,

I tried the SWP_NOSIZE flag. In fact I tested this flag, and if this flag is set to 0 than it means the window is SIZING. Here is my solution:

mov ebx,lParam
test [ebx+WINDOWPOS.flags],SWP_NOSIZE
jnz @F
[B]; If we get here it means the window is sizing[/B]
invoke GetDlgItem,hWnd,IDC_MYIMCLIENT_SBR1 [B]; Resize the Status Bar[/B]
invoke MoveWindow,eax,0,0,0,0,TRUE
Posted on 2004-04-09 09:51:46 by bszente
Can you not kill two birds with one stone by processing the WM_WINDOWPOSCHANGING message? You can limit the window size there by setting the cx, cy values of the WINDOWPOS struct and handle the sizing of your window at the same time...
Posted on 2004-07-14 10:41:02 by adamjjackson
Hi adamjjackson,

you have right, it can be done also in the way you specified. Actually it has a slight problem and difficulty when you want to resize your controls and child windows according to the changed child area: The WM_WINDOWPOSCHANGING message is sent to a window whose size, position, or place in the Z order is about to change. So inside this message you don't know what will be the new size of the window, you cannot resize your controls precisely. You also have to test for cx, cy and to set to the desired limit values, it's more complicated and you should write more code. That's why the WM_SETMINMAXINFO message exists, to handle the size limits directly without calculation, to let Windows take care of it, if they already implemented such thing.

I tried your recommendation, but I encountered the problem, wat I said above about the precise placement of the controls. They sometimes remained outside the window during the sizing, if I moved my mouse fast.

As far as I know (and if i'm not wrong) it is "healthier" and easier to use the WM_GETMINMAXINFO and WM_WINDOWSPOSCHANGED message. Also as donkey and the others said the WM_SIZE and WM_MOVE messages are not send if you process WM_WINDOWPOSCHANGED.

In fact my problem was how can I find out if my window is moving or just sizing within the WM_WINDOWPOSCHANGED or WM_WINDOWPOSCHANGING messages. If I don't test it, the window will flicker, because I redraw the controls in every case the messages appear, wich is bad. I found that testing SWP_NOSIZE is working well.
Posted on 2004-07-14 12:26:42 by bszente
I stand corrected. I've just encountered the problem that you described - It was just a thought and I hadn't tested it thoroughly before I posted - I just came back to correct myself!

However, I came across this because I found that WM_GETMINMAXINFO is not sent to child windows. So a child control will have to process the WM_WINDOWPOSCHANGING message to limit its window size :)
Posted on 2004-07-14 15:28:04 by adamjjackson
2 Donkey

It seems to me that exactly this way was used
in The Customiser by Wanga International
for very nice drag'n'drop and resizing...
Posted on 2004-07-14 23:05:04 by kero
Hi Kero,

It is the best and most efficient way to handle resizing so I am not surprised to find it in commercial packages. I haven't heard of the software but a quick look at the webpage and it seems to be useful though for us asm guys who deal with api and message hooks, process memory and such on a daily basis, probably a simple thing to do, at least I found nothing that I couldn't think of a way to acheive the same results.

BTW I fixed the problem you found with my desktop listview demo, the version on my site was one I was testing and got uploaded by mistake. The fix is done and uploaded, forgot to set LVS_SHAREDIMAGELISTS.
Posted on 2004-07-15 00:17:42 by donkey