Forum

Hi,
We have code which creates the mail application window using SDK API CreateWindow(). So to port to prof-UI, I have subclassed using CExtNCW<CWnd> (Due to the code complexity, I could not use CFrameWnd). Then I have added status bar using CExtStatusControlBar() with standard indicators (CAPS, NUM, and SCROLL). The window is displayed correctly with status bar. However the keyboard status are not reflected in the status bar. Please let me know if I need to do any other initialization.

Thanks.
Do I have to inherit like CExtNCW < CExtWS<CWnd> > ? With this I am not seeing the thick frame though!.

You should recompute the window’s non-client area after subclassing. Alternatively you can change the paint manager after that.

Thanks.
If I use CFrameWnd, then status bar shows the keyboard status. But with this I have a side effect. We create a form (using CreateWindow)having the controls and I am subclasing this window using CWnd. This form is then attached to CFrameWnd. Now when I resize, the whole view flickers very badly!. Hence I went with CExtNCW<CWnd> for the main frame also. Having CExtNCW<CWnd> as main frame works fine, but the status bar does not show the key status(may be due to focus is not set correctly?). Please advice.

If in the case of a non-CFrameWnd-based window (e.g., CWnd, CDialog), please implement the following:

1) Make sure that WS_CLIPCHILDREN|WS_CLIPSIBLINGS are set for this window. These styles are essential form removing any flickering.

2) To position the status bar at the bottom, invoke CWnd::RepositionBars( 0, 0xFFFF, 0 ); both when the window is created and resized. This is the same as CFrameWnd::RecalcLayout() in frame windows. The ProfUIS_Controls sample is a dialog-based application with a status bar. So you can use it as an example.

3) You wrote you were using CExtNCW < CWnd >. This type provides a skinned non-client window area if the currently installed paint manager supports it. We guess you should also use a CExtWS template decorator class which provides a skinned window client area like in CExtResizableDialog-based windows.

Please also note that even if you use the CFrameWnd class, the main thread’s message loop should be controlled by MFC’s CWinApp-derived class and this frame window should be the main window in the thread (i.e. the CWinApp::m_pMainWnd pointer should be not NULL and point to this frame window) or, alternatively, you should pre-translate all the messages through this frame.

You can use the CFrameWnd class exactly like the CWnd class. We have described this issue in one of our previous answers. Believe or not, the keyboard state will be displayed correctly. We will be with you until the problem gone. Just some additional notes: the HWND handle can be created as it is, but without the WS_VISIBLE standard window style. Then subclass it with CFrameWnd object and remember it should be allocated dynamically using C++ new operator and it will delete itself automatically when the window handle will be destroyed. If you need non-dynamic CFrameWnd window, then you should override its PostNcDestroy() virtual method with empty body. Then you should invoke some method of your subclassed frame - this method should create menu bar, status bar and do anything else what typically the CMainFrame::OnCreate() method do.

Such approach is used in our FrameFeatures ActiveX control. It uses such phantom frame window and it successfully subclasses .NET Windows Forms popup form windows, Visual Basic 6.0 popup form windows, Microsoft Visual J++ 6.0 AWT library’s popup form windows, Internet Explorer server windows and we have reports about other ActiveX form containers were very friendly with this control. If we do this successfully, then you should have 100% chance for success in converting your application.