|
Actually, after looking it over in light of my other comments, I'm not sure it's needed. Just raise the event and catch it on your form. Then, if InvokeRequired is true, you'll need to call Invoke. I would do this from the form instead of your class, as doing otherwise entangles the two objects. You could have the following, for instance:
public void Search_ProcessingComplete()
{
if(this.InvokeRequired)
{
this.Invoke(Search_ProcessingComplete);
}
else
{
//Do your stuff here that hits the UI.
}
}
On your Search object, your Search method would look like:
public void Start()
{
/// Search would take place here
if(SearchComplete != null) SearchComplete(?);
}
where "?" is the set of parameters you need to pass to invoke the delegate.
|
|
|
|
|
|
this.Invoke(**delegate required here**, args) , what you have is a method
|
|
|
|
|
Right. I should have passed the following in:
this.Invoke(new ProcessingCompleteDelegate(this.Search_ProcessingComplete));
The whole point of the Invoke... methods on the form object is not just to call a delegate, but to actually switch to the thread on which the form is running. Windows Forms are inherently single threaded due to their message loop. This is just a way to get them to run the code in question on the same thread as their message loop, instead of on the background thread. In the above example, I'm calling Invoke to get it to switch over to the UI thread and re-enter the method in that context.
|
|
|
|
|
Use an anonymous method. Here's a code snippet from an MSDN article:
public class SafeLabel : Label
{
delegate void SetString(string text);
delegate string GetString();
override public string Text
{
set
{
if(InvokeRequired)
{
SetString setTextDel = delegate(string text)
{base.Text = text;};
Invoke(setTextDel,new object[]{value});
}
else
base.Text = value;
}
get
{
if(InvokeRequired)
{
GetString getTextDel = delegate(){return base.Text;};
return (string)Invoke(getTextDel,null);
}
else
return base.Text;
}
}
}
Logifusion[^]
|
|
|
|
|
|
the only thing is that i know when invoke is and isn't required so why is this necessary? My issue is that my events do not stay registered and when i call them they are null. I'm lost in what you guys are trying to tell me.
|
|
|
|
|
Are you calling your event using if(SearchComplete != null) SearchComplete(?); or are you using Invoke? Invoke is just the wrong thing to be calling to fire your event.
Logifusion[^]
|
|
|
|
|
You guys will love this. If you simply set the CheckForIllegalCrossThreadCalls to false you can use threads just as you did in VS 2003, which is what I was doing. This was originally written in 2003 and that is why it wasn't working. Now I can manage my own threads without it complaining. What an easy fix.
|
|
|
|
|
From MSDN: When a thread other than the creating thread of a control tries to access one of that control's methods or properties, it often leads to unpredictable results. A common invalid thread activity is a call on the wrong thread that accesses the control's Handle property. Set CheckForIllegalCrossThreadCalls to true to find and diagnose this thread activity more easily.
I surely hope you don't intend to use that in production! I'm also not sure what you mean by "manage my own threads" in VS 2003. I would still get exceptions thrown indicating I was on the wrong thread even in .Net 1.1.
Logifusion[^]
|
|
|
|
|
I only have two threads in the entire application. It is very easy to keep track of what is being accessed by each thread when the number is so small. Thats all I meant. I knew this would pinch a nerve, but my 2003 application has run perfectly since I wrote it. It really is not an issue. This feature was not nearly as strict in 2003 because I ran this exact code and never received a single error.
|
|
|
|
|
Thanks for all of your help. I really appreciate it. I have another major issue however. Could you view my post on listviews. You should see it in the newer posts.
|
|
|
|
|
Did you get this one straightened out?
|
|
|
|
|
well, i reverted to a previous method. I was completely and utterly confused by this conversation.
|
|
|
|
|
This won't work because this.Invoke(Search_ProcessingComplete) is not a valid Invoke statement. That is the wrong parameter for an invoke statement.
|
|
|
|
|
FYI, you can utilize the System.Windows.Forms.WindowsFormsSynchronizationContext object to raise events on the UI thread from your class without having to "entangle" to two objects. You don't even have to entangle your object with Windows forms either; just have it accept any old SynchronizationContext. For Windows Forms apps, you can pass in a WindowsFormsSynchronizationContext and the class then doesn't have to be specific to Windows Forms. 
Tech, life, family, faith: Give me a visit.
I'm currently blogging about: Goof around music jam with my brothers (with video)
The apostle Paul, modernly speaking: Epistles of Paul
Judah Himango
|
|
|
|
|
Looks pretty cool. My one complaint being that you're stuck with the SendOrPostCallback delegate which only takes one object. I'm not really sure you can call it raising an event either because it doesn't technically raise any events. But this is definitely a nice new tool that I'll want to experiment with in the future.
Logifusion[^]
|
|
|
|
|
It really addresses a particular problem that encompasses events: SynchronizationContext are meant for doing things (such as calling methods, raising events, etc.) on a particular thread by either Posting (which corresponds to BeginInvoke for Windows Forms) or Sending (which corresponds to Invoke for Windows Forms).
Thus, you *could* make a library that can dispatch events on a UI thread without tying your library to that control, or even to Windows Forms, for that matter. For example:
class MyCrazyLib
{
private SynchronizationContext syncContext;
public event EventHandler WorkProgressed;
public MyCrazyLib(SynchronizationContext eventRaisingSync)
{
this.syncContext = eventRaisingSync;
}
void DoWorkInBackground()
{
ThreadPool.QueueUserWorkItem(MyWorkMethod);
}
void MyWorkMethod(object state)
{
...
this.syncContext.Post(delegate(object state)
{
this.WorkProgressed(someSender, EventArgs.Empty);
});
}
}
There you've got yourself a library that *can* raise events on any thread, UI thread or otherwise. To use this with Windows Forms, you can simply do:
MyCrazyLib lib = new MyCrazyLib(WindowsFormsSynchronizationContext.Current);
lib.WorkProgressed += MyHandler;
lib.DoWorkInBackground();
...
void MyHandler(object sender, EventArgs e)
{
}
Tech, life, family, faith: Give me a visit.
I'm currently blogging about: Goof around music jam with my brothers (with video)
The apostle Paul, modernly speaking: Epistles of Paul
Judah Himango
|
|
|
|
|
Excellent! The name SynchronizationContext gave me pause because it makes me wonder if it's actually going to still let me do my work asynchronously. I can see from your example that it works just fine. Thanks for showing me this!
Logifusion[^]
|
|
|
|
|
SearchComplete is an event, not a delegate. If you want to fire the event, get rid of Parent.Invoke and use if (SearchComplete != null) SearchComplete(this, new EventArgs()); Or whatever you have to pass into your ProcessingCompleteDelegate.
Logifusion[^]
|
|
|
|
|
Whoops. I didn't even see that. Try his suggestion first. You want to raise the event on your class, not on the form. In the handler for the event (on the form), check for InvokeRequired. If it is required, then you'll have to do call this.Invoke to get it back onto your UI thread.
|
|
|
|
|
I used the wrong wording before. You are correct about it being an event, but it doesn't work either way. I have to use invoke because i will be accessing the controls of another form in another thread when i make this call. I need the event to not have the value null because i need to fire it. For whatever reason when I register ArtifactSearch for its events before I start the thread, they are not staying registered.
|
|
|
|
|
You're thinking about this backwards. The event should not care anything about what's listening to it. It doesn't care what thread the listener is in. The event should just fire. It is the job of the listener to get itself back into the main thread. You have a listener in MainForm, but when you interact with anything in MainForm, you're going to have to do it through the use of Invoke. This means you'll have to write delegates for MainForm, but luckily anonymous methods will make this easier.
Logifusion[^]
|
|
|
|
|
I don't understand what the other guy was saying about lock statements... never used them. Is this the solution?
|
|
|
|
|
In this case, I think you can get away without having to use them. Check out my comments above for more info.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
