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 » Bug/Problem in in-place cell control: VK_DELETE is never received in the cell. Collapse All
Subject Author Date
Offer Har Sep 17, 2008 - 10:38 AM

I have an in-place control, that implement the OnKeyDown event. I see that when I press the Delete key, the function is never called. For every other key it is called.


I debugged the grid code and found that the source of the problem is in CExtGridCell::OnInplaceControlWindowProc. In this function, for some reason you replace the VK_DELETE KeyDown with a EM_REPLACESEL message that replaces the current selection with an empty string, ExtGridWnd.cpp line 58,240:



                                if( ( g_pEditCell->GetStyle() & __EGCS_READ_ONLY ) == 0 )
                                    ::SendMessage( msg.hwnd, EM_REPLACESEL, 1, reinterpret_cast < LPARAM > ( strEmpty ) );

Please explain how to prevent this from happening, and give the Delete key back to my In-lace control.


Thanks,

Ron.


 


 


 

Technical Support Sep 23, 2008 - 5:48 AM

The in-place editor window is not a grid cell. You can handle keyboard messages sent to the in-place activated cell editor window only if you implement the CExtGridCell::OnInplaceControlWindowProc() virtual method in your grid cell class or the CExtGridWnd::OnGridCellInplaceControlWindowProc() virtual method in your grid control class. These methods are designed for this. You should override one of them. If you don’t like them, then please implement the CWnd::WindowProc() virtual method in your in-place editor control class. We have handled the VK_DELETE key explicitly because it’s often pre-translated and filtered in customer applications.


Offer Har Sep 23, 2008 - 6:20 AM

Dear Support,


I know the in-place is not a grid cell - the in-place is CWnd derived - so I should be able to have an in-place that is not a grid specific, but any kind of control I have. My generic control handles the delete key, and I am not going to change a generic control to accomodate this requirement.


Please explain how can I over-ride this behavior - I would like to understand why this happens, and how what is the reason for that.

Technical Support Sep 24, 2008 - 5:00 AM

If the problem has to do with your custom controls activated as in-place cell editors, then you should override the CWnd::WindowProc() and CWnd::PreTranslateMessage() virtual method and redirect invocations to the grid window methods:

virtual LRESULT WindowProc( UINT message, WPARAM wParam, LPARAM lParam )
{
LRESULT lResult = 0L;
      if(m_refEditedGridCellObejct.OnInplaceControlWindowProc( lResult, message, wParam, lParam, m_hWnd, . . . ) )
            return lResult;
      . . .
      lResult = __BASE_CLASS_NAME__:: WindowProc(message, wParam, lParam );
      . . .
      return lResult;
}

virtual BOOL PreTranslateMessage( MSG * pMsg )
{
      ASSERT_VALID( this );
      if( m_refEditedGridCellObejct.OnInplaceControlPreTranslateMessage( pMsg, m_hWnd, . . . ) )
            return TRUE;
      . . .
      return __BASE_CLASS_NAME__::PreTranslateMessage( pMsg );
}
This will allow the grid control to receive all the required notifications. But you will also need to handle the end of editing in the similar way like the CExtGridInplaceEdit::_DoEndEdit() method does. Please believe us, it’s not possible to use any abstract window/control as in-place active editor in any other control in Prof-UIS, in any Windows common control, in any Windows Forms controls for .NET, in any other libraries written for MFC or .NET. The host control which can do in-place editing of its inner UI items (grid cells in case of grid) requires some mechanisms of on-the-fly validation and end-of-editing which are specific for the host control only. Unfortunately nobody has written standards for such control hosting and OLE in-pace item activation is not the case of grid control. Besides there are a lot of other requirements for each case of in-place UI editing. For instance, editors inside popup menus and toolbars should not gain focus or should hide their focused state somehow.

Technical Support Sep 17, 2008 - 12:23 PM

There are two absolutely different cases of keyboard processing related to the focused grid cell:

1) The focused grid cell is not being edited. You press a key and grid cell’s CExtGridCell::OnKey() virtual method is invoked (or the CExtGridCell::OnSysKey() virtual method). The focused window is the grid window in this case.

2) The focused grid cell is currently being edited. The in-pace editor window is created and displayed over the grid cell. The focused window in this case is the editor window rather than the grid window. As you know, all the keyboard messages are sent to the focused window only. So, you should implement the CExtGridCell::OnInplaceControlWindowProc() virtual method if you want to handle keyboard events during cell text editing. There are no problems in this method, you simply should implement it.


Offer Har Sep 17, 2008 - 1:37 PM

Dear Support,


I am only talking about the second case, when my In-Place control is created and displayed.


I have implemented in my control the ON_WM_KEYDOWN event handler, and all keys are captured by this method except the VK_DELETE key.I saw that when I press the Delete key, you ’eat’ it in the function mentioned above. I don’t need to re-write the CExtGridCell::OnInplaceControlWindowProc() function, I just need to get the Delete key down event... and I don’t know why you replace it with an EM_REPLACESEL event as you do. Please check why you do it, and how to prevent it from happening.