Forum

I am integrating ProfUIS into an exisiting MFC application. Now I have encountered a problem with the CExtEdit: The text disapears when I enter the control with the mouse. When I move the mouse very fast onto the control the text does not disapear.

I am creating the CExtEdit window at runtime using the CreateEx method, not using resources. The parent window in which the control is displayed is either based on a CMDIChildWnd or on a CExtResizableDialog.

The effect of disapearing text only happens when I have the scrollbars enabled (using the WS_HSCROLL | WS_VSCROLL style). I was not able to reproduce this behaviour in a standalone dialog based sample.

Do you have any hints how this could happen?

Any comment is welcome.

Thanks.

Torsten

The Date & Time and Date Browser dialog pages in the ProfUIS_Controls sample application have scrollable multi line editor windows at the bottom of dialog page windows. The Date & Time dialog page uses a simple editor common control. The Date Browser dialog page uses a rich edit control. Please compare the styles of these editors with your multiline editor styles. There must be a way to reproduce the problem using the ProfUIS_Controls sample application and it’s hardly possible this problem is related to the MDI interface.

Thanks for your information. I tried to add the recommended styles, but it did not help. I have found a workaround: when I overwrite the OnMouseMove() method in my CExtEdit derived class and do nothing there (which avoids the base class’s OnMouseMove() method to be called) the text does not disappear.

To understand the phenomena a bit more, I added a call to CExtEdit::OnMouseMove() and the text disappeared again when entering the control’s client area. By the way: if I just put the mouse cursor on the control’s scrollbars, the text stays visible. When I debug into the CExtEdit::OnMouseMove() I get to CWnd::OnActivate() which calls CWnd::Default() where DefWindowProc() is called with the last message. This last message is usually 512 (WM_MOUSEMOVE) but also has been 133 (WM_NCPAINT). Do you have any idea why this could cause the described behaviour?

I would really like to know the reason although the problem seems to be fixed in the first step.

Please check the following:

- The parent window of the edit control should have the WS_CLIPCHILDREN|WS_CLIPSIBLINGS styles.

- If the parent window has any child controls like a group box and a static frame, the Z-order such controls should be greater than the Z-order of any other control including any editor created at run-time.