Discussion:
No WM_CONTEXTMENU for RichEdit after EM_SETOLECALLBACK
(too old to reply)
Mark Hatsell
2007-08-13 15:45:29 UTC
Permalink
Hello All

I have a RichEdit control which I have placed in a dialog. I provide a
custom context menu by catching the WM_CONTEXTMENU message for the RichEdit.
WM_COMMAND messages sent by clicking menu items are received and handled
within the control. This all seems to work OK.

However, I have now need some of the OLE functionality of the RichEdit so I
have retreived a IRichEditOleCallback object using the EM_SETOLECALLBACK
message. However, once I have done this, the WM_CONTEXTMENU message is never
sent to the RichEdit any more. I can get around this by providing a
IRichEditOleCallback::GetContextMenu method and creating the context menu in
there. This seems to work. However, whenever I then select a menu item from
the context menu, the WM_COMMAND message is sent to the parent dialog rather
than the RichEdit control itself. Is there any way I can change this
behaviour so that command messages are sent to the control as normal?

Thanks in advance.

Mark
Gary Chanson
2007-08-13 16:14:49 UTC
Permalink
Post by Mark Hatsell
Hello All
I have a RichEdit control which I have placed in a dialog. I provide a
custom context menu by catching the WM_CONTEXTMENU message for the RichEdit.
WM_COMMAND messages sent by clicking menu items are received and handled
within the control. This all seems to work OK.
However, I have now need some of the OLE functionality of the RichEdit so I
have retreived a IRichEditOleCallback object using the EM_SETOLECALLBACK
message. However, once I have done this, the WM_CONTEXTMENU message is never
sent to the RichEdit any more. I can get around this by providing a
IRichEditOleCallback::GetContextMenu method and creating the context menu in
there. This seems to work. However, whenever I then select a menu item from
the context menu, the WM_COMMAND message is sent to the parent dialog rather
than the RichEdit control itself. Is there any way I can change this
behaviour so that command messages are sent to the control as normal?
WM_COMMAND messages are always sent to the parent of the control.
--
- Gary Chanson (Windows SDK MVP)
- Abolish Public Schools
Mark Hatsell
2007-08-13 17:07:07 UTC
Permalink
OK, then MFC must be routing them back to the control in the first case,
since I am handling them via the ON_COMMAND macro in the RichEdit control
class. Once I have called EM_SETOLECALLBACK however, the routing no longer
works, since the handler no longer gets called in the RichEdit and instead
the message goes to the parent dialog. Any idea how I can still have the
command messages still go to the control class since all my handling is
there at the moment and I don't really want to have to add it to each dialog
class just for the case where I need the OLE functionality?

Thanks.
Mark
Post by Gary Chanson
Post by Mark Hatsell
Hello All
I have a RichEdit control which I have placed in a dialog. I provide a
custom context menu by catching the WM_CONTEXTMENU message for the RichEdit.
WM_COMMAND messages sent by clicking menu items are received and handled
within the control. This all seems to work OK.
However, I have now need some of the OLE functionality of the RichEdit so I
have retreived a IRichEditOleCallback object using the EM_SETOLECALLBACK
message. However, once I have done this, the WM_CONTEXTMENU message is never
sent to the RichEdit any more. I can get around this by providing a
IRichEditOleCallback::GetContextMenu method and creating the context menu in
there. This seems to work. However, whenever I then select a menu item from
the context menu, the WM_COMMAND message is sent to the parent dialog rather
than the RichEdit control itself. Is there any way I can change this
behaviour so that command messages are sent to the control as normal?
WM_COMMAND messages are always sent to the parent of the control.
--
- Gary Chanson (Windows SDK MVP)
- Abolish Public Schools
Gary Chanson
2007-08-13 18:43:12 UTC
Permalink
Post by Mark Hatsell
OK, then MFC must be routing them back to the control in the first case,
since I am handling them via the ON_COMMAND macro in the RichEdit control
class. Once I have called EM_SETOLECALLBACK however, the routing no longer
works, since the handler no longer gets called in the RichEdit and instead
the message goes to the parent dialog. Any idea how I can still have the
command messages still go to the control class since all my handling is
there at the moment and I don't really want to have to add it to each dialog
class just for the case where I need the OLE functionality?
Not really. I don't generally program in MFC.
--
- Gary Chanson (Windows SDK MVP)
- Abolish Public Schools
Jeffrey Tan[MSFT]
2007-08-14 10:15:27 UTC
Permalink
Hi Mark ,

Yes, I agree that this magic should be done by MFC. I will discuss with
some MFC experts internally to see if we have any elegant workaround for
it. I will get back to you ASAP. Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Jeffrey Tan[MSFT]
2007-08-16 03:26:28 UTC
Permalink
Hi Mark,

Have you tried ON_CONTROL_REFLECT in your rich edit control's message map?

Also, can you send an email to ***@online.microsoft.com(remove "online.")
so that we can communicate more efficiently?

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Mark Hatsell
2007-08-16 10:50:03 UTC
Permalink
Hi Jeffrey

Yes, I have already tried ON_CONTROL_REFLECT. However, I still get the same
problem, in that the handler function specified in the macro is never called
and the message instead goes to the parent dialog.

Thanks.

Mark
Post by Jeffrey Tan[MSFT]
Hi Mark,
Have you tried ON_CONTROL_REFLECT in your rich edit control's message map?
so that we can communicate more efficiently?
Thanks.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Jeffrey Tan[MSFT]
2007-08-17 06:58:09 UTC
Permalink
Hi Mark,

Thank you for the feedback.

Without reproducing the problem, the analysis can only base on the guess.
Is it possible to create a little sample project to demonstrate this
behavior? Once we can reproduce it locally, we can analysis it better.

You may send the sample project to me at the email address I provided in
the last reply.

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Loading...