Quote:
Originally Posted by balabaster
Custom event args usually hold relevant data to the event, and they should inherit from System.EventArgs - if the coder follows standards, which I'm certain you do :oP
While I AM a big fan of coding to standards, the DLL is written for (and needs to continue to work on) an limited system Compact framework, where reflection isn't really feasable.
Perhaps I am a bit to vague for generallity sake.
I wrote a webserver in the form of a dll for a project at work.
The dll has a class that handles all the socket business of reading in the http request and building a custom request object (also contained in the dll).
This class exposes TWO events with the following signatures
void NotifyMessage(string msg)
Plater.ThreadState RequestReceived(Socket s, Plater.RequestObject)
Plater.ThreadState, Plater.RequestObject are contained only in the DLL.
Now with my last post I was able to cheat, and do the Assembly.Load(), create an instance of my class and attach eventhandlers to each event, partially because I knew that I gould call a .GetType() on the ThreadState and other objects, and partially because i abused the generics properties on a method.
Now this is functional for what I was after, I was just wondering for a more universal implementation.
I just want my program to go "hey, the httplistener.dll is here, I might as well run a webserver" or "no dll, guess i will carry on without serving webpages"
EDIT:
Not sure why I am being a helmet and thinking I need to use Reflection in the CE version, it will have a legitamate reference to the dll and can use the types like normal.
I suppose I should rewrite the events to match standard handlers, the event that requires a return value: I can create a custom eventargs that has an object inside it, then I can change that object and read it back again at the palce where i called the event, to mimic a return value right?