Forum

Is there any special reason why Ctrl+C, Ctrl+V wouldn’t work in the Inplace EditCtrl in the CExtGridWnd?

I have a CMainFrame class; inside of it, there is a static SplitterWnd and on the two sides of the SplitterWnd, I have 2 CFormViews and on one of these FormViews I have my CExtGridWnd.

Do you by any chance have an idea what could cause the problem? Unfortunately I couldn’t reproduce the problem in a small sample.
I know I could write my own EditCtrl class, override the appropiate methods and subclass original EditCtrl. But in all of your samples it works without subclassing, so I’d prefer some other solution for my problem.

Thank you:
Chris

We guess there may be some accelerator table pre-translation problem in your app, which causes the key combinations not work properly. Please try to remove all these key combinations from the accelerator table resource.

Yes, removing those key combinations from our accelerator table solved the problem. But we really do need those, since the items represented in the grid has to be put on the clipboard in our application.

When an application is using clipboard, it’s not a good practice to use accelerators other than the ones throughoutly used in Windows for clipboard operations. But as I’ve been reading through Prof-UIS and MFC PreTranslateMessage codes, it seems to me that this is kind of an MFC bug.... Actually I had the same problem with CTreeCtrl and CListCtrl, I had to subclass in-place EditCtrl-s to handle these key events. Another proof of bad coding considerations with MFC itself. Well, anyway, I’m going to go for subclassing then.

Thank you:
Chris

Last few hours I’ve been struggling with trying to find an appropiate place to subclass the in-place editcontrol created inside the grid.

My first guess was to call SubclassWindow method in the overriden OnGbwBeginEdit method. Help says: "Called to activate an in-place editor for the specified cell. The method returns true if the editor window has been successfully created." so I was assuming that default implementation creates editor and returns. Well, reading through code I had to realize, CExtGridBaseWnd::OnGbwBeginEdit only returns after all editing is done and inplace editor is destroyed.

Second guess: Override CExtGridWnd::OnGridCellInplaceControlCreate, but help was pretty clear on that: default implementation does nothing, only returns NULL.

Third and closest guess: For my editable cells I created a class derived from CExtGridCellString and override OnInplaceControlCreate method. Default implementation really does create the editor and returns its HWND. BUT.... when I called SubclassWindow after calling default implementation of OnInplaceControlCreate and passing the returned HWND in SubclassWindow (in case it’s not NULL ,of course), I got an assertion:

ASSERT(FromHandlePermanent(hWndNew) == NULL);
// must not already be in permanent map

So my main question: What is the right way to subclass the editor created for the grid?

Best regards:
Chris

If you want to use a custom inplace edit control instead of ours, you need to override the CExtGridCell::OnInplaceControlCreate() virtual method, which is is used for creating the edit control. Your edit class should be derived from CExtGridInplaceEdit. So basically you need to copy the body of the CExtGridCell::OnInplaceControlCreate method into your overridden method and replace CExtGridInplaceEdit with CYourGridInplaceEdit (your class).

Please note, there is a virtual method OnInplaceControlWindowProc in the CExtGridCell class. It is spying on the window procedure of the in-place editor and returns true if a Windows message has been handled by the cell object. So you can override this method to handle any message from the in-place edit control. This means that probably you may not have to create your own inplace edit control.

Ok, so if I understand right, there’s no way I could subclass... :(

The reason I wanted to choose this approach is that I also have a CTreeCtrl which has the same problem, so I already created a CEdit-derived class for fixing this. I could also override OnInplaceControlPreTranslateMessage and handle the messages there, but then I would have the same code twice: once in this OnInplaceControlPreTranslateMessage and once in my CEdit-derived class. I’m not really fond of this idea, since: Who will remember in some years that I had this code twice? So if anytime I realize I have to fix something in it, I probably will just fix it in one of the codes and forget about the other.

You are writing: "So basically you need to copy the body of the CExtGridCell::OnInplaceControlCreate method into your overridden method and replace CExtGridInplaceEdit with CYourGridInplaceEdit (your class)." This also has it’s dangers: What if you change the body of the CExtGridCell::OnInplaceControlCreate method in any of your future versions? At every Prof-UIS upgrading I should check if it changed or not and if so, copy the changes to my code as well.

But since I don’t see any other solution right now, I guess I’ll go for this second approach: use the edit class I already created, derive it from CExtGridInplaceEdit, override CExtGridCell::OnInplaceControlCreate method and create my own editor in it. Probably I won’t have problems subclassing the inplace editor of the CTreeCtrl to a CExtGridInplaceEdit-derived class.

Have a good weekend!
Chris

Yes, to create an CExtGridInplaceEdit-derived seems to be the best solution. We do not plan to change it abd CExtGridCell::OnInplaceControlCreate() so you will have no problem in future with this.

I couldn’t make it work this way, after all. The main reason is that I wanted to use this same CExtGridInplaceEdit-derived class in my CTreeCtrl and subclass that inplace editor to this same class. For that I would need a default constructor for this CExtGridInplaceEdit-derived class, which I don’t think I can make.

So I have overriden the OnInplaceControlPreTranslateMessage method and handled everything there. It works good now.

One more question: The context menu appearing when I right-click inside the inplace editor... does that show OS/user specific language? I mean if the user of our application uses for example Hungarian Windows, will he/she see those strings (Copy/Paste/Cut/Select all, etc.) in Hungarian, or you fill that context menu with Prof-UIS resources?

Thank you:
Chris

You can create a template class with the PreTranslateMessage method, that can be applied to the edit class for the tree and for the grid. This may help you to solve the problem of dubbing the source code. As for the context menus, we did not find any way to retreive all the menu items including the extended part, so we build the menu manually. It is done in the CExtEditBase::OnContextMenu method. All you can do is to disable Prof-UIS menus. Just set the m_bHandleCtxMenus property to false.

Thank you for the information. I’ll try template class.

Best regards:
Chris