The MASM Forum Archive 2004 to 2012

Hi all, i have a problem on child windows paint wen i drag one over the other here are some images:

http://screensnapr.com/v/bA3Dfa.png

http://screensnapr.com/v/vaOpTG.png


this append wen i drag the down window...

some help will be very nice...

best regards

5k3l3t0r

Any code?
Maybe it is something trivial like missing DefMDIChildProc()?

hi, tkx for fast reply.

this isn't mdi, the darkest rect is a child window created just for host dialogs

here is how the dialogs are created:

invoke CreateDialogParam,hInstance,1100,hWnd,addr TestWindowProc,NULL
invoke CreateDialogParam,hInstance,1100,hWnd,addr TestWindowProc2,NULL

and here is the dialog funcs

TestWindowProc proc hWnd:HWND,uMsg:UINT,wParam:WPARAM,lParam:LPARAM

.if uMsg == WM_INITDIALOG

.elseif uMsg == WM_LBUTTONDOWN
.elseif uMsg == WM_COMMAND
.elseif uMsg == WM_MOUSEMOVE
invoke BringWindowToTop,hWnd
invoke UpdateWindow,hWnd
invoke RTLogMessage,s("Updated"),TRUE
.elseif uMsg==WM_MOVE
invoke BringWindowToTop,hWnd
invoke RTLogMessage,s("Updated"),TRUE
.elseif uMsg == WM_CLOSE
invoke EndDialog,hWnd,0
.else
mov eax,FALSE
ret
.endif
mov eax,TRUE
ret
TestWindowProc endp

TestWindowProc2 proc hWnd:HWND,uMsg:UINT,wParam:WPARAM,lParam:LPARAM

.if uMsg == WM_INITDIALOG
.elseif uMsg == WM_LBUTTONDOWN

.elseif uMsg == WM_COMMAND
.elseif uMsg == WM_MOUSEMOVE
invoke BringWindowToTop,hWnd
invoke UpdateWindow,hWnd
invoke RTLogMessage,s("Updated"),TRUE
.elseif uMsg==WM_MOVE
invoke BringWindowToTop,hWnd
invoke RTLogMessage,s("Updated"),TRUE
.elseif uMsg == WM_CLOSE
invoke EndDialog,hWnd,0
.else
mov eax,FALSE
ret
.endif
mov eax,TRUE
ret
TestWindowProc2 endp


i have tried a lot of things but nothing (as you have said maybe something trivial...)

tkx

5k3l3t0r

These BringWindowToTop's seems to be not correct ...  the common way to force redrawing of a window or control, is to invalidate its client area using InvalidateRect(hWnd,0,TRUE).

hi have changed the code:

.elseif uMsg==WM_MOVE
invoke InvalidateRect,hWnd,0,TRUE
invoke UpdateWindow,hWnd


but stays the same...

something with the style of the child windows?


IDD_LOG DIALOGEX 253,40,346,50
FONT 9,"Trebuchet MS",400,0,0
STYLE 0x50C80004
EXSTYLE 0x00000188
BEGIN
  CONTROL "",IDC_LSVLOG,"SysListView32",0x50010003,0,4,346,46,0x00000200
END


or the parent

IDD_DLG1 DIALOGEX 10,10,297,172
FONT 8,"MS Sans Serif",0,0,0
STYLE 0x56000000
BEGIN
END


?????

tkx

5k3l3t0r

you shouldn't have to do anything like that for WM_MOVE
when you drag a window, it becomes the foreground window and gets keyboard focus

for WM_MOUSEMOVE...
you will drive that thing nuts in processor time if you do that - lol
WM_MOUSEMOVE happens hundreds of times when you move the mouse across a window
so - use SetForegroundWindow, and set a flag
test the flag so you only have to do it once
to keep track of the mouse leaving, use SetCapture
when the mouse is outside the window, use ReleaseCapture
then, respond by clearing the flag in WM_CAPTURECHANGED

could you show use the resource template for 1100 ?

hi.
this is the resource(the name IDD_LOG just come from some experiments):

IDD_LOG DIALOGEX 253,40,346,50
FONT 9,"Trebuchet MS",400,0,0
STYLE 0x50C80004
EXSTYLE 0x00000188
BEGIN
  CONTROL "",IDC_LSVLOG,"SysListView32",0x50010003,0,4,346,46,0x00000200
END


tkx
5k3l3t0r

sorry - i see it was in the previous post   :P

