Printable View
I have to write an ActiveX DLL for an app. When this DLL is loaded, it's supposed to add a couple of menu items in the client app's menu bar. Does anyone know how this can be made possible? I guess I shall have to use some API because the client app is not a COM app so I can't assume I can interact with it using COM.
.
Have a look at this : http://www.pscode.com/vb/scripts/Sho...25025&lngWId=1
I suggesting taking some time and reading through MSDN's menu section. I'll try to summerize as much as I can.
Let's assume you already have a menu created. You can add to this menu via the AppendMenu function.
To add to the main menu bar, pass the return value of GetMenu().
To add to a sub-menu, pass the return value of GetSubMenu()
To respond to events from your newly created menu's, you need to subclass your main window, and catch the WM_COMMAND event. The lower-order bits of the wParam parameter (of the window procedure) will tell us the identifier of the window that passed the message. You can set the identifier via the 3rd parameter of the AppendMenu.
Thanks a lot, Megatron. I went through the APIs earlier too, including the subclassing. I am sure the code is also readily available on the net. My only problem is I shall have to use this code in a DLL, and have its menus added into a client application.
In short,
Client app loads my DLL
DLL initialization code will add menus to the client app (?)
DLL initialization code will subclass these menus (??)
DLL will have event handlers to process the menu messages.
The second and third steps are what I cannot understand how to do.
To use the APIs, I shall need the hwnd of the menu control in the client app. This means first I shall have to retrieve the hwnd of the client app itself. I guess it becomes too messy for a non-C/C++ guy like me :)
manavo11, thanks for the link. I have downloaded the zip file and shall check it out soon. It does look like what I want to do.
I ran the project and it prompts me for a Class. I am using the ConTEXT editor as my notepad. The default setting of Notepad didn't work. I changed it to read ConTEXT and then tried to add a menu, but nothing changed in the ConTEXT window. If I have to find out the app class myself it's no use to me, again.
.
Is there a speicifc reason why you're doing this through an ActiveX DLL?
It's a client requirement. My boss sounded as if it was child's play to add menus dynamically to an app, but I thought it wouldn't be so easy to do with "another" app.Quote:
Originally posted by Megatron
Is there a speicifc reason why you're doing this through an ActiveX DLL?
The requirement is for the ActiveX DLL to add menus dynamically to the client application, something like the context menus in IE and such. But I know these menus are statically created, i.e. whether or not the addin app is running the menus will still be there, and they are manipulated through the registry or through an exposed COM interface (as in the case of VB IDE and AddIns). But in my case I shall most probably have to rely on the API to do it.
.
Now that I think about it, you're going to run into more problems.
In order to catch a "menu click" event via API, you need to analyze the WM_COMMAND message, which means you have to subclass. Since your procedure must exist in a standard DLL (not ActiveX), you're going to have to create yet another (standard) DLL to hold the subclassed window procedure.
For optimal results, you're looking at a reimplementation of the original application. All that overhead with subclassing, is unnecessary. If your boss wants to replicate what IE has,
Am I wrong in assuming that your company is the developer of the original application?
LOL you are wrong, as you must have expected. We are not the developers of the main application/client application.Quote:
Originally posted by Megatron
Now that I think about it, you're going to run into more problems.
In order to catch a "menu click" event via API, you need to analyze the WM_COMMAND message, which means you have to subclass. Since your procedure must exist in a standard DLL (not ActiveX), you're going to have to create yet another (standard) DLL to hold the subclassed window procedure.
For optimal results, you're looking at a reimplementation of the original application. All that overhead with subclassing, is unnecessary. If your boss wants to replicate what IE has,
Am I wrong in assuming that your company is the developer of the original application?
Why should I need to use a standard DLL and not an ActiveX DLL? Surely I can use API and subclassing in an ActiveX DLL?
.
Whoops, my mistake.
Yes, so long as the ActiveX DLL, and the client application are in the same thread, you should be able to subclass fine.
This makes me curious though, how are you implementing a completely new DLL into a pre-compiled executable? (Maybe I'm missing something, here)
My guess is they are replacing an existing dll with the application?
Or no :ehh:
Well, here's the deal: We have been asked to write an ActiveX DLL using all the specificiations given for the same, and it's supposed to work with an EXE file. I don't even know if the EXE will be in VB, but commonsense tells me it should be. Anyways, one of the specification requirements was the dynamic menus, which I guessed must appear in the EXE's menubar. That prompted me to think and stumble across these problems.Quote:
Originally posted by Megatron
Whoops, my mistake.
Yes, so long as the ActiveX DLL, and the client application are in the same thread, you should be able to subclass fine.
This makes me curious though, how are you implementing a completely new DLL into a pre-compiled executable? (Maybe I'm missing something, here)
For the moment they have said they will handle the menus at their end, so I don't know if they are going to build static menus to invoke and manage our DLL or we shall be asked to do it later.
Hope that clears it up. Also I don't think there is any existing DLL. We are writing it up from scratch.
.
Sounds like to me the specification needs to be nailed down before you do your thing.
From my reading of the post, it appears this is not the case.
I agree with dw85745, here.Quote:
Originally posted by honeybee
For the moment they have said they will handle the menus at their end, so I don't know if they are going to build static menus to invoke and manage our DLL or we shall be asked to do it later.
From what you say, it appears the option to implement the code at thier end is still open, in which case I would strongly encourage them to do so.
Implementing it through a DLL is just an unnecessary hassle, here.
Thanks for the advice :) I just wanted to confirm this is the only way. Maybe if they make their app a COM app and expose its menu object through COM it could be done a bit more easily but I doubt they will do it.Quote:
Originally posted by Megatron
I agree with dw85745, here.
From what you say, it appears the option to implement the code at thier end is still open, in which case I would strongly encourage them to do so.
Implementing it through a DLL is just an unnecessary hassle, here.
At least now I know what justification I have to give when I try to throw it out of the specs :)
.