Yep, 272, the value returned from GetRectClient() does correctly account for the scrollbar's presence/absence. Why other people are using GetSystemMetrics(SM_CYBORDER) along with GetSystemMetrics(SM_CYHSCROLL)is beyond me. Using dc.FillSolidRect was a good suggestion and helped me to determine what was going on. Thanks again.

Okay, great. I appreciate your responses. I'll do the FillRect thing and do some testing. Thanks again!

Thanks for the response, I appreciate it. The question is really this. When people/you/me account for scrollbars, do we also need to account for the border of the scrollbar with GetSystemMetrics(SM_CYBORDER)? The border I think you were talking about is the border of the client window which I realize I don't need to subtract. (::GetSystemMetrics(SM_CYHSCROLL) Does this include the entire scrollbar (bar + borders of scrollbar)? It appears to. It's just that I saw some code in which the programmer subtracted the border (GetSystemMetrics(SM_CYBORDER))in addition to the scrollbar and so I'm wondering why they did it. Thanks again.

Do I need to incorporate SM_CYBORDER to catch the border of the horizontal scrollbar or is this value inclusive in SM_CYHSCROLL? Here is why I am asking I have a window that I need to know the client height if a scrollbar is present. (horiz scrollbar is not set yet) GetClientRect returns 292. Using ::GetSystemMetrics(SM_CYHSCROLL) + ::GetSystemMetrics(SM_CYBORDER) returns 21. Therefore, the window will have a client height of 271 when this window gets a scrollbar. After the horizontal scrollbar is set I use GetClientRect (which should return 271) It returns 272. Do I need to incorporate SM_CYBORDER to catch the border of the horizontal scrollbar or is this value inclusive in SM_CYHSCROLL? GetClientRect is off by one pixel when scrollbar is present MSDN says SM_CYBORDER = Width and height, in pixels, of a window border. But it doesn't say whether this is already included in the SM_CYHSCROLL value. I saw some code that uses both to determine the scrollbar size so its messing with my head. That pixel may be a misunderstanding of some other factor. Thanks

Thanks, Does it matter where those recordset objects get instantiated with the new keyword (CDatabase or CFormView)?

I am writing a MDI database app using a splitter window (upper pane = parent table) (lower pane= child table) and am unsure as to the responsibilities of each class. I have it working but am always trying to better myself. I have a database object (CDatabase) I have a recordset object (CRecordset) I have a document object (CDocument) I have several views (CFormView) I have a CSplitterWnd hosting the CFormViews I realize the document holds the data. So here are my questions I have seen an example where the document holds a member variable of both the Recordset and the Database and am currently adopting this scenario. But which class is responsible for actually creating the recordset or does it matter? I currently have the document creating the database and each formview class responsible for creating the recordset of its pane. My document holds a member pointer of the recordsets created in the view Is it appropriate to use the UpdateAllViews from the CDocument class to invoke the OnUpdate of each view? Then overide the OnUpdate in the view class to run a requery and other housekeeping procedures. Normally I associate the UpdateAllViews with some sort of visual activity in the Views but with a database it's all about requerying and housekeeping. Thanks

Hi David, I did it once and my eyes kind of glazed over. So I did it again and it makes sense now. InitialUpdateFrame was being called in the code that switched the views and this then makes each view call OnInitialUpdate. Thanks

I am attempting to write a front-end database app. Using relational database design I have a parent table in a CFormView in one pane of a splitter window and a child table CFormView in another pane of the same splitter window. On the OnInitialUpdate for each of the CFormView's I create and open the recordsets. I can replace a new CFormView and (subsequent recordset) into a pane based on user selection. I notice that OnInitialUpdate fires for each pane of the window regardless of whether or not the pane is being replaced. Creating some problems as I was expecting the OnInitialUpdate to only fire once. To test this again before I posted this question, I opened up a Splitter Window example from a book (MFC Answer Book) and put some trace statements in the OnInitialUpdate event for each of the CFormViews. It appears that if a window has 3 panes, all 3 panes get the OnInitialUpdate to fire even when only one is being replaced. Question: Is this normal behavior? Thanks.

Thanks for your patience and thoughtful comments. Jay

Thanks for being so patient. Yep It works, it was case sensitive. I see where the WM_CLOSE message is being posted. I can keep pressing F11 and trace into the functions where finally the DefWindowProc shows up. Then I can go to the call stack and see all this too. I think I'm back to wondering why (according to you) I should be seeing a WM_COMMAND message instead of a WM_CLOSE message. Hey thanks you are teaching me a bunch!

Sounds neat, I wish I could get it to work. Both wparam and lparam are zero with nMsg = 16. I using Visual C++ 6.0 so maybe the watch stuff is a new edition. IDCANCEL, wm gives me an error message in the watch window. I also looked up the value of WM_COMMAND and it is 273

Yeah, its starting to make sense. But why when I hovered over the nMsg in the DefWindowProc did the message come back as 16. I know IDCANCEL is 2 #define IDOK 1 #define IDCANCEL 2 #define IDABORT 3 #define IDRETRY 4 #define IDIGNORE 5 #define IDYES 6 #define IDNO 7 #if(WINVER >= 0x0400) #define IDCLOSE 8 #define IDHELP 9 Still scratching. Oh and by the way thanks for your help.

