Re: Plugin Architecture Question - Best Practice For Forms Update

DLL's used by an EXE don't run on a separate thread. The DLL usually runs on
the EXE's thread. This means that your normal event handling systems work
just fine. Remember that things like TextBoxes and indeed the Form base
class are held in a DLL that's used by your EXE.

Timers such as System.Threading.Timer do indeed notify of timeouts on a
different thread. In cases where you use the more reliable timers you must
invoke correctly.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.





"cab0san" <cabosan@xxxxxxxxx> wrote in message
news:1129258710.215818.307320@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Plugin Architecture Question - Best Practice For Forms Update
>
>
>
> I have an application that follows a simple plugin architecture. Yes,
> it is my first plugin app, so please bear with me. There is an
> interface defined, and followed by the host exe and plugin (or client)
> dll. The plugins reach out into the world and get bits of information
> (stock prices, new mail, disk space, rss feeds... whatever) these bits
> of information end up as treenodes in a treeview in the host app.
>
> My question is:
>
> When a plugin is ready to deliver updated content, say perhaps by use
> of a timer, what is the preferred way of notifying the host app?
>
> (assuming that my plugin will be in a seperate thread)
> Should I pass a reference to the form?
> Do I raise an event?
>
>
> I know that you should operate on winforms in the originating thread
> only , so they don't play well with refreshes sent from timer threads
> (or any other thread). I am able to use invoke to get around a few
> things, but I was hoping to find a simpler solution, and wanted to hear
> some opinions.
>


.

Relevant Pages

  • Re: Plugins in C#
    ... Point taken though, I'll just stay with the extra DLL for now, it works ... make each plugin reference the main application project, ... since you can just copy the DLL with the interfaces in ... If it is in the same directory as the EXE, ...
    (microsoft.public.dotnet.languages.csharp)
  • Tracking down the process that owns a window
    ... My company makes a DLL that acts as a plugin to another product (an EXE). ... While interacting with that product, a message box pops up with the name of ...
    (microsoft.public.vc.mfc)
  • Re: Dynamic linking with symbols
    ... plugin simply registers some callbacks inside these singeltons. ... The latter will result in a bigger dll and also a duplication of code. ... stuff inlined in the header or you have to include it either in the dll or link it from the exe. ... You can not simply call methods if all you know if the class definition and also a this pointer. ...
    (microsoft.public.vc.language)
  • Re: Dynamic linking with symbols
    ... Now the problem is that in this case the dll has to link against a specific executable which in turn makes sure I can't use the same dll in two different executables. ... Now I could put all the exported code from my executables into a dll and let my plugin dll and both of my executables link against this dll. ... EXE links against. ...
    (microsoft.public.vc.language)
  • Re: Access base window class (FromHandlePermanent)
    ... The way I handle this is to specify a "plugin interface". ... The DLL, to be a valid plugin, must export a number of functions that are called by the ... fact that the hosting app might be statically linked, ...
    (microsoft.public.vc.mfc)
Loading