I would like to have a button from my toolbar activate in-place editing of a specific column in the selected row.  I can get in-place editing working based on a user selecting the cell but I don't want editing to be activated accidentally so would like to force them to activate it from a toolbar (or maybe a right click menu).

How can I pragmatically switch a cell to in-place editing mode?

Hey Serge,

Thanks!  That's exactly want I needed the only issue is that even though I have SelectTextOnEdit set to TRUE it select the text when using the EditItem call, it only works when the user manually starts in-place editing.

Any suggestions?

Cheers,

- James

No worries Serge, thanks for letting me know.

My latest issue, (I haven't investigated it fully but thought I'd check with you now incase it's a known issue) is when I am editing something in-place any keys that are assigned to a command bars option don't work.  Eg. if I assign 'a' to a command I can no longer type 'a' in the in-place editor.  Is this something you have encountered before?

Thanks,

- James

Thanks Serge,

I was able to reproduce it using the task list sample on a different machine but since our main enviroment is C++ and there are no report control C++ samples I need to wait until a machine with C# is available.  All I did was assign the [Del] key to a menu item and it ment I was unable to use delete during in-place editing.

If you are unable to reproduce it yourself let me know and I will try to get access to a C# machine to send you a sample.  (although some C++ (ATL) report control sample would always be nice  )

Cheers,

- James

Hello Serge,

sserge wrote: It is recommended to have unique accellerator keys for menu items access.

Surely the delete key as an accellerator to allow deleting of selected objects is common in many applications.

sserge wrote:  However, to resolve this issue you have to forward this key processing to the control. For more details see also http://support.microsoft.com/default.aspx?kbid=180402 - http://support.microsoft.com/default.aspx?kbid=180402

Thank you for the link, however I'm not certain where this forwarding should happen, according to the link it is in the edit control (which is the in-place editing control) but this is in the active-x control.  How would I go about adding a preTranslateMessage handler to that?

sserge wrote: If you use C++, why not to use corresponding version of the toolkit, what would additionally provide you with more flexibility...

I wish we could.  It would make lots of things much simpler however we are constrained to ATL due to some of our other libraries.

Thanks for the help,

- James

sserge wrote: Yes, this could be a solution. However, I'm not sure whether it is possible for command bars in current version. However, I also think this solution is too "heavy" to for your case.

Is there any chance this could be added to command bars?  While I agree it may not be the best solution it would resolve my problem.

sserge wrote: Also, actually for me using an accelerator for Del key is not a good idea.

Perhaps it depends on the type of application.  PaintShop Pro uses Del as it's 'Clear' accelerator, and Visual Studio (6.0) has Del as it's Delete accelerator.  In our application delete is a commonly used command and keyboard input is hardly used (similar to a drawing or CAD program) for this reason we like to have easy to use accelerators as one hand is always on the mouse.

sserge wrote: Another idea, you can delegate processing of Del key from ReportControl.OnKeyDown to command bar handler.

An interesting idea.  This would be a possible solution except the report control is in a docking pane that is only visible sometimes.  When the pane is not up (or does not have focus) we would need to pass off the delete key from other windows.  Even worse is the keyboard shortcuts are user configurable so someone might choose to use the 'd' or space key instead of 'del'.  We would need to have special handling for all different user accelerators and it would get quite messy.

It seems to me some type of communication with command bars to tell it not to trap the keys at certain times would be very useful.

Best regards,

- James

sserge wrote: Ok, 2 more last proposals on how it could be resolved without patching a toolkit

 .. I'm sure I can come up with some work-around.  Although ideally some change to the toolkit would be nice.  Should I submit it as a feature request?

sserge wrote: -Vice versa, when you catch Del key in your command bar handler, forward key down message (SendMessage) to a currently active window -- an inplace edit box when editing, etc; - Process Del key not as an accelerator, but as a key down/up handlers in your application.

Both of those sound like good suggestions, however my issue isn't just with the delete key.  Our keyboard short-cuts are fully customizable so if someone changes an accelerator to a different key I would need to search through all the command bars menu items to determine what short cut key is being used and handle it appropriately.  Perhaps when the in-place edit has focus the command bars shouldn't respond to any thing?

For now I think I will drop the use of in-place editing, but if you could investigate the issue for the next patch release it would be appreciated.

Thanks,

- James