|
OK the code below is puzzling me. i have this nice little static member that loads pluggins based on a Type object. It does all of this fine, gets everything I want, yada yada... then i get to using the object. I'm looking at the autos in the debugger right now and they say that pluggin, by itself, is of type SourceControl.SourceSafe, which DOES implement ISourceControlPluggin (these are my classes/interfaces) though it won't let me do the cast - keeps yelling at me. Anyone have anything - i'm sure i'm just being blinded by the weekend...
object[] pluggins = System.Pluggins.Pluggins.LoadPluggins( plugginsDir, typeof(ISourceControlPluggin) );
foreach(object pluggin in pluggins)
{
MessageBox.Show( this, ((ISourceControlPluggin)pluggin).Name );
}
.... Snippet of the loadpluggins member ....
.... Almost exactly the same as leppie's function in MYrc ....
public static object[] LoadPluggins( string Directory, Type Interface )
foreach( file found in Directory, load the assembly)
{
if( asm != null )
{
Type[] types = asm.GetTypes();
foreach(Type type in types)
{
Type[] interfaces = type.GetInterfaces();
if( type.GetInterface(Interface.FullName) != null)
{
lstPluggins.Add( Activator.CreateInstance(type) );
}
}
}
}
}
|
|
|
|
|
Where is ISourceControlPluggin defined? Types have assembly identity, so for this to work, both your loader and the plugin have to be referencing the same type in the same assembly. Usually you'd do this by creating a separate assembly that just holds the interfaces plugins need.
Let me know if that's not the issue.
|
|
|
|
|
Really? That seems a bit absurd, really. How could you ever write an abstract class such as linked list. I'd have to recompile the linked list each time i create a new datatype I want to use it. Does this only apply to copy types or reference types as well?
|
|
|
|
|
Cromwell wrote:
Really? That seems a bit absurd, really
Taking your linked list example, what would stop two people from just happening to write a class with the same name? They would most likely not be compatible with each other, so allowing casting between the two is a bad idea.
Cromwell wrote:
How could you ever write an abstract class such as linked list.
I wouldn't make the linked list class abstract; instead I would use a generic node type which would hold an object as well as the prev, next references.
Now this class gets placed into its own assembly which other projects can reference to leverage the class.
James
|
|
|
|
|
Well I gave your suggestion a try and it had no effect. I am still quite disturbed by your statement though. I think you might want to run through the snippets I put in the original post again. I think you may have misinterpreted the LoadPluggins method, but I could be wrong.
Thanks for the response though.
|
|
|
|
|
Hmm I did try this though just for kicks. I changed the return type of LoadPluggins to System.Array and instead of this:
return lstPluggins.ToArray()
I did:
return lstPluggins.ToArray( Interface )
At this point the exception is:
System.InvalidCastException - At least one element in the source array could not be cast down to the destination array type.
Which I could see as being solved by your comment, but referencing the ISourceControlPluggin project and even adding a using line doesn't help.
|
|
|
|
|
CromwellRyan wrote:
though it won't let me do the cast - keeps yelling at me.
What is the exceptions you are getting? I struggled a couple of days with getting it to work just right.
MYrc : A .NET IRC client with C# Plugin Capabilities. See
http://sourceforge.net/projects/myrc for more info. 
|
|
|
|
|
Well I get two really. It just depends on where the cast is done. You can see the second of the exceptions in the post previous to yours by Eric. The first problem noticed when returning the object[] from LoadPluggins is:
System.InvalidCastException - Specified cast is not valid.
I'm starting to get a little frustrated here. Damn I just want some pointers (memory pointers - someone pointed out that could have been taken poorly  ) people!!! 
|
|
|
|
|
Here's a picture of the debug window. Notice the Watch window as it says the pluggin is of type SourceControl.SourceSafe. In the Class View window it shows that the class does implement the interface ISourceControlPluggin. See, its weird. Wierd even...
|
|
|
|
|
|
Here are the two files in question. Note that each are in their own project and hence library. The first has a reference to the Pluggins project.
Calling Exe
Pluggins Class
I would like to mention a really bad thing though. ((SourceControl.SourceSafe)pluggin) is invalid as well!!! I hate to say it, but I can't think that this is anything but a bug, which I'm slow to assume but either the debugger watch window lies or the code doesn't compile.
|
|
|
|
|
The 1st thing i notice is that you are placing the plugins in a directory. I had lotsa problems with this, too many to think of now.
Secondly , I still do not see the definition of the interface. 
From Pluggins.cs:
if( type.GetInterface(Interface.FullName) != null)
Should be:
if( type.GetInterface(typeof(ISourceControlPluggin).FullName) != null)
MYrc : A .NET IRC client with C# Plugin Capabilities. See
http://sourceforge.net/projects/myrc for more info.
|
|
|
|
|
Why is that wrong. Its the same thing... instead of getting the typeof(ISourceControlPluggin) type object in the method, i'm passing it in.
here is the interface def file -- sorry 'bout that
I actually posted this same problem friday but since it was friday I didn't get much feedback. One response I did get was from someone saying that he had lots of problems loading assemblies because of version issues; even if signatures didn't change. In following that path, I realized I hadn't removed the auto-version increment in some of the assemblies including the Pluggins and Interface one files. I will let you know if I find anything.
|
|
|
|
|
I found out what the problem was everyone. Russell Morris mentioned he had similar issues and he tracked it down to version issues with the loaded version vs. the linked version. What I did is 1) cleaned out my debug directories to start fresh. 2) Removed all auto-increment versions in assemblies files (not really necessary, but less confusing) 3) made sure that the assemblies being built and linked during debug where the same version being loaded dynamically. More specifically, had the same signature.
I want to thank Russell Morris from a duplicate post from friday for the solution to my problem. leppie thanks a ton for all your time, I really appreciate it. By the way, everything is running in different directories and, if you believe this, on network shares which was my hope because I'd like to store the pluggins and configuration files on a server for centralization.
|
|
|
|
|
I had a look, and will see if i can load my files similary (Brain.VocabularyOutOfRangeException) 
I think the reason why i didnt have issues, is that im rebuilding main app, plus interface assembly, and allmost all plugins with every build.
I shall get back to you if that is the case
MYrc : A .NET IRC client with C# Plugin Capabilities. See
http://sourceforge.net/projects/myrc for more info.
|
|
|
|
|
WM_CTLCOLOREDIT is sent to an edit control's parent window. Now assume I have a System.Windows.Forms.TextBox derived class. And assume I wanted to handle WM_CTLCOLOREDIT from within the class. I am unable to do so currently. How do people handle WM_CTLCOLOREDIT from their derived edit classes?
Nish
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Review by Shog9
Click here for review[NW]
|
|
|
|
|
When I was fooling around with implementing a new wrapper for the SysTreeView32 I noticed that most messages like these were reflected back to your class. So in your WndProc for your derived edit control look for messages as:
#define WM_REFLECT WM_USER + 0x400
...
case WM_REFLECT + WM_CTLCOLOREDIT
...
I'm not 100% positive that is the right definition for WM_REFLECT. I remember first seeing this (and copying it) from Lutz Roeder's code for the enhanced toolbar, so check there if the above doesn't seem to work.
--
Russell Morris
"Have you gone mad Frink? Put down that science pole!"
|
|
|
|
|
I understand your Q. now
The Control class handles WM_CTLCOLOR for you and sets the background color and the text color of the dc to that specified in the properties of the Control. So you don't need to handle it.
|
|
|
|
|
Rama Krishna wrote:
The Control class handles WM_CTLCOLOR for you and sets the background color and the text color of the dc to that specified in the properties of the Control. So you don't need to handle it.
Usually we dont need to. But if you handle WM_PAINT yourself, and draw a different color background, then you have a problem. Now when the user types something in, the bgcolor of the text is not your back color 
Even specifying the backColor property is useless here. I wasted half an hr over this today. Also discussed with James. He feels that when you handle WM_PAINT yourself somehow WM_CTLCOLOR is handled by the OS
Nish
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Review by Shog9
Click here for review[NW]
|
|
|
|
|
Follow Russel Morris's idea. WM_REFLECT is 8192.
|
|
|
|
|
|
|
In the controls constructor add the following line
SetStyle(ControlStyles::UserPaint, true);
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
