Search Results

Search found 190 results on 8 pages for 'backgroundworker'.

Page 2/8 | < Previous Page | 1 2 3 4 5 6 7 8  | Next Page >

  • Having a Backgroundworker refresh splash screen

    - by Jiri
    Hi, Would it be theoretically possible to make BackgroundWorker in a class to periodically refresh existing splash screen form, or is that impossible? (I know that it's probably bad design, but currently I do not see any better way.) Please keep in mind that: I do not want the background worker to do the loading as it would be terribly hard to implement. I can't use the inbuilt splash screen support I'm aware of DoEvents alternative but I do not want to go this path, it would very hard to implement as well, and not reliable.

    Read the article

  • BackgroundWorker Thread in IIS7 - FAIL!

    - by Darren Oster
    Just wondering if anyone has had any trouble using a BackgroundWorker Thread in a site running under IIS 7 in Integrated Pipeline mode? I am trying to use such a beast to update the database schema (admin function, obviously), and it works perfectly in Cassini, but when I deploy to IIS 7, the thread gets about one line of code in and silently ends. Is there a way to tell why a thread ended? Thanks in advance.

    Read the article

  • Java Backgroundworker: Scope of Widget to be updated unclear

    - by erlord
    Hi all, I am trying to understand the mechanism of org.jdesktop.swingx.BackgroundWorker. Their javadoc presents following example: final JLabel label; class MeaningOfLifeFinder implements BackgroundListener { public void doInBackground(BackgroundEvent evt) { String meaningOfLife = findTheMeaningOfLife(); evt.getWorker().publish(meaningOfLife); } public void process(BackgroundEvent evt) { label.setText("" + evt.getData()); } public void done(BackgroundEvent evt) {} public void started(BackgroundEvent evt) {} } (new MeaningOfLifeFinder()).execute(); Apart from the fact that I doubt the result will ever get published, I wonder how label is passed to the process method, where it is being updated. I thought it's scope is limited to the outside of the BackgroudListener implementation. Quite confused I am ... any answers for me? Thanks in advance

    Read the article

  • Events raised by BackgroundWorker not executed on expected thread

    - by Topdown
    A winforms dialog is using BackgroundWorker to perform some asynchronous operations with significant success. On occasion, the async process being run by the background worker will need to raise events to the winforms app for user response (a message that asks the user if they wish to cancel), the response of which captured in an CancelEventArgs type of the event. Being an implementation of threading, I would have expected the RaiseEvent of the worker to fire, and then the worker would continue, hence requiring me to pause the worker until the response is received. Instead however, the worker is held to wait for the code executed by the raise event to complete. It seems like method I am calling via the event call is actually on the worker thread used by the background worker, and I am surprised, since I expected to see it on the Main Thread which is where the mainform is running. Also surprisingly, there are no cross thread exceptions thrown. Can somebody please explain why this is not as I expect?

    Read the article

  • Updating a status on a Winform in BackgroundWorker

    - by Mike Wills
    I have a multi-step BackgroundWorker process. I use a marquee progress bar because several of these steps are run on a iSeries server so there isn't any good way to determine a percentage. What I am envisioning is a label with updates after every step. How would you recommend updating a label on a winform to reflect each step? Figured I would add a bit more. I call some CL and RPG programs via a stored procedure on an iSeries (or IBM i or AS/400 or a midrange computer running OS/400... er... i5/OS (damn you IBM for not keeping the same name year-to-year)). Anyway I have to wait until that step is fully complete before I can continue on the winform side. I was thinking of sending feedback to the user giving the major steps. Dumping data to iSeries Running month-end Creating reports Uploading final results I probably should have given this in the beginning. Sorry about that. I try to keep my questions general enough for others to make use of later rather than my specific task.

    Read the article

  • wpf cancel backgroundworker on application exits

    - by toni
    Hi! In my application I have a main windows and into it, in a frame I load a page. This page do a long time task when the user press a button. My problem is that when long task is being doing and the user presses the close button of the main window, the application seems to not finish because I am debugging it in VS2008 and I can see the stop button highlighted. If I want to finish I have to press stop button, the application doesn't stop the debugging automatically on application exit. I thought .NET stops automatically backgroundworkers on application exits but I am not sure after seeing this behaviour. I have tried to force and cancel background worker in unloaded event page with something like this: private void Page_Unloaded(object sender, RoutedEventArgs e) { // Is the Background Worker do some work? if (My_BgWorker != null && My_BgWorker.IsBusy) { //If it supports cancellation, Cancel It if (My_BgWorker.WorkerSupportsCancellation) { // Tell the Background Worker to stop working. My_BgWorker.CancelAsync(); } } } but with no success. After doing CancelAsync(), a few minutes after, I can see the backgroundworker finishes and raise RunWorkerCompleted and I can see the task is completed checking e.Cancelled argument in the event but after this event is exectued the application continues without exiting and I have no idea what is doing.... I set WorkerSupportsCancellation to true to support cancel at the begining. I would apreciate all answers. Thanks.

    Read the article

  • Diffrernce between BackgroundWorker.ReportProgress() and Control.Invoke()

    - by ohadsc
    What is the difference between options 1 and 2 in the following? private void BGW_DoWork(object sender, DoWorkEventArgs e) { for (int i=1; i<=100; i++) { string txt = i.ToString(); if (Test_Check.Checked) //OPTION 1 Test_BackgroundWorker.ReportProgress(i, txt); else //OPTION 2 this.Invoke((Action<int, string>)UpdateGUI, new object[] {i, txt}); } } private void BGW_ProgressChanged(object sender, ProgressChangedEventArgs e) { UpdateGUI(e.ProgressPercentage, (string)e.UserState); } private void UpdateGUI(int percent, string txt) { Test_ProgressBar.Value = percent; Test_RichTextBox.AppendText(txt + Environment.NewLine); } Looking at reflector, the Control.Invoke() appears to use: this.FindMarshalingControl().MarshaledInvoke(this, method, args, 1); whereas BackgroundWorker.Invoke() appears to use: this.asyncOperation.Post(this.progressReporter, args); (I'm just guessing these are the relevant function calls.) If I understand correctly, BGW Posts to the WinForms window its progress report request, whereas Control.Invoke uses a CLR mechanism to invoke on the right thread. Am I close? And if so, what are the repercussions of using either ? Thanks

    Read the article

  • How to properly use Object Contexts in Entity Framework using BackgroundWorker

    - by OffApps Cory
    Good day, I am developing using Entity Framework and WPF, and I am encountering some errors and I don't know why. When saving a record (using a BackgroundWorker), I set the entities change tracker to nothing (null), attach the record to a new disposable context, save it, detach, and dispose of the context. Saving a record fires and event in the MainViewModel of the program that the other ViewModels (including the one that is saving) need to refresh their entities to reflect changes. Private Sub _saveRecordWorker_DoWork(ByVal sender As Object, ByVal e As System.ComponentModel.DoWorkEventArgs) Handles _saveRecordWorker.DoWork Using MyContext As New RVShippingEntities Dim MyShipment = CType(ShipmentRecord, IEntityWithChangeTracker) MyShipment.SetChangeTracker(Nothing) MyContext.Attach(MyShipment) MyContext.Detach(ShipmentRecord) End Using End Sub The Refresh background worker is similar, but it has a Do While block to keep it from interfering with the save worker (which doesn't appear to be working; hence the post). When I save (and it subsequently refreshes) I get the following error: The calling thread cannot access this object because a different thread owns it. I thought that with the DoWhile block, it would wait (and when i step through it does) until the save thread finished, and all would be good. But it would seem that something (either the main thread or the save thread) is still doing something that is interfering. Is there a better way of doing this? Am I doing it is a goofy kludgey fashion? Any help would be appreciated. (Apparently Firefox recognized kludgey as a word. Interesting)

    Read the article

  • BackgroundWorker

    - by vdh_ant
    Hi guys I'm working on some code that calls a service. This service call could fail and if it does I want the system to try again until it works or too much time has passed. I am wondering where I am going wrong as the following code doesn't seem to be working correctly... It randomly only does one to four loops... protected virtual void ProcessAsync(object data, int count) { var worker = new BackgroundWorker(); worker.DoWork += (sender, e) => { throw new InvalidOperationException("oh shiznit!"); }; worker.RunWorkerCompleted += (sender, e) => { //If an error occurs we need to tell the data about it if (e.Error != null) { count++; System.Threading.Thread.Sleep(count * 5000); if (count <= 10) { if (count % 5 == 0) this.Logger.Fatal("LOAD ERROR - The system can't load any data", e.Error); else this.Logger.Error("LOAD ERROR - The system can't load any data", e.Error); this.ProcessAsync(data, count); } } }; worker.RunWorkerAsync(); } Cheers Anthony

    Read the article

  • Concurrent Threads in C# using BackgroundWorker

    - by Jim Fell
    My C# application is such that a background worker is being used to wait for the acknowledgement of some transmitted data. Here is some psuedo code demonstrating what I'm trying to do: UI_thread { TransmitData() { // load data for tx // fire off TX background worker } RxSerialData() { // if received data is ack, set ack received flag } } TX_thread { // transmit data // set ack wait timeout // fire off ACK background worker // wait for ACK background worker to complete // evaluate status of ACK background worker as completed, failed, etc. } ACK_thread { // wait for ack received flag to be set } What happens is that the ACK BackgroundWorker times out, and the acknowledgement is never received. I'm fairly certain that it is being transmitted by the remote device because that device has not changed at all, and the C# application is transmitting. I have changed the ack thread from this (when it was working)... for( i = 0; (i < waitTimeoutVar) && (!bAckRxd); i++ ) { System.Threading.Thread.Sleep(1); } ...to this... DateTime dtThen = DateTime.Now(); DateTime dtNow; TimeSpan stTime; do { dtNow = DateTime.Now(); stTime = dtNow - dtThen; } while ( (stTime.TotalMilliseconds < waitTimeoutVar) && (!bAckRxd) ); The latter generates a very acurate wait time, as compared to the former. However, I am wondering if removal of the Sleep function is interferring with the ability to receive serial data. Does C# only allow one thread to run at a time, that is, do I have to put threads to sleep at some time to allow other threads to run? Any thoughts or suggestions you may have would be appreciated. I am using Microsoft Visual C# 2008 Express Edition. Thanks.

    Read the article

  • BackgroundWorker acting bizarrely...

    - by vdh_ant
    Hi guys I'm working on some code that calls a service. This service call could fail and if it does I want the system to try again until it works or too much time has passed. I am wondering where I am going wrong as the following code doesn't seem to be working correctly... It randomly only does one to four loops... protected virtual void ProcessAsync(object data, int count) { var worker = new BackgroundWorker(); worker.DoWork += (sender, e) => { throw new InvalidOperationException("oh shiznit!"); }; worker.RunWorkerCompleted += (sender, e) => { //If an error occurs we need to tell the data about it if (e.Error != null) { count++; System.Threading.Thread.Sleep(count * 5000); if (count <= 10) { if (count % 5 == 0) this.Logger.Fatal("LOAD ERROR - The system can't load any data", e.Error); else this.Logger.Error("LOAD ERROR - The system can't load any data", e.Error); this.ProcessAsync(data, count); } } }; worker.RunWorkerAsync(); } Cheers Anthony

    Read the article

  • backgroundworker+wpf -> frozen window

    - by Valetudox
    -progressbar always 0% -the window is froozen (while DoWork r.) -if System.threading.thread.sleep(1) on - works perfectly whats the problem? private void btnNext_Click(object sender, RoutedEventArgs e) { this._worker = new BackgroundWorker(); this._worker.DoWork += delegate(object s, DoWorkEventArgs args) { long current = 1; long max = generalMaxSzam(); for (int i = 1; i <= 30; i++) { for (int j = i+1; j <= 30; j++) { for (int c = j+1; c <= 30; c++) { for (int h = c+1; h <= 30; h++) { for (int d = h+1; d <= 30; d++) { int percent = Convert.ToInt32(((decimal)current / (decimal)max) * 100); this._worker.ReportProgress(percent); current++; //System.Threading.Thread.Sleep(1); - it works well } } } } } }; this._worker.WorkerReportsProgress = true; this._worker.RunWorkerCompleted += delegate(object s, RunWorkerCompletedEventArgs args) { this.Close(); }; this._worker.ProgressChanged += delegate(object s, ProgressChangedEventArgs args) { this.statusPG.Value = args.ProgressPercentage; }; this._worker.RunWorkerAsync(); } <Window x:Class="SzerencsejatekProgram.Create" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Title="Létrehozás" mc:Ignorable="d" xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" Height="500" Width="700"> <DockPanel> <Button DockPanel.Dock="Right" Name="btnNext" Width="80" Click="btnNext_Click">Tovább</Button> <StatusBar DockPanel.Dock="Bottom"> <StatusBar.ItemsPanel> <ItemsPanelTemplate> <Grid> <Grid.ColumnDefinitions> <ColumnDefinition Width="*"/> <ColumnDefinition Width="Auto"/> <ColumnDefinition Width="auto"/> <ColumnDefinition Width="auto"/> </Grid.ColumnDefinitions> </Grid> </ItemsPanelTemplate> </StatusBar.ItemsPanel> <StatusBarItem Grid.Column="1"> <TextBlock Name="statusText"></TextBlock> </StatusBarItem> <StatusBarItem Grid.Column="2"> <ProgressBar Name="statusPG" Width="80" Height="18" IsEnabled="False" /> </StatusBarItem> <StatusBarItem Grid.Column="3"> <Button Name="statusB" IsCancel="True" IsEnabled="False">Cancel</Button> </StatusBarItem> </StatusBar> </DockPanel> </Window>

    Read the article

  • Update C# Chart using BackgroundWorker

    - by Mark
    I am currently trying to update a chart which is on my form to the background worker using: bwCharter.RunWorkerAsync(chart1); Which runs: private void bcCharter_DoWork(object sender, DoWorkEventArgs e) { System.Windows.Forms.DataVisualization.Charting.Chart chart = null; // Convert e.Argument to chart //.. // Converted.. chart.Series.Clear(); e.Result=chart; setChart(c.chart); } private void setChart(System.Windows.Forms.DataVisualization.Charting.Chart arg) { if (chart1.InvokeRequired) { chart1.Invoke(new MethodInvoker(delegate { setChart(arg); })); return; } chart1 = arg; } However, at the point of clearing the series, an exception is thrown. Basically, I want to do a whole lot more processing after clearing the series, which slows the GUI down completely - so wanted this in another thread. I thought that by passing it as an argument, I should be safe, but apparently not! Interestingly, the chart is on a tab page. I can run this over and over if the tabpage is in the background, but if I run this, look at the chart, hide it again, and re-run, it throws the exception. Obviously, it throws if the chart is in the foreground as well. Can anyone suggest what I can do differently? Thanks!

    Read the article

  • BackgroundWorker and Progressbar.Show()

    - by Juergen
    Hi, I am using Visual Studio 2010 and C# and try to get my progressbar to show but it doesn't work. I listen to an event. If it happens I want to do some work and show a progressbar while doing that. This is what I do: static void Main(string[] args) { ProgressForm form = new ProgressForm(); new FileWatcher(form).Start(); Application.Run(); } ProgressForm: bgWorker.DoWork += new DoWorkEventHandler(bgWorker_DoWork); private void bgWorker_DoWork(object sender, DoWorkEventArgs e) { this.Show(); .... } but nothing shows. Why isn't that working? thanks bye juergen

    Read the article

  • BackgroundWorker Help needed

    - by ChrisMuench
    I have code that does a web-service request. While doing this request I need a progress-bar to be moving independently. My problem is that I just need to say run a progress update every 1 or 2 seconds and check to see if progress of the request has been completed. NetBasisServicesSoapClient client = new NetBasisServicesSoapClient(); TransactionDetails[] transactions = new TransactionDetails[dataGridView1.Rows.Count - 1]; for (int i = 0; i < dataGridView1.Rows.Count - 1; i++) { transactions[i] = new TransactionDetails(); transactions[i].TransactionDate = (string)dataGridView1.Rows[i].Cells[2].Value; transactions[i].TransactionType = (string)dataGridView1.Rows[i].Cells[3].Value; transactions[i].Shares = (string)dataGridView1.Rows[i].Cells[4].Value; transactions[i].Pershare = (string)dataGridView1.Rows[i].Cells[5].Value; transactions[i].TotalAmount = (string)dataGridView1.Rows[i].Cells[6].Value; } CostbasisResult result = client.Costbasis(dataGridView1.Rows[0].Cells[0].Value.ToString(), dataGridView1.Rows[0].Cells[1].Value.ToString(), transactions, false, "", "", "FIFO", true); string result1 = ConvertStringArrayToString(result.Details);

    Read the article

  • C# BackgroundWorker RunWorkerCompleted Event

    - by Jim Fell
    My C# application has several background workers. Sometimes one background worker will fire off another. When the first background worker completes and the RunWorkerCompleted event is fired, on which thread will that event fire, the UI or the first background worker from which RunWorkerAsync was called? I am using Microsoft Visual C# 2008 Express Edition. Any thoughts or suggestions you may have would be appreciated. Thanks.

    Read the article

  • Inside BackgroundWorker

    - by João Angelo
    The BackgroundWorker is a reusable component that can be used in different contexts, but sometimes with unexpected results. If you are like me, you have mostly used background workers while doing Windows Forms development due to the flexibility they offer for running a background task. They support cancellation and give events that signal progress updates and task completion. When used in Windows Forms, these events (ProgressChanged and RunWorkerCompleted) get executed back on the UI thread where you can freely access your form controls. However, the logic of the progress changed and worker completed events being invoked in the thread that started the background worker is not something you get directly from the BackgroundWorker, but instead from the fact that you are running in the context of Windows Forms. Take the following example that illustrates the use of a worker in three different scenarios: – Console Application or Windows Service; – Windows Forms; – WPF. using System; using System.ComponentModel; using System.Threading; using System.Windows.Forms; using System.Windows.Threading; class Program { static AutoResetEvent Synch = new AutoResetEvent(false); static void Main() { var bw1 = new BackgroundWorker(); var bw2 = new BackgroundWorker(); var bw3 = new BackgroundWorker(); Console.WriteLine("DEFAULT"); var unspecializedThread = new Thread(() => { OutputCaller(1); SynchronizationContext.SetSynchronizationContext( new SynchronizationContext()); bw1.DoWork += (sender, e) => OutputWork(1); bw1.RunWorkerCompleted += (sender, e) => OutputCompleted(1); // Uses default SynchronizationContext bw1.RunWorkerAsync(); }); unspecializedThread.IsBackground = true; unspecializedThread.Start(); Synch.WaitOne(); Console.WriteLine(); Console.WriteLine("WINDOWS FORMS"); var windowsFormsThread = new Thread(() => { OutputCaller(2); SynchronizationContext.SetSynchronizationContext( new WindowsFormsSynchronizationContext()); bw2.DoWork += (sender, e) => OutputWork(2); bw2.RunWorkerCompleted += (sender, e) => OutputCompleted(2); // Uses WindowsFormsSynchronizationContext bw2.RunWorkerAsync(); Application.Run(); }); windowsFormsThread.IsBackground = true; windowsFormsThread.SetApartmentState(ApartmentState.STA); windowsFormsThread.Start(); Synch.WaitOne(); Console.WriteLine(); Console.WriteLine("WPF"); var wpfThread = new Thread(() => { OutputCaller(3); SynchronizationContext.SetSynchronizationContext( new DispatcherSynchronizationContext()); bw3.DoWork += (sender, e) => OutputWork(3); bw3.RunWorkerCompleted += (sender, e) => OutputCompleted(3); // Uses DispatcherSynchronizationContext bw3.RunWorkerAsync(); Dispatcher.Run(); }); wpfThread.IsBackground = true; wpfThread.SetApartmentState(ApartmentState.STA); wpfThread.Start(); Synch.WaitOne(); } static void OutputCaller(int workerId) { Console.WriteLine( "bw{0}.{1} | Thread: {2} | IsThreadPool: {3}", workerId, "RunWorkerAsync".PadRight(18), Thread.CurrentThread.ManagedThreadId, Thread.CurrentThread.IsThreadPoolThread); } static void OutputWork(int workerId) { Console.WriteLine( "bw{0}.{1} | Thread: {2} | IsThreadPool: {3}", workerId, "DoWork".PadRight(18), Thread.CurrentThread.ManagedThreadId, Thread.CurrentThread.IsThreadPoolThread); } static void OutputCompleted(int workerId) { Console.WriteLine( "bw{0}.{1} | Thread: {2} | IsThreadPool: {3}", workerId, "RunWorkerCompleted".PadRight(18), Thread.CurrentThread.ManagedThreadId, Thread.CurrentThread.IsThreadPoolThread); Synch.Set(); } } Output: //DEFAULT //bw1.RunWorkerAsync | Thread: 3 | IsThreadPool: False //bw1.DoWork | Thread: 4 | IsThreadPool: True //bw1.RunWorkerCompleted | Thread: 5 | IsThreadPool: True //WINDOWS FORMS //bw2.RunWorkerAsync | Thread: 6 | IsThreadPool: False //bw2.DoWork | Thread: 5 | IsThreadPool: True //bw2.RunWorkerCompleted | Thread: 6 | IsThreadPool: False //WPF //bw3.RunWorkerAsync | Thread: 7 | IsThreadPool: False //bw3.DoWork | Thread: 5 | IsThreadPool: True //bw3.RunWorkerCompleted | Thread: 7 | IsThreadPool: False As you can see the output between the first and remaining scenarios is somewhat different. While in Windows Forms and WPF the worker completed event runs on the thread that called RunWorkerAsync, in the first scenario the same event runs on any thread available in the thread pool. Another scenario where you can get the first behavior, even when on Windows Forms or WPF, is if you chain the creation of background workers, that is, you create a second worker in the DoWork event handler of an already running worker. Since the DoWork executes in a thread from the pool the second worker will use the default synchronization context and the completed event will not run in the UI thread.

    Read the article

  • Difference in BackgroundWorker thread access in VS2010 / .NET 4.0?

    - by Jonners
    Here's an interesting one - in VS2005 / VS2008 running against .NET 2.0 / .NET 3.0 / .NET 3.5, a BackgroundWorker thread may not directly update controls on a WinForms form that initiated that thread - you'll get a System.InvalidOperationException out of the BackgroundWorker stating "Cross-thread operation not valid: Control 'thecontrol' accessed from a thread other than the thread it was created on". I remember hitting this back in 2004 or so when I first started writing .NET WinForms apps with background threads. There are several ways around the problem - this is not a question asking for that answer. I've been told recently that this kind of operation is now allowed when written in VS2010 / .NET 4.0. This seems unlikely to me, since this kind of object access restriction has always been a fairly fundamental part of thread-safe programming. Allowing a BackgroundWorker thread direct access to objects owned not by itself but by its parent UI form seems contrary to that principle. A trawl through the .NET 4.0 docs hasn't revealed any obvious changes that could account for this behaviour. I don't have VS2010 / .NET 4.0 to test this out - does anyone who has access to that toolset know for sure whether the model has changed to allow that kind of thread interaction? I'd like to either take advantage of it in future, or deploy the cluestick. ;)

    Read the article

  • How can I pause a BackgroundWorker? Or something similar...

    - by juan
    I was using a BackgroundWorker to download some web sites by calling WebClient.DownloadString inside a loop. I wanted the option for the user to cancel in the middle of downloading stuff, so I called CancelAsync whenever I found that CancellationPending was on in the middle of the loop. But now I noticed that the function DownloadString kinda freezes sometimes, so I decided to use DownloadStringAsync instead (all this inside the other thread created with BackgroundWorker). An since and don't want to rewrite my whole code by having to exit the loop and the function after calling DownloadStringAsync, I made a while loop right after calling it that does nothing but checks for a variable bool Stop that I turn true either when the DownloadStringCompleted event handler is called or when the user request to cancel the operation. Now, the weird thing is that it works fine on the debug version, but on the release one, the program freezes in the while loop like if it were the main thread.

    Read the article

  • How can I debug an unhandled exception in code called from a BackgroundWorker?

    - by SkippyFire
    I am running some import code asynchronously from a simple WinForms app using a BackgroundWorker object and its DoAsync() method. I had a problem where I didn't know that exceptions were being thrown and the thread was prematurely dying. I eventually discovered this, and now know when an exception is thrown after reading Unhandled exceptions in BackgroundWorker. However, I still have a problem while debugging. How do I debug this code? I guess I could run it in a test app that doesn't use a BackgrounWorker, but is there a way to debug this as is? If I step through the code that actually throws the exception, I just get kicked out the step-through when the exception occurs. Re-throwing the exception from the RunWorkerCompletedEventHandler naturally doesn't help much either. Any ideas!? Thanks in advance!

    Read the article

  • Using the BackgroundWorker in a Silverlight MVVM Application

    - by axshon
    With Silverlight 4 and the Entity Framework you get a lot of work done on your behalf in terms of standard UI CRUD-style operations. Validations and I/O are pretty easy to accommodate out of the box. But sometimes you need to perform some long running tasks either on the client or on the server via service calls. To prevent your UI from hanging and annoying your users, you should consider placing these operations on a background thread. The BackgroundWorker object is the perfect solution for this...(read more)

    Read the article

  • Using INotifyPropertyChanged in background threads

    - by digitaldias
    Following up on a previous blog post where I exemplify databinding to objects, a reader was having some trouble with getting the UI to update. Here’s the rough UI: The idea is, when pressing Start, a background worker process starts ticking at the specified interval, then proceeds to increment the databound Elapsed value. The problem is that event propagation is limeted to current thread, meaning, you fire an event in one thread, then other threads of the same application will not catch it. The Code behind So, somewhere in my ViewModel, I have a corresponding bethod Start that initiates a background worker, for example: public void Start( ) { BackgroundWorker backgroundWorker = new BackgroundWorker( ); backgroundWorker.DoWork += IncrementTimerValue; backgroundWorker.RunWorkerAsync( ); } protected void IncrementTimerValue( object sender, DoWorkEventArgs e ) { do { if( this.ElapsedMs == 100 ) this.ElapsedMs = 0; else this.ElapsedMs++; }while( true ); } Assuming that there is a property: public int ElapsedMs { get { return _elapsedMs; } set { if( _elapsedMs == value ) return; _elapsedMs = value; NotifyThatPropertyChanged( "ElapsedMs" ); } } The above code will not work. If you step into this code in debug, you will find that INotifyPropertyChanged is called, but it does so in a different thread, and thus the UI never catches it, and does not update. One solution Knowing that the background thread updates the ElapsedMs member gives me a chance to activate BackgroundWorker class’ progress reporting mechanism to simply alert the main thread that something has happened, and that it is probably a good idea to refresh the ElapsedMs binding. public void Start( ) { BackgroundWorker backgroundWorker = new BackgroundWorker( ); backgroundWorker.DoWork += IncrementTimerValue; // Listen for progress report events backgroundWorker.WorkerReportsProgress = true; // Tell the UI that ElapsedMs needs to update backgroundWorker.RunWorkerCompleted += ( sender, e ) => { NotifyThatPropertyChanged( "ElapsedMs" ) }; backgroundWorker.RunWorkerAsync( ); } protected void IncrementTimerValue( object sender, DoWorkEventArgs e ) { do { if( this.ElapsedMs == 100 ) this.ElapsedMs = 0; else this.ElapsedMs++; // report any progress ( sender as BackgroundWorker ).ReportProgress( 0 ); }while( true ); } What happens above now is that I’ve used the BackgroundWorker cross thread mechanism to alert me of when it is ok for the UI to update it’s ElapsedMs field. Because the property itself is being updated in a different thread, I’m removing the NotifyThatPropertyChanged call from it’s Set method, and moving that responsability to the anonymous method that I created in the Start method. This is one way of solving the issue of having a background thread update your UI. I would be happy to hear of other cross-threading mechanisms for working in a MCP/MVC/MVVM pattern.

    Read the article

  • Why does the BackgroundWorker in WPF need Thread.Sleep to update UI controls?

    - by user364060
    namespace WpfApplication1 { /// <summary> /// Interaction logic for Window1.xaml /// </summary> public partial class Window1 : Window { BackgroundWorker bgWorker; Action<int> myProgressReporter; public Window1() { InitializeComponent(); bgWorker = new BackgroundWorker(); bgWorker.DoWork += bgWorker_Task; bgWorker.RunWorkerCompleted += myWorker_RunWorkerCompleted; // hook event to method bgWorker.ProgressChanged += bgWorker_ReportProgress; // hook the delegate to the method myProgressReporter = updateProgress; bgWorker.WorkerReportsProgress = true; } private void myWorker_RunWorkerCompleted(object sender, System.ComponentModel.RunWorkerCompletedEventArgs e) { object result; result = e.Result; MessageBox.Show(result.ToString()); progressBar1.Value = 0; button1.IsEnabled = true; } private void bgWorker_ReportProgress(object sender, ProgressChangedEventArgs e) { System.Windows.Threading.Dispatcher disp = button1.Dispatcher; disp.BeginInvoke(myProgressReporter,e.ProgressPercentage); //Dispatcher.BeginInvoke(myProgressReporter, DispatcherPriority.Normal, e.ProgressPercentage); } private void updateProgress(int progressPercentage) { progressBar1.Value = progressPercentage; } private void bgWorker_Task(Object sender, DoWorkEventArgs e) { int total = 1000; for (int i = 1; i <= total; i++) { if (bgWorker.WorkerReportsProgress) { int p = (int)(((float)i / (float)total) * 100); bgWorker.ReportProgress(p); } Thread.Sleep(1); // Without Thread.Sleep(x) the main thread freezes or gives stackoverflow exception, } e.Result = "Completed"; } private void button1_Click(object sender, RoutedEventArgs e) { if(!bgWorker.IsBusy) bgWorker.RunWorkerAsync("This is a background process"); button1.IsEnabled = false; } } }

    Read the article

  • .NET Backgroundworker - Is there no way to let exceptions pass back normally to main thread?

    - by Greg
    Hi, QUESTION: Re use of .NET Backgroundworker, is there not a way to let exceptions pass back normally to main thread? BACKGROUND: Currently in my WinForms application I have generic exception handle that goes along the lines of, if (a) a custom app exception then present to user, but don't exit program, and (b) if other exception then present and then exit application The above is nice as I can just throw the appropriate exception anywhere in the application and the presentation/handling is handled generically

    Read the article

  • Page not rendering until BackgroundWorker.RunWorkerAsync completes

    - by brainimus
    I have an aspx page that on a button click creates a BackgroundWorker and then calls the RunWorkerAsync method. In my aspx file I have set Async='true' but when I run the application and click the button it appears as though the page waits to refresh until the processing of the BackgroundWorker is done. How do I get control to return to the page (and have the page refresh) after the BackgroundWorker is created and started? BackgroundWorker worker = new BackgroundWorker(); worker.DoWork += RunJob; worker.RunWorkerCompleted += JobCompleted; worker.RunWorkerAsync();

    Read the article

< Previous Page | 1 2 3 4 5 6 7 8  | Next Page >