0

I am implementing Perforce API in my application. For few long processes, I am trying to implement backgroudworker. I have done the implementation before many times, I know the in and outs of the BGW, but this time I am just not able to get results.

public P4()
        {
            bw.WorkerReportsProgress = true;
            bw.WorkerSupportsCancellation = true;
            bw.DoWork += new DoWorkEventHandler(bw_DoWork);
            bw.ProgressChanged += new ProgressChangedEventHandler(bw_ProgressChanged);
            bw.RunWorkerCompleted += new RunWorkerCompletedEventHandler(bw_RunWorkerCompleted);

        }

private void bw_DoWork(object sender, DoWorkEventArgs e)
        {
            BackgroundWorker worker = sender as BackgroundWorker;            

            Recordset = p4.Run(p4command, p4args);
        }

P4 is my constructor initializing BGW. I am calling it normally via RunWorkerAsync() method. bw_DoWork suppose to run p4.Run() but my Recordset is null (means command is not running). About p4command, its a global string containing command such as "integrate" and p4args is a global array containing arguments for the command, both are initialized from the base function.

Any idea what I am missing? (I also have bw_RunWorkerCompleted() which runs perfectly after bw_DoWork skips p4.run)

Thanks

EDIT: All functions related to BGW are in a separate class, P4, which has nothing to do with any GUI operations. I am calling P4.integrate() from a GUI which in turn call BGW. When I place P4.run() directly into P4.integrate() I get my results in Recordset, but placing this same command into bw_DoWork() seems not to work.

Async call is in P4 class, inside P4.integrate().

Thanks

Niyojan
  • 544
  • 1
  • 6
  • 23

1 Answers1

0

Can you get it to work on the GUI thread outside of the background worker? If so...

Are the commands being used, the references, located on the GUI thread? Even though one is reading information, cross thread access is still a consideration. I had run into a linq issue failure C# WPF: Linq Fails in BackgroundWorker DoWork Event when using a background worker and this seems similar.

Update

Where is your run worker async call?

ΩmegaMan
  • 29,542
  • 12
  • 100
  • 122
  • Edited my question, async is being called within a separate class which is being called by GUI, is this the reason why its not working? It need to be implemented in GUI class? – Niyojan Jul 25 '14 at 04:16
  • The example that you have shared, it tries to read values from Textbox within DoWork(), that is wrong, I know that we need to pass all arguments from Async() and get the values from DoWorkEventArguments. All variables used in my bw_DoWork are already initialized outside. – Niyojan Jul 25 '14 at 04:22
  • @DeepakKumar what happens when you debug it and put a breakpoint in the worker method? – ΩmegaMan Jul 25 '14 at 14:03
  • It reaches the statement P4.run() but no results in recordset, after that it goes to runworkercompleted and executes the print statement there. – Niyojan Jul 28 '14 at 03:54
  • @DeepakKumar Does this call work outside the background thread, say on the GUI thread; it sounds like a DB problem and not a background thread per-se (unless there is some cross thread memory issue). – ΩmegaMan Jul 28 '14 at 07:16
  • It works fine from GUI thread, currently I have implemented it from GUI only. The problem is, there is already a BGW in my GUI application and I dont want to implement a new BGW for each long process that I implement on the form. So I was searching for a way to generalize BGW in P4 class, but that doesn't seem to work. – Niyojan Jul 28 '14 at 09:17
  • @DeepakKumar You mentioned an `async` call...you are not trying to do `async` in a background thread are you? All calls to the database should be direct (no async). – ΩmegaMan Jul 28 '14 at 12:51
  • Backgroundthread, what do you mean? As I mentioned, async call is implemented Integrate() function. – Niyojan Jul 30 '14 at 11:22
  • @DeepakKumar I used 'background thread' which is what the `background worker` ultimately is coded. If there is an async call within the worker, I don't believe the worker is `alive` long enough to receive the work of the async call; hence no data. – ΩmegaMan Jul 30 '14 at 14:04
  • I think I was not clear enough, as I mentioned "async call is in a different function in a different class" and that function has nothing to do with background thread. I understand that async call should be in "the background thread". Can you please elaborate more? – Niyojan Jul 31 '14 at 05:21
  • @DeepakKumar Here is the gist of what I am saying. If the call can work outside the background thread, it may be due to async operations being properly handled in the GUI thread. If it thus fails in the background worker, don't use any async operations, regardless of *where* along the chain they are being done; or make sure that the background work is calling the async operations properly and *the backgrond worker* is not exiting before the async call(s) have a true chance to finish. Hence a race condition. – ΩmegaMan Jul 31 '14 at 12:24