Forum

I have an MDI program with an inner dialog bar in my view frame.  From the view, I’m trying to set the text in an edit control in the dialog bar.



The code in the view is



    CChildStdTrace *pFrame = (CChildStdTrace *)GetParentFrame();

    ... code to set CString szTmp ...

    pFrame->m_DlgBarStdTrace.m_EdtHorz.SetWindowText(szTmp);



When this is called, I get a break in winocc.cpp because m_pCtrlSite is NULL.  m_hWnd exists.



void CWnd::SetWindowText(LPCTSTR lpszString)

{

    ENSURE(this);

    ENSURE(::IsWindow(m_hWnd) || (m_pCtrlSite != NULL));



    if (m_pCtrlSite == NULL)

        ::SetWindowText(m_hWnd, lpszString);

    else

        m_pCtrlSite->SetWindowText(lpszString);

}



The dialog bar draws fine.  I can interract with the control in the dialog bar.  The dialog bar and the control on the dialog bar is visible before the code in the view is called.  I experimented writing to this control in the OnInitDialog for the dialog bar and it works there.



When the program breaks on the above ENSURE test, I can hit run and the program contrinues, but comes up with a message box in the program that says:



"An invalid argument was encountered."



I didn’t create this message box, I’m not sure if it is in Prof-UIS or the MFC library code somewhere.



I can’t seem ot find any information on what m_pCtrlSite is and where it is supposed to be set.  Why is this having problems?



Bill

I wrote an update the next day, but it doesn’t appear to have posted.  I must have been tired when I ran into the problem because I misread the code.  I thought the test was m_pCtrlSite == NULL instead of m_pCtrlSite != NULL. 

The problem was with the m_hWnd, but it wasn’t a straight forward problem.  On call to SetWindowText, m_hWnd was a valid value, but it was corrupted within SetWindowText.  I finally solved the problem by putting #pragma pack(1) into the header file for the class.  In some places data item addresses were getting shifted three bytes.  My best guess is that a byte or bool declared in my class was in some places being treated as a byte wide and in other places being treated as 4 bytes wide, which shifted the address locations of everything else by three bytes in some situations. 

Ultimately I think there is a bug in the underlying Windows/MFC classes somewhere.  This should not happen, but the #pragma pack(1) seems to solved the problem where ever I’ve run into it.

Bill

We guess the m_pCtrlSite is not to do with the problem. Please check the m_hWnd property of the pFrame->m_DlgBarStdTrace.m_EdtHorz object before invoking its SetWindowText() method.