Hmmm...
Here is some sample code that I'm using right now (uses
BackgroundWorkerThread and populates a listview for event logging):
BackgroundWorker m_eventWorker = new BackgroundWorker();
// This delegate enables asynchronous calls for adding items
// to a ListView control.
delegate void AddEventToListCallback(ListViewItem lvi);
....
public frmConsole()
{
InitializeComponent();
Helper.RunRemotingServices();
m_eventWorker.DoWork += new DoWorkEventHandler(m_eventWorker_DoWork);
}
private void frmConsole_Load(object sender, EventArgs e)
{
m_eventWorker.RunWorkerAsync();
}
void m_eventWorker_DoWork(object sender, DoWorkEventArgs e)
{
while (true)
{
if (Fenestra.Foundation.Core.EventQueue.Events.Count > 0)
{
Fenestra.Foundation.Core.Event et =
Fenestra.Foundation.Core.EventQueue.Events.Dequeue ();
ListViewItem i = new ListViewItem(new string[] {
et.Timestamp.ToString("dd/MM @ HH:mm:ss.mm"), et.Data });
i.Tag = et;
this.AddEventToList(i);
}
System.Threading.Thread.Sleep(new TimeSpan(0, 0, 5));
}
}
private void AddEventToList(ListViewItem lvi)
{
// InvokeRequired required compares the thread ID of the
// calling thread to the thread ID of the creating thread.
// If these threads are different, it returns true.
if (this.lvEvents.InvokeRequired)
{
AddEventToListCallback d = new AddEventToListCallback(AddEventToList);
this.Invoke(d, new object[] { lvi });
}
else
{
this.lvEvents.Items.Add(lvi);
}
}
"Rob R. Ainscough" <ro*****@pacbell.net> wrote in message
news:eL**************@TK2MSFTNGP05.phx.gbl...
Brendan,
Good article, but it was written before .NET 2.0 was released. I'm using
the new BackgroundWork approach (in .NET 2.0) to threading as it
implements much cleaner and more manageable code than Invoke approach.
Still testing out some solutions, but I suspect I might be able to use
WithEvents on the BackgroudWorker defined in my class modules -- it also
appears that BackgroundWorker is part of system.componentmodel so I can
conceptually use it in my non-UI classes effectively retaining separation
of UI code.
Rob.
"Brendan Green" <bg****@nospam.nospam> wrote in message
news:Oh*************@TK2MSFTNGP04.phx.gbl... See here: http://weblogs.asp.net/justin_rogers...es/126345.aspx
Short answer, use InvokeRequired
"Rob R. Ainscough" <ro*****@pacbell.net> wrote in message
news:eU**************@TK2MSFTNGP04.phx.gbl... I'm using a BackgroundWorker to perform a file download from an ftp
site. Per good code design practices where I separate my UI code from my
core logic code (in this case my Download file method in my FileIO
class) I've established Public Event in my core logic classes along with
RaiseEvents (that will updated a progress bar on the UI side). This all
works great when I'm NOT using Threading (BackgroundWorker), however, as
soon as I introduce threading and fire off the download via a
BackgroundWorker control, I get the above error whenever I issue an
RaiseEvents in my core code.
I've gone thru the many samples and noticed that none of them separate
UI code from logic code (perhaps to save time for purpose of
demonstration). So it appears that the simple approach of using
BackGroundWorker is once again not very useful for anyone implementing
more professional code design/solutions.
It would appear to me that if I want this to work correctly, I'd have to
pass to my core logic the background worker control? Not an option.
Or, setup a public event for the BackgroundWorker control and change my
raise event to reference the event that will trigger the background
worker?
I must admit, I'm not sure why this limitation exists?
Rob