I believe that fact that the Dialog was not getting destroyed was because the WM_CLOSE message is being overridden by CDialog and calling and IDCANCEL. That would make sense. Before I posted the question though I attempted to follow the WM_CLOSE message to see where it was going - hence the reference to CWnd::Close from Help at the top of the question. When I put a break point at the OnClose function -user clicks the x at upper right hand part of dialog(Created through ClassWizard capturing the WM_CLOSE message) I am lead to this. _AFXWIN_INLINE void CWnd::OnClose() { Default(); } Continuing I am lead to LRESULT CWnd::DefWindowProc(UINT nMsg, WPARAM wParam, LPARAM lParam) Message being passed is 16 and IDCANCEL is defined as 2 Now I'm scratching my head. Wouldn't I see an IDCANCEL call or something like that. CWnd is supposed to destroy the window Thanks

Bingo! Hey thanks, Here was where I wasn't understanding: Be aware that the default behavior for WM_CLOSE just posts a WM_COMMAND for IDCANCEL (so it'll end up calling IDCANCEL). Thanks for taking the time to write again and explaining why the window wasn't really destroyed when the WM_CLOSE was called. I'll also strongly consider your other suggestions. :)

I think you both missed my message. You have to intercept the WM_CLOSE message. If you don't you are 1. Not Destroying your window till your parent is closed. 2. Therefore you PostNcDestroy is not run until your parent is closed 3. Therefore, how does your app know that the pointer is no longer valid. You can run GetSafeWnd all day long - it still points to valid memory...cause you never bothered to delete the CWnd object...until the parent is closed. So back to my original question please.

Thanks for the responses. I do check for the NULL pointer before opening an instance. I didn't include that code because it isn't relevant. What is relevant though is the correct way to handle the WM_CLOSE message. And my curiosity was I didn't understand why the WM_CLOSE message didn't run the Destroy Window right away - only after parent was closed.

Need your thoughts and/or opinion. Question at the bottom. When user closes the modeless dialog box you can trap the WM_CLOSE message to insure proper cleanup. According to Help CWnd::OnClose The framework calls this member function as a signal that the CWnd or an application is to terminate. The default implementation calls DestroyWindow. I found two ways to approach the user who closes the modeless dialog box by clicking the x on the upper right hand corner of the window Looking at the first example below. I found out that if you don't call DestroyWindow() from your OnClose() and you don't want multiple instances of your modeless opened you will need to set the pointer to NULL here (otherwise your pointer value can't be used as a flag to prohibit other instances of your modeless dialog from being opened). PostNcDestroy apparently isn't run until the parent is destroyed. Once the parent/owner is closed then a PostNcDestroy is run for each modeless that opened - one right after another. void CDialogDerived::OnClose() { CDialog::OnClose(); m_pParent->m_pModelessDialog = NULL; } void CDialogDerived::PostNcDestroy() { CDialog::PostNcDestroy(); m_pParent->m_pModelessDialog = NULL; //in case destroy window is called from your code and OnClose is never run delete this; } Example 2. This seems like a cleaner approach as the Dialog is destroyed immediately and thus your pointer is set to NULL immediately void CDialogDerived::OnClose() { CDialog::OnClose(); DestroyWindow(); } void CDialogDerived::PostNcDestroy() { CDialog::PostNcDestroy(); m_pParent->m_pModelessDialog = NULL; delete this; } Any thoughts pro and con to either of these approaches? I'm curious why the PostNcDestroy is not run promptly with the OnClose call on the first example. Thanks!

Okay I created a dialog based app and the GetParent function works as advertised. So now we know that the problem is more likely a conceptual one. The mainApp dialog is a popup and the CDialog derived modeless dialog is also a popup. Code is exactly the same as the problem project. In the problem project example I couldn't get to work I had an MDI application that had a CFormView derived class. It was a child. That child had a button when pressed would create the CDialog derived class modeless dialog. The CDialog derived class was set as PopUp. So can't a child spawn a modeless dialog (works) and can't that dialog in turn know it's spawning entity as Parent (GetParent). I won't mention anything about child as it was demonstrated to me by David that a modeless dialog shouldn't have a child style. I agree. I think this is important because these are pretty basic concepts. Thanks for your help.

I sent the constructor of CModelessDialogHeap already. Here it is again. CModelessDialogHeap::CModelessDialogHeap(CWnd* pParent /*=NULL*/) : CDialog(CModelessDialogHeap::IDD, pParent) { //{{AFX_DATA_INIT(CModelessDialogHeap) // NOTE: the ClassWizard will add member initialization here //}}AFX_DATA_INIT m_parent=pParent; } CModelessDialogHeap is derived from CDialog. As long as the parent exists it shouldn't matter where GetParent is called. But I put a button on the dialog and attempted it while it was still active. void CModelessDialogHeap::OnButton1() { CWnd * tmpPtr = this->GetParent(); } Thanks for your help as well David.

Yes I've stepped through the code. Like I said, the parent is passed into it just fine because I can assign that pointer to a member variable. But GetParent() should do the same thing...right? Appreciate your help. Here is the code CModelessDialogHeap::CModelessDialogHeap(CWnd* pParent /*=NULL*/) : CDialog(CModelessDialogHeap::IDD, pParent) { //{{AFX_DATA_INIT(CModelessDialogHeap) // NOTE: the ClassWizard will add member initialization here //}}AFX_DATA_INIT m_parent=pParent; }