Child dlg can only move w/in parent client region.. help!

[jiac]

Hello all,

I have a MFC that I have a parent dlg and 2 child dlgs. I have 1 parent dlg with 2 child windows instead of just having 2 pop-up dlgs is because for data communication.

Here is the obsticle: I have overriden the OnMoving() in the child window class so that there is some mouse dragging/moving possible for the child window with
GetParent()->MoveWindow(pRect);

However, this moving is bounded by the client area of the child window that it can only move inside the parent window.

Ok. I am very stuck.

1. I don't ever show the parent dlg but only needs it for handling the messages. i.e. OnTimer() it calls the child windows.

2. How can I break this "boundary"? I noticed the boundary got re-defined after I let go of the mouse.

3. Speaking for the designing purposes, if I were to use 2 threads for each child window, and make them a pop-up instead and get rid of the parent dlg, how can I have the 2 child windows talk to each other?
Would thread be a better approach?

I am on this for 3 days now... please help me.

Jiac

[jiac]

While still clueless on this topic, I thought I would make it more graphic in terms of why I am stuck.

 

||=======================||
||    (but it can only reach this location)                                          
||~~~~~~~~~~~~~~~~~~~~~~~||                
||                       ||                                       
||=======================|| 
|    (try to move up this window)                                          
+~~~~~~~~~~~~~~~~~~~~~~~~~+

the single ~ denotes where the child window is, and it is limted to where it can be moved to, i.e. the double line, unless the mouse is let go and then the bounardy is reset, but noneless still with the same refinement. The double line rect can't go anywhere on the screen.

Thanks,
Jiac

[gstercken]

However, this moving is bounded by the client area of the child window that it can only move inside the parent window.

Well, that's exactly the way child windows behave - by design. Maybe yoú intended to use owned windows instead of child windows?

3. Speaking for the designing purposes, if I were to use 2 threads for each child window, and make them a pop-up instead and get rid of the parent dlg, how can I have the 2 child windows talk to each other?
Would thread be a better approach?

Communication between the windows is completely unrelated to their parent/child relationship. There's no need to make two windows child windows of a common parent just to have the "talk" to each other. I don't know what exactly you mean by "talking", but the windows can send messages to each other by simply knowing the other window's HWND, or the related CWnd class instances can call methods on each other if you give them references or pointers to the other window's CWnd instance.

[jiac]

Hello gstercken et all,
Thank you for the reply. Yes, my intend of having a parent was so that
some of the code can be re-used, i.e. the menu items and their associated actions and I thought that makes toggling between the child windows easier.

I want to bring up the menu when any child window received a mouse-up signal. This menu is the same for both windows.
Currently I have tried to have the menu code in Child_1 class, and if Child_2 receives the mouse up msg, it would call Child_1's OnNcRButtonUp(), however, the problem, as you already know, is probably b/c Child_1 's h_wnd is not valid so I can't bring up the menu?

perhaps this is not right with putting "this"?
nCommand = m_subMenu->TrackPopupMenu(TPM_LEFTALIGN |TPM_RIGHTBUTTON | TPM_RETURNCMD, point.x, point.y, this);

2. The way I do the toggling bewteen Child_1 and Child_2 was that when a botton is clicked, then I EndDialog() the receiving child window and DoModal() the other way. Can you comment on this approach, or anyone?

Thanks alot,
Jiac

[jiac]

Hello,
I have made some progress now that I no longer care about the data transfering part, but PLEASE tell me how to create threads in my CWinApp class. I want to create 2 dialogs, each from a thread, so I can do

SHOWWINDOW(SW_HIDE) <-> (SW_NORMAL)
during toggling.

However, I have been reading about threads, there is UI and worker threads. I gather that AfxBeginThread() is safer in thread handling than CreateThread(), but I'd get assersion at afxcrit.cpp with
LeaveCriticalSection(&_afxResourceLock[nLockType]);

Pleaase.
Jiac

[kuphryn]

Check out MSDN.

Derive from CWinThread to create a UI thread. Worker thread is spawned via Win32 API including those you've mentioned.

Kuphryn