Re: How to program plugin DLL's

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Joseph M. Newcomer (newcomer_at_flounder.com)
Date: 02/10/05 

Date: Wed, 09 Feb 2005 19:03:19 -0500

I do this a lot; I have a huge number of apps that are essentially controllers for
embedded systems, and use MDI to monitor more than one device at a time.

What you need to do is create multiple templates, but do not do the AddDocTemplate call
(so the templates are not known to the 'new' menu).

Generally, you can use the same frame, because there is very little in the frame that is
related to the device. What I usually have are two frames, one for my "control panel",
that prevents it from being closed, and the other for the MDI windows. I do, however, have
unique views and documents. However, if each device is different, as you observe you want
to have a mechanism in the DLL that registers the CMultiDocTemplate and returns a
CMultiDocTemplate * that goes in as part of the context of the device. In this case, you
need to include the frame not because it is different, but because each DLL has to have
its own frame just so it can be self-contained in a single DLL. So your approach seems
sound.
                                joe

On Mon, 7 Feb 2005 20:34:38 -0300, "Jaime Stuardo" <jstuardo@manquehue.net> wrote:

>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
>

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: How to program plugin DLLs
    ... This is an MDI application. ... As other functionality of the tree nodes, ... user to open a MDI window that monitors the corresponding device. ... I know that I can place the menu resource in the DLL and load it ...
    (microsoft.public.vc.mfc)
  • Re: MDI Children and DLLs
    ... and it is nice that once the child form (its own ... I also understand that the purpose of a DLL is really for code that is ... - Upgrades - The MDI parent is not likely to change nearly as often as the ...
    (microsoft.public.dotnet.languages.vb)
  • Calling unmanaged C++ dll from C# app
    ... it doesn't work well for the MDI C# model. ... We have been trying to load the DLL more than once into the MDI process ... domains reference the same copy of the DLL in the MDI process space). ... Does anybody know of a way to load multiple instances of the same unmanaged ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Sharing a form
    ... It has to be an MDI and can't be a modal. ... > just say that the form in your DLL is for entering a user id and password. ... you might have a public method named VerifyUser. ... you could have this DLL work with any of your apps. ...
    (microsoft.public.vb.controls)
  • Re: Making DLLs
    ... a frame" during resizing is extremily annoying. ... You'll see the filelistbox flickering during ... When I created a DLL in VB, I exported a function that called a frame1.show ... Since a DLL is not a window it does not ...
    (microsoft.public.vc.language)