Re: How to program plugin DLL's

From: Jaime Stuardo (jstuardo_at_manquehue.net)
Date: 02/14/05 

Date: Mon, 14 Feb 2005 07:55:46 -0300

Do you mean I have to call the corresponding GetProcAddress for all
functions when I first load the DLL's? That's the only way I can think I can
build the descriptor you mentioned.

I think in my case I cannot use the user-defined field for the menu since
that menu is subclassed in order to have a different look from the standard
one. That new menu class uses that data to accomplish it tasks.

But I think I can use the user-defined field of the items in the CTreeCtrl.
Each lParam member of the TVITEM struct may be filled with the pointer to a
class in the DLL.

That class is the "only" element to be exported from the DLL.

As you mentioned a super class, I have thought that I can have, in the main
application, a class that defines some virtual functions. One one them may
be "ExecuteCommand". All DLL's may derive and export a class from that
superclass.

When user clicks a menu item, by mean of its user-defined data I can get the
pointer to that class and then call something like this:

pointer->ExecuteCommand(nCmd);

In this case, pointer will be declared as the superclass, so I don't know if
I can call ExecuteCommand that is implemented in the derived class (so that
compiler doesn't send the error).

The disadvantage I see here is that I have the include the .H file, where
the superclass is defined, in all DLL's. That way, I make the DLL's source
code dependant on the H "distributed" with the main application.

Little by little I'm getting closer to the final solution I will implement,
I think :-)

Jaime

> ****
> Generally, you should do the GetProcAddress exactly once, when the DLL is
> loaded, because
> the lookup time is fairly high. Build a descriptor of the DLL; instead of
> a m_dwa array of
> what appears to be module handles, create an array of the descriptors
> which have the
> handle, and the various function pointers in it.
>
> What I might consider here is a method which fills in a popup menu. For
> example, reserve
> the menu item range 10000-11000 for popup menu items for your tree
> control. Then what you
> do is have an ON_COMMAND_RANGE handler that works in the
> MY_POPUP_RANGE_MIN (that's the
> 10000) to MY_POPUP_RANGE_MAX (that's the 110000) value, and simply
> dispatches to the DLL
> that is associated with the menu. Since each menu can have a user-defined
> field, this
> could be the pointer to the record in the table. So all you need is the
> popup menu handle,
> and knowing the index of the command, you retrieve the MENUINFO for the
> menu item, and use
> the dwMenuData field to retrieve the pointer to the DLL descriptor, or,
> alternatively, the
> pointer to the DLL method itself (this means all DLL menu methods need the
> same
> prototype). All DLLs would be derived from the same abstract superclass,
> so this should be
> fairly straightforward.
>
> Generally, you should keep pointers to objects instead of indices to
> arrays because array
> indices could change if a DLL were unloaded, or even if a new one is
> loaded.
>
> These are just some ideas; I used DLL descriptors with function pointers
> for the methods,
> because I had the same menu for all popups. So my handlers just called the
> method of the
> plugin. But it should generalize to supporting plugins with completely
> unrelated menus. No
> need to use the ID map if you have the direct pointers, and calling the
> DLL with an index
> to the menu item lets the DLL figure out what to do, and doesn't require
> knowing in
> advance how many items each DLL supports, or even what they mean, which is
> what it appears
> you are doing.
>>
>>Is this approach correct or is there a more elegant or easy way to
>>accomplish the same task?
>>
>>Thanks
>>Jaime

Relevant Pages

  • Re: Importing a Class define in a Dll
    ... pointer as an extra parameter passed to each non-static ... It is specially useful for the ARM platform as the ... MyClass() {... ... Build the DLL containing your class in the same ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: Exception handling for loading of dependency library?
    ... typedef int (const CString & s, ... A common technique for doing this is to declare it as a global variable, ... the handle for a given dll all in one place. ... pointless because ANSI C does not require dereferencing function pointer variables. ...
    (microsoft.public.vc.mfc)
  • Re: Pointers and DLLs/shared libraries
    ... These pointer variables will point to data in the main program. ... subroutine set_pointer ... (DLLs and shared libraries do not always behave like ordinary ... ....the DLL effectively becomes a part of all of the client programs that use it. ...
    (comp.lang.fortran)
  • Re: dll load address
    ... Marco Ventanas ... >> I'm trying to read the dll import table using a pointer initialized to ... >> but as I read the first byte pointed by this pointer, ... but the displayed Base Addr is the same for all ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Is this a legitimate use of ExternalAddress?
    ... Now, the first time ... pointer is now invalid ?). ... directly to some third party's DLL, then running that under VC could be a real ... to load the DLL from VC's debug folder, and tell VC to "attach" the Dolphin ...
    (comp.lang.smalltalk.dolphin)
Quantcast