I am assuming you are coding raw Win32 applications in either C or C++ ( no MFC).
For the first question, I am afraid you will have to "subclass" the Edit control.
(The "subclass" word is related to Win32 classes not to C++ classes)
I think you can not catch that menu event from the parent window ( but Im a bit rusty in Win32 so you might try catching the WM_INITMENU from your main window procedure ).
In order to subclass the Edit control, you will have to call GetWindowLongPtr() using the handle of the Edit control and the parameter GWL_WNDPROC to get the current pointer to the window procedure of the Edit control and save it for later use.
Also, you will have to code a custom Window Procedure for the Edit control, and catch the WM_INITMENU message.
Then use SetWindowLongPtr() using the handle of the edit control, the GWL_WNDPROC parameter and a pointer to your custom Window Procedure.
Your custom window procedure should call the original Edit Window Procedure using the CallWindowProcedure() API call for the messages you dont process; this is why you saved this pointer.
Now regarding the second question, you dont usually make the controls send messages to the parent Window, controls originate notifications theirselves automatically (look at the API documentation for the notifications that controls generate).
For instance, the Edit control generates the event EN_CHANGE when the user edits the text. All you have to do is catch the WM_COMMAND message and EN_CHANGE notification from your main window procedure.
If you ever want to generate notifications, you will have to subclass the control (as I just explained) and from the custom Window Procedure you can generate messages to the parent Window using PostMessage().