My program's main window is a modeless dialog, upon which
child dialogs can be opened. A child can be moved to a
new position by dragging its title bar, as usual. But if
that child is closed and later opened again, it will be
back in the original position. How do I make it remember
the new position?

If I have to do this all myself, I assume I first need to be
notified when the position has changed. How? The best
I have come up with, by monitoring message traffic, would
be to trap the first WM_NCMOUSEMOVE after a
WM_NCLBUTTONDOWN with HTCAPTION set.

Then, I assume I must get the current position with
GetWindowPlacement or GetWindowRect or something. But
when would I call SetWindowPos or whatever... when the
child is later opened? This seems cumbersome, and since
this is a standard Windows operation I hope there is a
better way.

Also, if a child dialog opens a child of its own, I'd
like to be able to drag both together as a unit, without
changing their relative positions. My best guess on this
is that I would wait for the move to complete on one of
the dialogs (as above), and then quickly move the other
to the proper location. This would seem to involve the
same sort of position determination as above, with the
added issue of getting the proper offset between dialogs.

I thought this could be done by simply posting copies
of WM_NCLBUTTONDOWN and the subsequent WM_NCMOUSEMOVE
to the second dialog, but I can't get that to work.
It _sorta_ works, in that when you move the dotted
rectangle for the first dialog and release, that dialog
is moved and the dotted rectangle pops to the proper
new location for the second dialog. But I have to
manually click and release a second time in the same
location to get the second dialog to move there. I
haven't found any message to do this automatically.

Any ideas for a simpler approach to these tasks?

Many thanks!





Bob Masta
dqatechATdaqartaDOTcom

D A Q A R T A
Data AcQuisition And Real-Time Analysis
www.daqarta.com

Bob Masta wrote:
You can save the child's position in its WM_DESTROY handler and restore
it in WM_CREATE.

When you receive WM_ENTERSIZEMOVE, make a note of the top-left corner of
the dialog you're moving. Then, on each subsequent WM_MOVING (and on the
final WM_EXITSIZEMOVE), calculate the distance and move the other
dialogs accordingly.

On Sat, 11 Oct 2003 14:21:20 GMT, StopSpam@EveryChance.org (Bob
Masta) wrote:
When you create a child window, you specify its coordinates. Use
the coordinates you saved from when the window was last closed.

SetWindowPos.

On Sat, 11 Oct 2003 21:41:42 +0300, "Elias Fotinis"
<efotinisNO@SPAMpat.forthnet.gr> wrote:

Thanks! It looks like my main problem was that I wasn't
seeing the messages you mentioned. For development
purposes, I was logging all messages that came through
the main GetMessage loop, but not the child dialog procs,
because I apparently misunderstood the GetMessage doc:

"The GetMessage function only retrieves messages
associated with the window identified by the hWnd
parameter or any of its children as specified by the
IsChild function, and within the range of message values
given by the wMsgFilterMin and wMsgFilterMax parameters."

I never bothered with IsChild since I was _certain_ of
the child's paternity. (Hmm, guess you can't be certain
without a test...) I still haven't tested with IsChild,
but the messages are certainly coming through to the
child without passing through GetMessage. I don't know
what this is all about; maybe modeless children aren't
recognized? Maybe because the parent window is a
modeless dialog it can't recognize any children?
Is there deep social significance here? ;-)

Anyway, thanks again!





Bob Masta
dqatechATdaqartaDOTcom

D A Q A R T A
Data AcQuisition And Real-Time Analysis
www.daqarta.com

Bob Masta wrote:
The children mentioned in the help are the controls, i.e. those windows
with the WS_CHILD style that are drawn *inside* the main dialog. On the
other hand, the dialog boxes you're talking about are not really
children; the are *owned* by the main dialog.

IsChild will return false in this case, because the other dialogs are
not inside the main one.

That's because you're using GetMessage with a non-zero HWND parameter.
If you use 0 then you'll get all the messages, including those from
the other dialogs. Usually, you should not specify a HWND in the
GetMessage of an application's msg loop.

Actually, yes )) You should check out "Win32 Window Hierarchy and
Styles" by Kyle Marsh in MSDN help. It explains the
parent/child/owner/owned relationships and much more.

StopSpam@EveryChance.org (Bob Masta) wrote:


unfaithful HWNDs, whatever next?

--
Lucian