Child window not appearing at first

[jj2007]

I'm trying to learn those rules, not just copy other people's examples blindly.

Learning is good, not following blindly the others, too, but be ready to accept that certain standards have emerged after a lot of trial and error done by many, many very experienced coders. Transparency and maintenance, for example, are aspects that you learn to appreciate after a while...

If you want to learn, use the structure below for a simple window, and then step through it using Olly.

Code Select Expand

WndProc proc uses esi edi ebx hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM
LOCAL rc:RECT, xyz
SWITCH uMsg
CASE WM_DESTROY
invoke PostQuitMessage, NULL

CASE WM_CREATE
... create menus and children ...

CASE WM_COMMAND ; react here to menus and controls
movzx eax, word ptr wParam ; the Ids are in the lowword of wParam
switch eax
case IdButton1
call Button1proc
case IdEdit
call Editproc
endsw

CASE WM_SIZE
invoke GetClientRect, hWnd, addr rc
... ; resize controls

CASE WM_PAINT
call WmPaintHandlerIfAny
ENDSW
invoke DefWindowProc, hWnd, uMsg, wParam, lParam
ret
WndProc endp


By the way: I found the problem with your code using MasmBasic's deb macro in console mode. With the right tools, bug chasing is much easier.

   SUB   EDX, gpRect.bottom
; Use size to create child window:
   deb 4, "Size", gpRect.bottom, gpRect2.bottom, gpRect2.right, edx   ; OPT_Susy console
   INVOKE   CreateWindowEx, 0, ADDR ChildClassName, NULL,
      $childWinAttrs, 0, gpRect2.bottom, gpRect2.right, EDX,
      MainWinHandle, NULL, hInst, NULL
Output:

Code Select Expand

Size
gpRect.bottom   34   <<< the good one
gpRect2.bottom  569  <<< the bad one ;-)
gpRect2.right   588
edx             535

[ToutEnMasm]

There's no reason you have to create things in a WM_CREATE handler, just because everyone else does it that way.

:P
Windows messages loop are the same things than the road code.
There is a stop on a road,you can ignore it,there is a crash,no surprise.
Windows give you time to perform some tasks,you can ignore them.There is a crash,no surprise.

[dedndave]

...you don't have to do everything according to the standard canonical examples. You do  have to follow certain rules
about when and how to do things, though. I'm trying to learn those rules, not just copy other people's examples blindly.

that's a good thing - i think much the same way

along the way, i have learned there are reasons some things are done certain ways
there are definate advantages, sometimes - other times, they are unnecessary

an example of the unnecessary is the INVOKE WinMain construct
it is totally a carry-over from C compilers that has no real meaning in ASM-written programs

setting things up in WM_CREATE is one of the times when there are advantages
the reasons may be somewhat obscure, however, and difficult to convey   :P

if you refer to the "Project.zip" file that i posted earlier in this thread....
you will see that the main window's WM_CREATE handler basically does 2 things
1) create the toolbar
2) create the child window

an advantage of doing it that way is that the WM_SIZE code takes care of sizing the child
in my example, you will see that i set the initial child window size and position values to 0 when it is created
a WM_SIZE message will be issued immediately following the completion of WM_CREATE
we eliminate the unnecessary step of calculating the size of the child in 2 different code sections
this is only one advantage of doing it this way - there are others

the hard part of trying something different is testing it under a seemingly infinite number of possible conditions
somewhere down the road, you will be chasing some obscure behaviour flaw
that is where you really learn the subtleties of writing windows programs   :bg
they can't always be explained in plain-text - you just have to experience them
play with it - try it both ways and see which you like best   :U

[NoCforMe]

Well, thanks to all (especially jj). Everything's working nicely now; I can paint & draw in the child window, it appears instantly, resizes correctly, toolbar & tooltips work correctly, and custom cursors get selected properly.

One little tiny problem (isn't there always?). When the program first starts, I get an hourglass cursor in the child window, which goes away when I click on something or resize the window.

I checked the program's CPU usage (using Task Manager), and it's not using anything (shows as 0%). Not a huge deal, but obviously something's not right.

What are the places I should be looking for this problem? Is there a message I'm not responding to that I should? I'm handling WM_CREATE, WM_COMMAND, WM_NOTIFY and WM_SIZE in the parent, and WM_PAINT, WM_SETCURSOR, and WM_LBUTTONDOWN in the child (so far; just getting started).

[dedndave]

the last code that you posted does not exhibit the problem
maybe you can use that fact to help troubleshoot it

the hourglass is controllable in the startup options when your process is created
i have a similar issue with a program that calls CreateProcess
you can view some related reading in the STARTUPINFO structure documentation and here...
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682015%28v=vs.85%29.aspx

of course, you do not create your own processes - it's likely to be done by windows explorer
i would suspect an issue in the main process, somewhere between CreateWindowEx and the message loop   :P

or - perhaps you are not returning the correct value in EAX in one of the WndProc message handlers