hi,
it seems that the problem is that the child window never become active, even wen dragged around.(the caption bar never changes his state, and the window don't come to top)

i have tried to call SetActiveWindow, but without results...

is there a way to force a child window to become active?

tkx in advance

5k3l3t0r

IDD_DLG1 DIALOGEX 10,10,297,172
FONT 8,"MS Sans Serif",0,0,0
STYLE 0x56000000
BEGIN
END

this is the template for the parent ???
you have the WS_CHILD bit set   :P

i am just trying to get the thing to display - lol
it might be easier if you would post a complete program

not to worry - i will get there   :bg

hi...

here is the full project(radasm3)

https://www.box.com/s/68caba58160304a683e7


tkx
5k3l3t0r

that helps a lot   :bg

the template you posted above as the parent is for the log window - lol

at any rate.....

you are using CreateDialogParam, creating 2 modeless dialog boxes as child windows
these require a message loop - and a little bit special, if you want it to handle certain keyboard stuff, as it requires IsDialogMessage

as a parent, you have a modal dialog, which requires no message loop
i am not sure there is a way to use that specific window hierarchy  :red

but - the solutions seem easy enough
you could create a modeless dialog as the parent, followed by a message loop, something like this...
    LOCAL   msg:MSG

;--------------------------

;
;other code
;

    .while TRUE
        INVOKE  GetMessage,addr msg,edi,edi,edi
        .break .if !eax
        INVOKE  IsDialogMessage,hWin,addr msg
        .if eax==FALSE
            INVOKE  TranslateMessage,addr msg
            INVOKE  DispatchMessage,addr msg
        .endif
    .endw

    INVOKE  ExitProcess,msg.wParam
normally, a message loop handles messages for all windows in a process
that may not work so well, in this case, as IsDialogMessage is window-specific
although, you could probably make a loop with a call to IsDialogMessage for each modeless dialog

or - you could create modal dialogs as children - probably the easy way

the problems you are having are caused by the fact that no messages are being dispatched for the child windows

personally, i would not use dialogs at all - lol
i like to use CreateWindowEx for everything

hi,
tkx for the explanation, but i don't understand very well... ;(

can you make a simple example with a main window and two childs windows, so i can study the code and try to understand how things work? or give a link with some working code.

tkx in advance

5k3l3t0r

i will post a couple examples, shortly

there are different ways to go
one way would be an MDI window - a bit tricky - lol

another way would be to use the same class/WndProc for both children
another way would be to use seperate class/WndProc's for each child
it depends on the desired functionality of the children
if they are to behave the same, or nearly the same, it might be best to use the same class/WndProc for both

Activating the WS_CLIPSIBLINGS-Style for the IDD_LOG-Window solves the problem.

that is interesting, qWord

but - i do not understand how the modeless dialog messages are handled

also - i see that WS_CLIPSIBLINGS affects the re-paint
however, i do not understand why it should be that way   :red
it seems to me that WS_CLIPSIBLINGS should be optional - not required - lol

i am not getting what i think should be "standard behaviour" out of the child windows
when you click on a child - anywhere - it should come to the the foreground
the behaviour i am seeing is that you must click and release on the title bar before it comes to the front
i don't think we are using the right combination of style bits   :'(

yep, that's right but at least, 80% of the problem is solved...

thanks a lot.

if i get all working 100% i will post the solution here for future reference, since i have searched all over the internet and can't found a working example.

by,
5k3l3t0r

hi again,

after some testing, other strange behavior come:

http://screensnapr.com/v/HmxhNM.png

this append if you drag the child window around for a while, the complete application become crazy on the paint process

if i comment this line in the parent all seems to work correct

.elseif uMsg==WM_CTLCOLORDLG
RGB 206,206,206
invoke CreateSolidBrush,eax
ret


some workaround?

tkx in advance

5k3l3t0r

The problem is, that you are using dialogs as child controls. They look like top level windows, but behave like common child controls. These controls assumes to be not overlapped by siblings, because the are commonly not moved. The problem with the activation has probably something to do with the fact, the dialogs are designed as popup windows. The following code may helps:
.elseif uMsg == WM_NCLBUTTONDOWN
invoke SetWindowPos,hWnd,HWND_TOP,0,0,0,0,SWP_NOMOVE or SWP_NOSIZE
invoke InvalidateRect,hWnd,0,TRUE
invoke UpdateWindow,hWnd
xor eax,eax
ret
.elseif uMsg == WM_LBUTTONDOWN
invoke SetWindowPos,hWnd,HWND_TOP,0,0,0,0,SWP_NOMOVE or SWP_NOSIZE
(Also remove the TOPMOST-style from the dialog)

Quote from: 5k3l3t0r on May 17, 2012, 02:08:33 PM
this append if you drag the child window around for a while, the complete application become crazy on the paint process
...
some workaround?

You are producing a handle leak: create a global variable  (or better use a property) and store the brush in it when initializing the dialog. Pass this handle while handling the mesage.

well - i have played with this - lol
trying to figure out how to correctly create child windows - something i thought i had already figured out
apparently, i did not have it figured out   :bg

i have looked at:
class styles of both parent and child
extended styles of both parent and child
window styles of both parent and child
and - WndProc's of both parent and child

the answer has to be in there someplace, but still eludes me  :(
there are a seemingly enormous number of combinations to try

another thing i did was - i looked at my little MDI window program
it exhibits the behaviour that we are after
nothing special in the style bits, really
which leads me to consider the default handling of messages in the parent and child WndProc's
this is one place where MDI windows vary greatly from normal modeless windows
the parent window proc uses DefFrameProc instead of DefWindowProc
and the MDI child window proc's use DefMDIChildProc instead of DefWindowProc

another big difference of MDI windows (there are many),
is that there is a 3-tier hierarchy of windows - not just the 2 tiers that we have been trying
i.e., there is a frame window, a client window, then there are the child windows
you have to provide the WndProc's for the frame and the children
but the WndProc for the client is provided by the system
so - you don't really see what is going on, there   :P

in other programs i have written, i often wind up doing something similar
i create windows and controls to fill the client area - never really working directly with the client, itself
i have done this to reduce flicker and to reduce CPU usage in WM_PAINT - things like that
it's also easier to position and size all the controls together during WM_SIZE if you don't deal directly with the client
sometimes, i can use NULL_BRUSH as the client background, because it is covered by other windows   :P
if i have scroll bars, though, i use COLOR_SCROLLBAR as the client background

so - i am going to play with a 3-tier hierarchy for a little while
and - if i get tired of that, i will re-write my MDI program so that others may read it - lol

here is a simple MDI window example
i cleaned it up so everyone else can read it - lol
i even used IF/ELSE/ENDIF and indentation, both of which i hate   :P

this one handles the menu correctly - i even provide keyboard accelerators for most menu items

a special version that creates 2 MDI child windows and a "log" window as skeletor wants should be an easy mod

hi,
tkx for the example, i will use it for future ref, since in this project i don't want the mdi features like menu merge etc, but is an interesting peace of code...

tkx all

5k3l3t0r     

it is easy to remove the menu features and add a second window
i hope you tried "File menu - New" a few times - then played with the child windows
they behave like they ought to - you click on one anywhere, and it comes to the front

to remove the child list from the menu, just eliminate this code...
        ; ----------- Initialize client create structure -----------

        ;we need a handle to the menu where the client will update the child list

        INVOKE  GetMenu,ebx
        mov     hMenu,eax
        INVOKE  GetSubMenu,eax,edi
        mov     edx,offset ccs
        mov     [edx].CLIENTCREATESTRUCT.hWindowMenu,eax
that will leave the ccs.hWindowMenu member set to 0, and there will be no child list
it is important that the CLIENTCREATESTRUCT has the ID of the first child, however
so, leave this part intact...
;-----------------------------------------

;Client Create Structure

ccs CLIENTCREATESTRUCT <?,IDW_FIRSTCHILD>
the last parameter in CreateWindowEx must be a pointer to the CLIENTCREATESTRUCT structure
        INVOKE  CreateWindowEx,edi,offset szClientClass,edi,
                WS_CHILD or WS_VISIBLE or WS_CLIPCHILDREN,
                edi,edi,edi,edi,ebx,edi,esi,offset ccs
and - you could change the "?" to "0"

to create a second child window...
; ----------- Create the first child "automatically" -----------

;the child window count is already initialized to 1

    INVOKE  SendMessage,esi,WM_MDICREATE,edi,offset mcs
just execute that SendMessage call a second time
you can also eliminate the code that keeps count in nChildCount

to prevent it from making new windows, eliminate the File - New code
making an MDI window not work completely is easy - lol

one more item....
the MDI frame window does not need to be the main application window
it can be a child of the main window

the window hierarchy used in my example looks like this...
frame window (main app)
    MDI client window
        MDI child
        MDI child
        MDI child....

the window hierarchy you may want to use looks something like this...
main app window
    MDI frame window
        MDI client window
            MDI child
            MDI child
    log window
in WM_SIZE, you only need to size the MDI frame window and the log window
the MDI client window sizes itself to fill the MDI frame window client area

yep, i have understand the mdi features (i use a lot in c#), but here isn't suitable since all dialogs (except  the main and the log) come from Dll's coded by others and can't be maximized because the layout, sow that gray part (actually a dialog to serve as parent) in my window is to serve as parent for all dialogs that come from plugins (maybe sounds a bit strange) but wen i have finished all i can post here a copy, or send a copy to you since i don't know if this type of software is welcome in the forum.

by,
5k3l3t0r

oh - i did not realize what you were making
no - that isn't allowed, here