need help with Shortcut menu in a Dll

[Rainstorm]

Hi.

Am trying to make a custom shortcut Menu available to another application via a dll.
The other application willl pass the mouse co-ordinates on a right-click so that is taken care off.
The dll will have to create/display the menu etc..& execute the commands as per what is clicked in the context menu.

In the sdk it says that the resulting shortcut menu messages are processed by the window procedure of the said window.
My problem is this..I don't have access to the window procedure for the window in the application where the context menu will be displayed, since it belongs to the external application, so how do I implement this context menu for that other application ?
Can someone clarify this for me..... or say maybe whether what am trying to do is possible or not,.. & if its possible then how do i do it.


Thanks!

Rainstorm

-

[donkey]

This involves code insertion into an application that is not your own, I assume this because you have called it an "external app", and exploration of that avenue is against the rules of the forum. The only legitimate avenue is a message or WndProc hook, hooking the WM_CONTEXTMENU notification message.

http://msdn2.microsoft.com/en-us/library/ms632589(VS.85).aspx

[Rainstorm]

hi
it is an external application that is not mine.
the external app has a proper dll interface, & the reason am doing it is that the application doesn't have any provision for making custom context menus. - with the dll am trying to supply this functionality in contexts I'll need it in - I'd rather have my code in the dll runnng cleanly & completely seperate from the application without messing with the application's code in anyway.

which would be a better solution & function quicker in your opinion.. messages or hooks ?
(..assuming its okay to carry on the discussion in the direction you mentioned, if not I'll stop posting in the thread.)

Thanks for the info & a pointer on a possible soultion..- I'll have to read up on that stuff.

[donkey]

If the application supports 3rd party DLLs then just subclass the control and process the WM_CONTEXTMENU message.

[ossama]

This involves code insertion into an application that is not your own, I assume this because you have called it an "external app", and exploration of that avenue is against the rules of the forum. The only legitimate avenue is a message or WndProc hook, hooking the WM_CONTEXTMENU notification message.

http://msdn2.microsoft.com/en-us/library/ms632589(VS.85).aspx

hello donkey,
please tell me why it is against the rules of this forum (give me the statment in the forum rules that say that).
thank you.

[donkey]

For "why" something is against the rules you would have to ask Hutch, code insertion is a violation of rule 3.

[ossama]

In order to insert code into an application you must reverse engineer it, that is explicitly against rule 3.

i was confused between "inserting code" and  "injecting code"
thank you Donkey .

[Rainstorm]

donkey wrote..

If the application supports 3rd party DLLs then just subclass the control and process the WM_CONTEXTMENU message.

don't know much about this stuff , what's the control in this case ?

[edit] - why do they say this ? Quote from the psdk

However, you cannot subclass a window or class that belongs to another application. All subclassing must be performed within the same process.

[donkey]

donkey wrote..

If the application supports 3rd party DLLs then just subclass the control and process the WM_CONTEXTMENU message.

don't know much about this stuff , what's the control in this case ?

[edit] - why do they say this ? Quote from the psdk

However, you cannot subclass a window or class that belongs to another application. All subclassing must be performed within the same process.

As I said, if the application supports "3rd party DLLs", A.K.A. Plugins, then you can subclass the window since the plugin DLL will be part of the target process. Otherwise it cannot be done in a non-viral/code injection way and so there can be no discussion of it here.

Donkey

[Rainstorm]

donkey wrote..

As I said, if the application supports "3rd party DLLs"..

it does support DLLs fully & has an interface for that.. the format gives the handle of the main window.. as well as the handle of the active window. It also supports SendMessage() to communicate with it.
i guess the subclassing will be the best since in the documentation they say that hooks slow up the process a bit. - was just confused there for a while cause they said..that another app can't subclass.. but you said that through the dll interface.. my dll becomes part of that app.

when i subclass, will my dll get flooded with all other msgs pertaining to the said window ? (which I'll have to pass on to the wndproc of that window)

anyhow i'll give it a try..& read some more on it,... i get the broad idea.
will post later in this thread if i have any questions.

-

[donkey]

donkey wrote..

when i subclass, will my dll get flooded with all other msgs pertaining to the said window ? (which I'll have to pass on to the wndproc of that window)

You will get all the messages destined for that window and will have to forward them with the exception of the ones you need to the original window procedure.