Re: How to program plugin DLL's

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


Date: Mon, 7 Feb 2005 20:34:38 -0300

Thanks all who answered. That is clear now about this mechanism but I got
another doubt concerning this.

This is an MDI application. As other functionality of the tree nodes, when I
right click a node, a popup menu is displayed. One of the options let the
user to open a MDI window that monitors the corresponding device. Here 2
questions:

1.- The popup menu displayed will depend on the device where the user
clicks. I know that I can place the menu resource in the DLL and load it
according to which plugin corresponds to the clicked node. Since the parent
window of the node is the CTreeCtrl (thus, the parent window of the menu),
is it possible to route the menu commands to the plugin DLL without actually
having a target window contained on it?

2.- The MDI window has the template created this way (currently I'm doing
this in OnInitInstance of the application):

 CMultiDocTemplate* pDocTemplate;
 pDocTemplate = new CMultiDocTemplate(
  IDR_HKDOCTYPE,
  RUNTIME_CLASS(CHKDoc),
  RUNTIME_CLASS(CHKFrame), // custom MDI child frame
  RUNTIME_CLASS(CHKView));
 AddDocTemplate(pDocTemplate);

Since each device functions differently, I cannot have either the same view,
or the same doc, or the same frame. Is it possible to have that template
definition in the plugins, so that when user chooses the menu option, the
CDocTemplate::OpenDocumentFile method is called and "transparently" the
right template is open? What approach can I follow to accomplish this to add
the templates to the application?

Thanks a lot for your advice
Jaime

"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:g8gf01lfel690mgdjutsrbtb4mbsck1oqp@4ax.com...
> Key here is to define the behavior of each of the interfaces. For example,
> that an
> interface takes a CWnd * to which messages are posted to indicate device
> status is one
> approach I've taken.
>
> One thing I did was put in the comments of the VERSIONINFO object a
> comment like
> Device:name here
> and then when my app starts up, I use GetModuleFileName to locate the
> directory, do a
> FindFirstFile/FindNextFile to look for *.dll, and for each DLL found, use
> the
> GetVersionxxx APIs to get the comment. If the comment starts out as
> "Device:" then I took
> the name and added it to a menu (my choice was to use a menu) of possible
> devices. Each
> DLL would be responsible for enumerating its devices, so you'd call an
> interface function
> to say "Tell me the names of each device you understand" and get back some
> sort of list
> that I could add to the tree control.
>
> There is no problem with loading multiple DLLs. As long as their names are
> different, such
> as A.DLL and B.DLL, there is no challenge. What I would do is put a
> pointer to a struct in
> the LPARAM of the tree item, and this pointer would reference a struct
> that had pointers
> to the methods in it. You would get these from GetProcAddress after you
> loaded the DLL.
> Thus, when you double-click an entry, you go out, get the LPARAM for that
> entry, and you
> have the vectors to the DLL so you can query it, ask it for status, etc.,
> etc.
>
> You could also set your program up so that if you loaded a DLL and asked
> it to enumerate
> its devices that if the enumeration list was empty, you could then choose
> to eliminate its
> entire entry from the tree.
> joe
> On Mon, 7 Feb 2005 06:01:04 -0800, "Jaime Stuardo"
> <JaimeStuardo@discussions.microsoft.com> wrote:
>
>>Hi all...
>>
>>I'm programming an MDI application that controls some devices connected to
>>serial port or Ethernet LAN.
>>
>>That application will support different type of devices and to make it
>>modular, I will program each device type functionality in DLL's.
>>
>>I'm planning that when I add support to a new device, I need to program
>>only
>>a DLL and after copying it to the application directory, the application
>>recognizes automatically the DLL and may add those kind of devices.
>>
>>As an example, support I have 2 kind of devices, A and B. Both controlled
>>by
>>A.DLL and B.DLL, respectively.
>>
>>In the tree will appear:
>>
>>- Devices
>> - A type
>> - DevA 1
>> - DevA 2
>> - B type
>> - DevB 1
>>
>>By double clicking a node, a status window will appear. Of course, that
>>status window depends on the kind of device. That window is popped up by a
>>function named ShowStatus present in the plugin DLL. Now the tricky part:
>>By
>>double clicking DevA 1 node, ShowStatus of A DLL will be called. On the
>>other
>>hand, when DevB 1 node is double clicked, ShowStatus of B DLL will be
>>called.
>>
>>Any advice about how can I achieve this?
>>Thanks a lot in advance
>>
>>Jaime
>
> Joseph M. Newcomer [MVP]
> email: newcomer@flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm



Relevant Pages

  • Re: MDI application embedded into DLL
    ... Each component is embedded into DLL written in Delphi ... functionality that a MDI MFC application such as open several documents, ... One is a logical component that implements functionality. ...
    (microsoft.public.vc.mfc)
  • Re: MDI application embedded into DLL
    ... There is nothing special in writing a DLL. ... extraordinary about MDI behavior in a DLL. ... It can contain MDI functionality as ... Start you creating a MFC Extension DLL and exporting a class which can ...
    (microsoft.public.vc.mfc)
  • Re: MDI application embedded into DLL
    ... want to move some of that behavior to a DLL, but still use the basic MFC ... extraordinary about MDI behavior in a DLL. ... whatever functionality you choose. ...
    (microsoft.public.vc.mfc)
  • transform MDI application into a dll window and load it as child of another window
    ... like the subject sais i want to transform a MDI application into a dll and ... load from that dll the main window as a child of an other window. ...
    (microsoft.public.vc.mfc)
  • Re: MDI application embedded into DLL
    ... If you want MFC behavior, ... you create an extension DLL. ... If you do not want the base MFC functionality (sharing ... extraordinary about MDI behavior in a DLL. ...
    (microsoft.public.vc.mfc)