Prev: SqlConnect and ODBC on 64-bit Systems
Next: CMultiDocTemplate and RUNTIME_CLASS.
From: Woody on 1 Feb 2010 17:04
I have a model dialog, F. F has a modeless dialog, A, which is
intended to show on top of F (user drags A to different locations of
F).

When F is instantiated by its parent dialog using DoModal, it creates
the modeless dialog A:

A.Create(IDD_A,this);

I attempted to position A using code in F. Guide2 is a static control
in F at the desired initial position of A:

CRect r;
A.GetWindowRect(&r); // to get the dimensions of A,
needed for MoveWindow
int w=r.Width(),h=r.Height();
CStatic *pStatic;
pStatic=(CStatic *)GetDlgItem(IDC_Guide2); // get the desired
position for A
pStatic->GetWindowRect(&r);
A.MoveWindow(r.left,r.top,w,h,TRUE/*repaint*/);
A.ShowWindow(SW_SHOW);

This code repositions the modeless dialog A, but not at the correct
spot.

The documentation for MoveWindow says that the coordinates are client
wrt the parent, but screen if A is a "top-level window". Although A
was created with F as a parent, Spy++ and GetParent both indicate that
it has no parent.

I tried converting the guide coordinates from screen to client, in
case MoveWindow was using client coords of F; this didn't work either.

How can I reposition the modeless dialog A at a known position with
respect to modal dialog F, its creator?
From: Woody on 1 Feb 2010 23:25
On Feb 1, 6:59 pm, Joseph M. Newcomer <newco...(a)flounder.com> wrote:
>The variable A is declared somewhere, and has a type.

A is a type, a dialog derived from CDialog. In simplifying the code
for the question, I confounded the type A, and the instance, a. In the
"parent" dialog F, there is a declaration

A a;

and in the remainder of the code I showed, "A" should be "a".

> Because A is a modeless dialog, I would add handlers to override the default OK and Cancel
> events:

Not using either of these, although I may have to provide for user's
typing Esc.

> You have shown none of this, nor have you indicated that any of it has been done.

It's true, I didn't show all my code. It does work, though, except for
the positioning.

> Never declare more than one variable on a line.  NEVER initialize more than one variable
> on a line.  ALWAYS put a space after a comma when one appears in a separator context.

These are your opinions, and as I have said before, I don't agree.

> The problem here is that you are using the wrong coordinates.  If you want to position a
> window, you must give its coordinates in parent client coordinates.  Since F, the class
> you are in, is the parent of the window, you must express the desired position of A in
> terms of the F client system.  So you have to do
>
>         ScreenToClient(&r);
> This converts the screen coordinates of GetWindowRect to the client coordinates of F.

Finally, we get to the point. It is undoubtedly a question of
coordinates, but not just screen to client. As I said, I did try this,
and it positions the window incorrectly.

> This presumes your modeless dialog is done as a popup, by the way, and you have said
> nothing about how this window is managed.  It would probably make more sense to create the
> dialog as a child window.

The modeless dialog has the following styles (as shown by Spy++):
WS_CAPTION, WS_VISIBLE, WS_CLIPSIBLINGS, WS_OVERLAPPED, DS_3DLOOK,
DS_FIXEDSYS, DS_SETFONT, WS_EX_ LEFT, WS_EX_LTRREADING,
WS_EX_RIGHTSCROLLBAR, WS_EX_TOOLWINDOW, WS_EX_WINDOWEDGE,
WS_EX_CONTROLPARENT, WS_EX_STATICEDGE. Spy++ shows its parent as
(none), although the dialog F was specified in the Create call.

> Actually, it should probably be a child window.

It was created using VS2005 dialog editor. I left the style choice as
"overlapped" (the default), but I can try "child".

The issue may be complicated by the fact that I'm testing this on the
primary monitor of a dual-monitor system.

> Note also that unless the dialog is a child (not a popup), when you move the parent
> dialog, the modeless dialog window will stay where it was, unless you also implement
> MoveWindow to move it.  And if you resize the window to cover some of the controls, the
> modeless dialog will still appear on top of the window; it will not be clipped by the
> parent window.

These properties are OK, but I do want to get the coords correct, so I
will try the "child" approach. 

> So what do you intend here?

In MS Word 97, the Find dialog's behavior is what I'm after. It
behaves as a window which remains on top of the main window, can be
moved anywhere.

> But much of the code I see is deeply suspect.

We are all deeply suspect.
From: Woody on 1 Feb 2010 23:30
Follow-up:

I changed the style of the modeless dialog from Overlapped to Child,
re-instated the screen-to-client conversion, and now MoveWindow works
as expected. Problem solved.
From: Tom Serface on 2 Feb 2010 02:19
Glad you got it to work. One thing I always do with modeless dialogs is
make the button that pops them up (from the parent) check to see if they are
already popped up and may have just slipped behind some other window (like
the parent). If that happens I just pop it to the front again using
SetForegroundWindow().

That way the dialog doesn't ever really get lost.

Tom

"Woody" <ols6000(a)sbcglobal.net> wrote in message
news:911d99c9-b52c-4e8f-97d5-c234259c53bb(a)p13g2000pre.googlegroups.com...
> Follow-up:
>
> I changed the style of the modeless dialog from Overlapped to Child,
> re-instated the screen-to-client conversion, and now MoveWindow works
> as expected. Problem solved.

From: Woody on 2 Feb 2010 04:04
I spoke too soon. Making the modeless dialog a child window works fine
wrt the coordinates, but the modeless gets clipped by the parent,
which I can't allow. So I'm back to figuring out the coord
transformation.

So far, I have discovered that neither GetParent nor GetOwner in the
"parent" dialog returns a non-null value, although Spy says the parent
F has an owner. Apparently there is more than one definition of
"owner", because ::GetOwner returns the correct window handle.

It looks like the coordinates for move window are relative to the
client area of another dialog, P, which is the owner of F. Now I need
to solve the problem of how to get the window coords of the client
area of a window. The only thing I have found so far on this topic is
WM_NCCALCSIZE, which may or may not get what I want (I haven't
finished researching this yet).
 |  Next  |  Last
Pages: 1 2
Prev: SqlConnect and ODBC on 64-bit Systems
Next: CMultiDocTemplate and RUNTIME_CLASS.