Search Results

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

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

  • BackgroundWorker.ReportProgress() not updating property and locking up the UI

    - by Willem
    i am using a backgroundWorker to do a long running operation: BackgroundWorker backgroundWorker = new BackgroundWorker() { WorkerSupportsCancellation = true, WorkerReportsProgress = true }; backgroundWorker.RunWorkerCompleted += delegate(object s, RunWorkerCompletedEventArgs args) { }; backgroundWorker.ProgressChanged += delegate(object s, ProgressChangedEventArgs args) { someViewModel.SomeProperty.Add((SomeObject)args.UserState); }; backgroundWorker.DoWork += delegate(object s, DoWorkEventArgs args) { someViewModel.SomeList.ForEach(x => { someViewModel.SomeInterface.SomeMethod(backgroundWorker, someViewModel, someViewModel.SomeList, x); }); }; backgroundWorker.RunWorkerAsync(); Then in SomeInterface.SomeMethod: public void SomeMethod(BackgroundWorker backgroundWorker, SomeViewModel someViewModel//....) { //Filtering happens backgroundWorker.ReportProgress(0, someObjectFoundWhileFiltering); } So, when it comes to: backgroundWorker.ProgressChanged += delegate(object s, ProgressChangedEventArgs args) { someViewModel.SomeProperty.Add((SomeObject)args.UserState);//Adding the found object to the Property in the VM }; On the line someViewModel.SomeProperty.Add((SomeObject)args.UserState);, the set on the Property is not firering and the UI just locks up. What am i doing wrong? Is this the correct way to update the UI thread?

    Read the article

  • Proper way to Dispose of a BackGroundWorker

    - by galford13x
    Would this be a proper way to dispose of a BackGroundWorker? I'm not sure if it is necesary to remove the events before calling .Dispose(). Also is calling .Dispose() inside the RunWorkerCompleted delegate ok to do? public void RunProcessAsync(DateTime dumpDate) { BackgroundWorker worker = new BackgroundWorker(); worker.RunWorkerCompleted += new RunWorkerCompletedEventHandler(worker_RunWorkerCompleted); worker.DoWork += new DoWorkEventHandler(worker_DoWork); worker.RunWorkerAsync(dumpDate); } void worker_DoWork(object sender, DoWorkEventArgs e) { // Do Work here } void worker_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e) { BackgroundWorker worker = sender as BackgroundWorker; worker.RunWorkerCompleted -= new RunWorkerCompletedEventHandler(worker_RunWorkerCompleted); worker.DoWork -= new DoWorkEventHandler(worker_DoWork); worker.Dispose(); }

    Read the article

  • Displaying wait cursor in while backgroundworker is running

    - by arc1880
    During the start of my windows application, I have to make a call to a web service to retrieve some default data to load onto my application. During the load of the form, I run a backgroundworker to retrieve this data. I want to display the wait cursor until this data is retrieved. How would I do this? I've tried setting the wait cursor before calling the backgroundworker to run. When I report a progress of 100 then I set it back to the default cursor. The wait cursor comes up but when I move the mouse it disappears. Environment: Windows 7 Pro 64-bit VS2010 C# .NET 4.0 Windows Forms EDIT: I am setting the cursor the way Jay Riggs suggested. It only works if I don't move the mouse. **UPDATE: I have created a button click which does the following: When I do the button click and move my mouse, the wait cursor appears regardless if I move my mouse or not. void BtnClick() { Cursor = Cursors.WaitCursor; Thread.Sleep(8000); Cursor = Cursors.Default; } If I do the following: I see the wait cursor and when I move the mouse it disappears inside the form. If I move to my status bar or the menu bar the wait cursor appears. Cursor = Cursors.WaitCursor; if (!backgroundWorker.IsBusy) { backGroundWorker.RunWorkerAsync(); } void backGroundWorkerDoWork(object sender, DoWorkEventArgs e) { Thread.Sleep(8000); } void backGroundWorkerCompleted(object sender, RunWorkerCompletedEventArgs e) { Cursor = Cursors.Default; } If I do the following: The wait cursor appears and when I move the mouse it still appears but will sometimes flicker off and on when moving in text fields. if (!backgroundWorker.IsBusy) { backGroundWorker.RunWorkerAsync(); } void backGroundWorkerDoWork(object sender, DoWorkEventArgs e) { UseWaitCursor = true; Thread.Sleep(8000); } void backGroundWorkerCompleted(object sender, RunWorkerCompletedEventArgs e) { UseWaitCursor = false; }

    Read the article

  • Backgroundworker abort

    - by MazarD
    Hi, I recently tried to use backgroundworker instead of "classic" threads and I'm realizing that it's causing, at least for me, more problems than solutions. I have a backgroundworker running a synchronous read (in this case from serialPort) and getting blocked around 30 seconds in 1 code line, then cancellationpending isn't the solution. I'm seeing that if the application gets closed at this point (either with the cross button and Application.Exit()) the process keeps zombie forever. I need a way to force abort or to kill the backgroundworker thread.

    Read the article

  • BackgroundWorker might be causing my application to hang

    - by alexD
    I have a Form that uses a BackgroundWorker to execute a series of tests. I use the ProgressChanged event to send messages to the main thread, which then does all of the updates on the UI. I've combed through my code to make sure I'm not doing anything to the UI in the background worker. There are no while loops in my code and the BackgroundWorker has a finite execution time (measured in seconds or minutes). However, for some reason when I lock my computer, often times the application will be hung when I log back in. The thing is, the BackgroundWorker isn't even running when this happens. The reason I believe it is related to the BackgroundWorker though is because the form only hangs when the BackgroundWorker has been executed since the application was loaded (it only runs when given a certain user input). I pass this thread a List of TreeNodes from a TreeView in my UI through the RunWorkerAsync method, but I only read those nodes in the worker thread..any modifications I make to them is done in the UI thread through the progressChanged event. I do use Thread.Sleep in my worker thread to execute tests at timed intervals (which involves sending messages over a TCP socket, which was not created in the worker thread). I am completely perplexed as to why my application might be hanging. I'm sure I'm doing something 'illegal' somewhere, I just don't know what.

    Read the article

  • C# update GUI continuously from backgroundworker.

    - by Qrew
    I have created a GUI (winforms) and added a backgroundworker to run in a separate thread. The backgroundworker needs to update 2 labels continuously. The backgroundworker thread should start with button1 click and run forever. class EcuData { public int RPM { get; set; } public int MAP { get; set; } } private void button1_Click(object sender, EventArgs e) { EcuData data = new EcuData { RPM = 0, MAP = 0 }; BackWorker1.RunWorkerAsync(data); } private void BackWorker1_DoWork(object sender, DoWorkEventArgs e) { EcuData argumentData = e.Argument as EcuData; int x = 0; while (x<=10) { // // Code for reading in data from hardware. // argumentData.RPM = x; //x is for testing only! argumentData.MAP = x * 2; //x is for testing only! e.Result = argumentData; Thread.Sleep(100); x++; } private void BackWorker1_RunWorkerCompleted_1(object sender, RunWorkerCompletedEventArgs e) { EcuData data = e.Result as EcuData; label1.Text = data.RPM.ToString(); label2.Text = data.MAP.ToString(); } } The above code just updated the GUI when backgroundworker is done with his job, and that's not what I'm looking for.

    Read the article

  • BackgroundWorker not working with TeamCity NUnit runner

    - by Catalin DICU
    I'm using NUnit to test View Models in a WPF 3.5 application and I'm using the BackgroundWorker class to execute asynchronous commands.The unit test are running fine with the NUnit runner or ReSharper runner but fail on TeamCity 5.1 server. How is it implemented : I'm using a ViewModel property named IsBusy and set it to false on BackgroundWorker.RunWorkerCompleted event. In my test I'm using this method to wait for the BackgroundWorker to finish : protected void WaitForBackgroundOperation(ViewModel viewModel) { int count = 0; while (viewModel.IsBusy) { RunBackgroundWorker(); if (count++ >= 100) { throw new Exception("Background operation too long"); } Thread.Sleep(100); } } private static void RunBackgroundWorker() { Dispatcher.CurrentDispatcher.Invoke(DispatcherPriority.Background, new ThreadStart(delegate { })); System.Windows.Forms.Application.DoEvents(); } Well, sometimes it works and sometimes it hangs the build. I suppose it's the Application.DoEvents() but I don't know why...

    Read the article

  • BackgroundWorker vs background Thread

    - by freddy smith
    I have a stylistic question about the choice of background thread implementation I should use on a windows form app. Currently I have a BackgroundWorker on a form that has an infinite (while(true)) loop. In this loop I use WaitHandle.WaitAny to keep the thread snoozing until something of interest happens. One of the event handles I wait on is a "stopthread" event so that I can break out of the loop. This event is signaled when from my overridden Form.Dispose(). I read somewhere that BackgroundWorker is really intended for operations that you dont want to tie up the UI with and have an finite end - like downloading a file, or processing a sequence of items. In this case the "end" is unknown and only when the window is closed. Therefore would it be more appropriate for me to use a background Thread instead of BackgroundWorker for this purpose?

    Read the article

  • Unhandled exceptions in BackgroundWorker

    - by edg
    My WinForms app uses a number of BackgroundWorker objects to retrieve information from a database. I'm using BackgroundWorker because it allows the UI to remain unblocked during long-running database queries and it simplifies the threading model for me. I'm getting occasional DatabaseExceptions in some of these background threads, and I have witnessed at least one of these exceptions in a worker thread while debugging. I'm fairly confident these exceptions are timeouts which I suppose its reasonable to expect from time to time. My question is about what happens when an unhandled exception occurs in one of these background worker threads. I don't think I can catch an exception in another thread, but can I expect my WorkerCompleted method to be executed? Is there any property or method of the BackgroundWorker I can interrogate for exceptions?

    Read the article

  • Canceling BackgroundWorker within the Thread

    - by Mike Wills
    I have a longer running multi-step process using BackgroundWorker and C#. I need to be sure that each step is completed successfully before moving on to the next step. I have seen many references to letting the BackgroundWorker catch errors and canceling from clicking on a Cancel button, but I want to check for an error myself and then gracefully end the process. Do I treat it just like someone clicked the cancel button, or is there another way?

    Read the article

  • BackgroundWorker From ASP.Net Application

    - by Kevin
    We have an ASP.Net application that provides administrators to work with and perform operations on large sets of records. For example, we have a "Polish Data" task that an administrator can perform to clean up data for a record (e.g. reformat phone numbers, social security numbers, etc.) When performed on a small number of records, the task completes relatively quickly. However, when a user performs the task on a larger set of records, the task may take several minutes or longer to complete. So, we want to implement these kinds of tasks using some kind of asynchronous pattern. For example, we want to be able to launch the task, and then use AJAX polling to provide a progress bar and status information. I have been looking into using the BackgroundWorker class, but I have read some things online that make me pause. I would love to get some additional advice on this. For example, I understand that the BackgroundWorker will actually use the thread pool from the current application. In my case, the application is an ASP.Net web site. I have read that this can be a problem because when the application recycles, the background workers will be terminated. Some of the jobs I mentioned above may take 3 minutes, but others may take a few hours. Also, we may have several hundred administrators all performing similar operations during the day. Will the ASP.Net application thread pool be able to handle all of these background jobs efficiently while still performing it's normal request processing? So, I am trying to determine if using the BackgroundWorker class and approach is right for our needs. Should I be looking at an alternative approach? Thanks and sorry for such a long post! Kevin

    Read the article

  • Accessing class member variables inside a BackgroundWorker's DoWork event handler, and other Backgro

    - by Justin
    Question 1 In the DoWork event handler of a BackgroundWorker, is it safe to access (for both reading and writing) member variables of the class that contains the BackgroundWorker? Is it safe to access other variables that are not declared inside the DoWork event handler itself? Obviously DoWork should not be accessing any UI objects of, say, a WinForms application, as the UI should only be updated from the UI thread. But what about accessing other (not UI-related) member variables? The reason why I ask is that I've seen the occasional comment come up while Googling saying that accessing member variables is not allowed. The only example I can find at the moment is a comment on this MSDN page, which says: Note, that the BGW can cause exceptions if it attempts to access or modify class level variables. All data must be passed to it by delegates and events. And also: NEVER. NEVER. Never try to reference variables not declared inside of DoWork. It may seem to work at times, but in reality you are just getting lucky. As far as I know, MSDN itself does not document any restrictions of this kind (although if I'm wrong, I'd appreciate a link). But comments like these do seem to pop up every now and again. (Of course if DoWork does access/modify a member variable that could be accessed/modified by the main thread at the same time, it is necessary to synchronise access to that field, eg by using a locking object. But the above quotes seem to require a blanket ban of accessing member variables, rather than just synchronising access!) Question 2 To make this into a more general question, are there any other (not documented?) restrictions that users of the BackgroundWorker should be aware of, aside from the above? Any "best practices", perhaps?

    Read the article

  • BackgroundWorker and foreach loop

    - by tomfox66
    I have to process a loop with backgroundworkers. Before I start a new loop iteration I need to wait until the provious backgroundworker has finished. A while loop inside my foreach loop with isbusy flag doesn's seem like a good idea to me. How should I design this loop so it waits for the bg-worker to end before iterating the loop public void AutoConnect() { string[] HardwareList = new string[] { "d1", "d4", "ds1_2", "ds4_2" }; foreach (string HW in HardwareList) { if (backgroundWorker1.IsBusy != true) { backgroundWorker1.RunWorkerAsync(HW); // Wait here until backgroundWorker1 finished } } } private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e) { BackgroundWorker worker = sender as BackgroundWorker; string FileName = e.Argument as string; try { if ((worker.CancellationPending == true)) { e.Cancel = true; } else { // Time consuming operation ParseFile(Filename); } } catch { } } private void backgroundWorker1_ProgressChanged(object sender, ProgressChangedEventArgs e) { label1.Text = e.ProgressPercentage.ToString() + " lines"; } private void backgroundWorker1_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e) { if(e.Cancelled == true) { //this.tbProgress.Text = "Canceled!"; } else if(!(e.Error == null)) { //this.tbProgress.Text = ("Error: " + e.Error.Message); } else { label1.text = "Done!"; } }

    Read the article

  • How to run batched WCF service calls in Silverlight BackgroundWorker

    - by Simon
    Is there any existing plumbing to run WCF calls in batches in a BackgroundWorker? Obviously since all Silverlight WCF calls are async - if I run them all in a backgroundworker they will all return instantly. I just don't want to implement a nasty hack if theres a nice way to run service calls and collect the results. Doesnt matter what order they are done in All operations are independent I'd like to have no more than 5 items running at once Edit: i've also noticed (when using Fiddler) that no more than about 7 calls are able to be sent at any one time. Even when running out-of-browser this limit applies. Is this due to my default browser settings - or configurable also. obviously its a poor man's solution (and not suitable for what i want) but something I'll probably need to take account of to make sure the rest of my app remains responsive if i'm running this as a background task and don't want it using up all my connections.

    Read the article

  • impersonation and BackgroundWorker

    - by Lucian D
    Hello guys, I have a little bit of a problem when trying to use the BackgroundWorker class with impersonation. Following the answers from google, I got this code to impersonate public class MyImpersonation{ WindowsImpersonationContext impersonationContext; [DllImport("advapi32.dll")] public static extern int LogonUserA(String lpszUserName, String lpszDomain, String lpszPassword, int dwLogonType, int dwLogonProvider, ref IntPtr phToken); [DllImport("advapi32.dll", CharSet = CharSet.Auto, SetLastError = true)] public static extern int DuplicateToken(IntPtr hToken, int impersonationLevel, ref IntPtr hNewToken); [DllImport("advapi32.dll", CharSet = CharSet.Auto, SetLastError = true)] public static extern bool RevertToSelf(); [DllImport("kernel32.dll", CharSet = CharSet.Auto)] public static extern bool CloseHandle(IntPtr handle); public bool impersonateValidUser(String userName, String domain, String password) { WindowsIdentity tempWindowsIdentity; IntPtr token = IntPtr.Zero; IntPtr tokenDuplicate = IntPtr.Zero; if (RevertToSelf()) { if (LogonUserA(userName, domain, password, LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT, ref token) != 0) { if (DuplicateToken(token, 2, ref tokenDuplicate) != 0) { tempWindowsIdentity = new WindowsIdentity(tokenDuplicate); impersonationContext = tempWindowsIdentity.Impersonate(); if (impersonationContext != null) { CloseHandle(token); CloseHandle(tokenDuplicate); return true; } } } } if (token != IntPtr.Zero) CloseHandle(token); if (tokenDuplicate != IntPtr.Zero) CloseHandle(tokenDuplicate); return false; } } It worked really well until I've used it with the BackgroundWorker class. In this case, I've added a impersonation in the the code that runs asynchronously. I have no errors, but the issue I'm having is that the impersonation does not work when it is used in the async method. In code this looks something like this: instantiate a BGWorker, and add an event handler to the DoWork event: _bgWorker = new BackgroundWorker(); _bgWorker.DoWork += new DoWorkEventHandler(_bgWorker_DoWork); in the above handler, a impersonation is made before running some code. private void _bgWorker_DoWork(object sender, DoWorkEventArgs e) { MyImpersonation myImpersonation = new MyImpersonation(); myImpersonation.impersonateValidUser(user, domain, pass) //run some code... myImpersonation.undoImpersonation(); } the code is launched with BGWorker.RunWorkerAsync(); As I said before, no error is thrown, only that the code acts as if I did't run any impersonation, that is with it's default credentials. Moreover, the impersonation method returns true, so the impersonation took place at a certain level, but probably not on the current thread. This must happen because the async code runs on another thread, so there must be something that needs to be added to the MyImpersonation class. But what?? :) Thanks in advance, Lucian

    Read the article

  • C#: BackgroundWorker cloning resources?

    - by Dav
    The problem I've been struggling with this partiular problem for two days now and just run out of ideas. A little... background: we have a WinForms app that needs to access a database, construct a list of related in-memory objects from that data, and then display on a DataGridView. Important point is that we first populate an app-wide cache (List), and then create a mirror of the cache local to the form on which the DGV lives (using List constructor param). Because fetching the data takes a good few seconds (DB sits on a LAN server) to load, we decided to use a BackgroundWorker, and only refresh the DGV once the data is loaded. However, it seems that doing the loading via a BGW results in some memory leak... or an error on my part. When loaded using a blocking method call, the app consumes about 30MB of RAM; with a BGW this jumps to 80MB! While it may not seem as much anyway, our clients are not too happy about it. Relevant code Form private void MyForm_Load(object sender, EventArgs e) { MyRepository.Instance.FinishedEvent += RefreshCache; } private void RefreshCache(object sender, EventArgs e) { dgvProducts.DataSource = new List<MyDataObj>(MyRepository.Products); } Repository private static List<MyDataObj> Products { get; set; } public event EventHandler ProductsLoaded; public void GetProductsSync() { List<MyDataObj> p; using (MyL2SDb db = new MyL2SDb(MyConfig.ConnectionString)) { p = db.PRODUCTS .Select(p => new MyDataObj {Id = p.ID, Description = p.DESCR}) .ToList(); } Products = p; // tell the form to refresh UI if (ProductsLoaded != null) ProductsLoaded(this, null); } public void GetProductsAsync() { using (BackgroundWorker myWorker = new BackgroundWorker()) { myWorker.DoWork += delegate { List<MyDataObj> p; using (MyL2SDb db = new MyL2SDb(MyConfig.ConnectionString)) { p = db.PRODUCTS .Select(p => new MyDataObj {Id = p.ID, Description = p.DESCR}) .ToList(); } Products = p; }; // tell the form to refresh UI when finished myWorker.RunWorkerCompleted += GetProductsCompleted; myWorker.RunWorkerAsync(); } } private void GetProductsCompleted(object sender, RunWorkerCompletedEventArgs e) { if (ProductsLoaded != null) ProductsLoaded(this, null); } End! GetProductsSync or GetProductsAsync are called on the main thread, not shown above. Could it be that the GarbageCollector just gets lost with two threads? Or is it the task manager that shows incorrect values? Will be greateful for any responses, suggestions, criticism.

    Read the article

  • Long Running Stored Proc - Report Progress Using BackgroundWorker & Timer

    - by daveywc
    While a long running stored proc (RMR_Seek) is executing (called via a Linq-To-SQL data context) I am trying to call another stored proc (RMR_GetLatestModelMessage) to check a table for the latest status message. The long running stored proc updates the table in question with status messages as it executes. I want to display the status message on a message panel to advise the user of the status of the execution of Proc_A. For various reasons it is not possible to determine how long RMR_Seek will take to execute so a progress bar with percentage increments is not feasible. I thought I'd found the way to do it by calling the long running stored proc from in a BackgroundWorker process DoWork event handler. This worked fine and allowed me to update my message panel with some dummy status messages that were NOT obtained via Proc_B while Proc_A was running. However now that I have tried to implement this fully by calling Proc_B to obtain the status messages I am running into problems that seem to be related to the mix of the backgroundworker and my System.Windows.Forms.Timer. An extract of the code I am using is below. I have tried many different ways around this but each one seems to present its own set of problems. The code below is problematic in the bw_DoWork event. The RMR_Seek stored proc gets called but does not execute properly - it also seems to be inconsistent as to whether _IsCompleted gets set to true. I'm sure there is a better way to achieve what I am trying to do. private bool _IsCompleted; private void RunRevenueSeek() { if (_SelectedModel == null) { MessageBox.Show("Please select a model from the list and try again.", "Model Generation", MessageBoxButtons.OK, MessageBoxIcon.Information); } else { var bw = new BackgroundWorker(); bw.DoWork += new DoWorkEventHandler(bw_DoWork); ProgressPanelControl.Visible = true; _IsCompleted = false; MessageTimer.Start(); // Has an interval of 3000 bw.RunWorkerAsync(); ProgressLabelControl.Text = "Refreshing Data"; this.Update(); ...more code goes here } } private void bw_DoWork(object sender, DoWorkEventArgs e) { using (var dc = new RevMdlrDataClassesDataContext()) { dc.CommandTimeout = 300; dc.RMR_Seek(_SelectedModel.ModelSet_ID); _IsCompleted = true; } } private void MessageTimer_Tick(object sender, EventArgs e) { string message = ""; if (_IsCompleted) { MessageTimer.Stop(); } else { using (var dc = new RevMdlrDataClassesDataContext()) { dc.CommandTimeout = 300; dc.RMR_GetLatestModelMessage(_SelectedModel.ModelSet_ID, ref message); ProgressLabelControl.Text = message; this.Update(); } } }

    Read the article

  • BackgroundWorker RunWorkerCompleted in a Component

    - by Sphynx
    I'm familiar with the following: "If the operation raises an exception that your code does not handle, the BackgroundWorker catches the exception and passes it into the RunWorkerCompleted event handler, where it is exposed as the Error property of System.ComponentModel.RunWorkerCompletedEventArgs. If you are running under the Visual Studio debugger, the debugger will break at the point in the DoWork event handler where the unhandled exception was raised." However, I've encountered a weird glitch. In my component, there's an instance of BackgroundWorker. Even though it's not running in the debugger, the exception remains unhandled by the worker. Even simplified code produces an unhandled exception (and RunWorkerCompleted doesn't fire): Throw New ArgumentException("Test") The main thing is the code of RunWorkerComplete: RaiseEvent UpdateComplete(Me, New AsyncCompletedEventArgs(e.Error, e.Cancelled, e.Result)) I need the component to expose the worker exception through a public event. If I remove the RaiseEvent call, the exception becomes handled by the worker, and accessible through e.Error. Apparently, raising an event causes the worker to miss the exception. How can that be?

    Read the article

  • C# BackgroundWorker skips DoWork and goes straight to RunWorkerCompleted

    - by mr_man
    I'm new with C# so go easy on me! So far - I have a console app that listens for client connections and replies to the client accordingly. I also have a WPF form with a button and a text box. The button launches some code to connect to the server as a BackgroundWorker, which then waits for a response before appending it to the end of the text box. This works great, once. Sometimes twice. But then it kept crashing - turns out that the DoWork block wasn't being called at all and it was going straight to RunWorkerCompleted. Of course, the .result is blank so trying to convert it to a string fails. Is this a rookie mistake? I have tried searching the internet for various ways of saying the above but haven't come across anything useful... This is the code so far: http://pastebin.com/ZQvCFqxN - there are so many debug outputs from me trying to figure out exactly what went wrong. This is the result of the debug outputs: http://pastebin.com/V412mppX Any help much appreciated. Thanks! EDIT: The relevant code post-fix (thanks to Patrick Quirk below) is: public void dorequest(string query) { request = new BackgroundWorker(); request.WorkerSupportsCancellation = true; request.WorkerReportsProgress = true; request.ProgressChanged += request_ProgressChanged; request.DoWork += request_DoWork; request.RunWorkerCompleted += request_RunWorkerCompleted; request.RunWorkerAsync(query); }

    Read the article

  • C# - update variable based upon results from backgroundworker

    - by Bruce
    I've got a C# program that talks to an instrument (spectrum analyzer) over a network. I need to be able to change a large number of parameters in the instrument and read them back into my program. I want to use backgroundworker to do the actual talking to the instrument so that UI performance doesn't suffer. The way this works is - 1) send command to the instrument with new parameter value, 2) read parameter back from the instrument so I can see what actually happened (for example, I try to set the center frequency above the max that the instrument will handle and it tells me what it will actually handle), and 3) update a program variable with the actual value received from the instrument. Because there are quite a few parameters to be updated I'd like to use a generic routine. The part I can't seem to get my brain around is updating the variable in my code with what comes back from the instrument via backgroundworker. If I used a separate RunWorkerCompleted event for each parameter I could hardwire the update directly to the variable. I'd like to come up with a way of using a single routine that's capable of updating any of the variables. All I can come up with is passing a reference number (different for each parameter) and using a switch statement in the RunWorkerCompleted handler to direct the result. There has to be a better way. Thanks for your help.

    Read the article

  • BackgroundWorker Not working in VSTO

    - by Chris
    I have a background worker. Before I invoke the worker I disable a button and make a gif visible. I then invoke the runworkerasync method and it runs fine until comleteion. On the 'RunWorkerCompleted()' I get a cross thread error. Any idea why? private void buttonRun_Click(object sender, EventArgs e) { if (comboBoxFiscalYear.SelectedIndex != -1 && !string.IsNullOrEmpty(textBoxFolderLoc.Text)) { try { u = new UpdateDispositionReports( Convert.ToInt32(comboBoxFiscalYear.SelectedItem.ToString()) , textBoxFolderLoc.Text , Properties.Settings.Default.TemplatePath , Properties.Settings.Default.ConnStr); this.buttonRun.Enabled = false; this.pictureBox1.Visible = true; BackgroundWorker bw = new BackgroundWorker(); bw.DoWork += new DoWorkEventHandler(bw_DoWork); bw.RunWorkerCompleted += new RunWorkerCompletedEventHandler(bw_RunWorkerCompleted); bw.RunWorkerAsync(); //backgroundWorker1.RunWorkerAsync(); } catch (Exception ex) { MessageBox.Show("Unable to process.\nError:" + ex.Message, Properties.Settings.Default.AppName); } } } void bw_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e) { buttonRun.Enabled = true; pictureBox1.Visible = false; } void bw_DoWork(object sender, DoWorkEventArgs e) { u.Execute(); }

    Read the article

  • update variable based upon results from .NET backgroundworker

    - by Bruce
    I've got a C# program that talks to an instrument (spectrum analyzer) over a network. I need to be able to change a large number of parameters in the instrument and read them back into my program. I want to use backgroundworker to do the actual talking to the instrument so that UI performance doesn't suffer. The way this works is - 1) send command to the instrument with new parameter value, 2) read parameter back from the instrument so I can see what actually happened (for example, I try to set the center frequency above the max that the instrument will handle and it tells me what it will actually handle), and 3) update a program variable with the actual value received from the instrument. Because there are quite a few parameters to be updated I'd like to use a generic routine. The part I can't seem to get my brain around is updating the variable in my code with what comes back from the instrument via backgroundworker. If I used a separate RunWorkerCompleted event for each parameter I could hardwire the update directly to the variable. I'd like to come up with a way of using a single routine that's capable of updating any of the variables. All I can come up with is passing a reference number (different for each parameter) and using a switch statement in the RunWorkerCompleted handler to direct the result. There has to be a better way.

    Read the article

  • WPF BackGroundWorker ProgressChanged not updating textblock

    - by user354469
    I have the method below that seems to behaving strangely. The ProgressChanged and RunWorkerCompleted seem to be updating themselves at the same time. If I comment out the RunWorkerCompleted code which updates the Textblock I see the ProgressChanged taking effect after the data is transferred. What am i doing wrong here? I obviously want the textblock to show I'm getting data, then change when I have finished getting the data. public void GetAppointmentsBackground() { System.Windows.Threading.Dispatcher webServiceDispatcher = this.Dispatcher; worker = new BackgroundWorker(); worker.WorkerReportsProgress = true; worker.DoWork += delegate(object sender, DoWorkEventArgs args) { GetAppointmentsForDayDelegate getAppt = new GetAppointmentsForDayDelegate(GetAppointmentsForDay); webServiceDispatcher.BeginInvoke(getAppt); (sender as BackgroundWorker).ReportProgress(25); }; worker.ProgressChanged += delegate(object s, ProgressChangedEventArgs args) { txtMessages.Text = "Contacting Server"; }; worker.RunWorkerCompleted += delegate(object s, RunWorkerCompletedEventArgs args) { txtMessages.Text = "Completed Successfully"; }; worker.RunWorkerAsync(); }

    Read the article

  • Cancelling BackgroundWorker While Running

    - by Nevets
    I have an application in which I launch a window that displays byte data coming in from a 3rd party tool. I have included .CancelAsync() and .CancellationPending into my code (see below) but I have another issue that I am running into. private void backgroundWorker_DoWork(object sender, DoWorkEventArgs e) { Thread popupwindow = new Thread(() => test()); popupwindow.Start(); // start test script if(backgroundWorker.CancellationPending == true) { e.Cancel = true; } } private voide window_FormClosing(object sender, FormClosingEventArgs e) { try { this.backgroundWorker.CancelAsync(); } catch (Exception ex) { MessageBox.Show(ex.Message.ToString()); } } Upon cancelling the test I get an `InvalidOperationException occurred" error from my rich text box in my pop-up window. It states that "Invoke or BeginInvoke" cannot be called on a control until the window handle has been created". I am not entirely sure what that means and would appreciate your help. LogWindow code for Rich Text Box: public void LogWindowText(LogMsgType msgtype, string msgIn) { rtbSerialNumberValue.Invoke(new EventHandler(delegate { rtbWindow.SelectedText = string.Empty; rtbWindow.SelectionFont = new Font(rtbWindow.SelectionFont, FontStyle.Bold); rtbWindow.SelectionColor = LogMsgTypeColor[(int)msgtype]; rtbWindow.AppendText(msgIn); rtbWindow.ScrollToCaret(); })); }

    Read the article

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