Cancel windows message from reaching parent

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I am developing a set of controls that must function inside of an application
that loads them through COM interop (I don't believe that makes a
difference). The application is designed to always handled the "Enter" key.
One of my controls is a text box which needs to allow the user multiline
input and not being able to use the "Enter" key is borderline unacceptable.

I have tried to override WndPRoc, PreProcessMessage, and a host of other
behaviors, but I cannot get the application to stop catching the enter
message.

I have written all messages to a text file when I transition using enter
versus using a mouse click, and I cannot even find a message that indicates
my control received an "Enter" at all.

All suggestions welcomed.
 
Just because your app handles the ENTER key doesn't mean it must stop it
from being processed by child controls.

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net
 
I am developing a set of controls that must function inside of an application
that loads them through COM interop (I don't believe that makes a
difference). The application is designed to always handled the "Enter" key.
One of my controls is a text box which needs to allow the user multiline
input and not being able to use the "Enter" key is borderline unacceptable.

I have tried to override WndPRoc, PreProcessMessage, and a host of other
behaviors, but I cannot get the application to stop catching the enter
message.

I have written all messages to a text file when I transition using enter
versus using a mouse click, and I cannot even find a message that indicates
my control received an "Enter" at all.

All suggestions welcomed.

If your eventArgs is called "e" then the code "e.Handled = true;" in
some cases will keep the event from being caught by other controls.
This doesn't work for all keys (ex: can't stop ctrl+alt+delete). You
can find more here.

http://www.duncanmackenzie.net/blog/Enter-Instead-of-Tab/

Good luck

Justin
www.immergetech.com
www.immergecomm.com
 
Thanks for the reply, but it is the other way around. I have a foreign app
(read- another internal team) that cannot be changed to suit my needs. I am
building a control to be loaded by this app through COM that needs to handle
the enter key and pre-empt the app from handling it (the behavior makes my
control go away prematurely).

In a web context, it would be the equivalent of cancelBubble = true.
 
It appears you are from a web dev background which is where your confusion
lies. In javascript, events 'bubble up' from the bottom so the control you
click on informs the parent about the click, that informs its parent etc etc.
In Windows, Windows itself finds the desktop window that contains the click
coordinates and gives it the message for the click, it is then that window
which finds the child control containing the coordinates and informs it of
the click, etc etc.
This is opposite to bubbling up and therefore it is impossible to handle an
event before the parent window as the parent window is what tells you about
it.
That is how forms can have the KeyPreview property where they fire their
keypress events before the children.
You would need to do something like handle the Ctrl+Enter keypress and get
the other internal team to let that through.
OR
Hook into all key events in windows with a top level windows hook and handle
the message directly from windows in that way. I know this is possible but
dont know that API call for getting the hook. You'll need to search for that.

HTH
 
Again, I appreciate the attempt to help, and I apologize for my lack of
clarity on the problem. I do understand how windowing works at the SDK level.
I was using the bubbling analogy for illustration.

What I am asking may not be possible, but I will try one last try:

I have identified messages 256 and 258 with lParam of 1835009 and wParam of
13 as the unique problem messages. This control is hosted in a COM container
meaning it has no official parent form.

What I am looking for specifically is the value to set the result (or wParam
or lParam) that might cause the parent to stop processing the message. I
suspect my control is not even receiving the message in the first place, but
if it does- what do I do?
 
Back
Top