Professional UI Solutions
Site Map   /  Register
 
 

Forum

Please Log In to post a new message or reply to an existing one. If you are not registered, please register.

NOTE: Some forums may be read-only if you are not currently subscribed to our technical support services.

Forums » Prof-UIS Tech Support » EnableWindow does not invalidate grid Collapse All
Subject Author Date
Offer Har Feb 17, 2008 - 4:37 PM

Dear Support,

All built in controls, including ProfUIS controls, when calling EnableWindow invalidates the control.
For a grid control, I need to explicitly call Invalidate for this to happen.

Please explain/rectify.

Thanks,
Ron

Technical Support Feb 18, 2008 - 11:15 AM

We implemented a WM_ENABLE message handler in the CExtScrollWnd class which is the base class of all the grid windows:

1) message map entry

ON_WM_ENABLE()
2) handler method’s declaration
afx_msg void OnEnable( BOOL bEnable );


3) handler method’s implementation
void CExtScrollWnd::OnEnable( BOOL bEnable )
{
      ASSERT_VALID( this );
      if( bEnable )
            OnSwUpdateScrollBars();
      else
            OnSwEnableScrollBarCtrl( SB_BOTH, false );
      OnSwRecalcLayout( true );
      RedrawWindow(
            NULL,
            NULL,
            RDW_INVALIDATE|RDW_UPDATENOW
                  |RDW_ERASE|RDW_ERASENOW
                  |RDW_FRAME|RDW_ALLCHILDREN
            );
}


Offer Har Feb 18, 2008 - 6:01 AM

I’m not really sure how come you came to the conclusion that when you call EnableWindow you should not redraw the control - If you call EnableWindow on a combo-box for example, it automatically appears disabled, and the same goes to all other controls.

We have a function to disable a dialog by traveling over all controls in it.
This is done using GW_CHILD/GW_HWNDNEXT, getting the CWnd* and calling EnableWindow on it. It seems to work fine with all other controls, so why shouldn’t it work with the grid controls?

Technical Support Feb 18, 2008 - 4:13 AM

Most of the common controls are painted differently depending on whether the state is enabled or disabled. The same is also true for many other child windows we came across. All popup windows on the desktop look equally both for the enabled and disabled states. If you display a modal dialog over the main frame window, the frame becomes disabled while the dialog is running modally and, as a result, clicking anywhere on the frame activates the dialog. That is a convenient behavior of windows on Windows OS, which makes implementation of modal dialogs easier. If the dialog is simply created as a popup window and a descendant of the frame window without running a message loop under the CDialog::DoModal() method and if we disable the main frame window manually, then the user will not be able to detect whether the dialog or modal or not. The message loop will be controlled by the CWinApp::Run() method but the frame and dialog will behave equally unlike a modal dialog over the frame. In both cases the frame window will have exactly the same look in the disabled and enabled states. The grid windows also have equal states and that is why we do not handle the WM_ENABLE standard message in the CExtGridWnd class for repainting the grid control. Please let us know details about disabled grid windows in your projects to clarify your point of view.