|
I haven't done any WPF yet, however I use BGW a lot in WinForms. A BackgroundWorker has a ReportProgress method, which is fine for reporting information back to the user. Seems to fit what you are looking for.
|
|
|
|
|
if i understand you correctly, i update my ui by using backgroundWorker.ReportProgress and in order to send user's response, i idle my algorithm with busy waiting ?
|
|
|
|
|
Sorry, I clearly wasn't paying attention here. ReportProgress() will cause the OnProgressChanged event to be fired on the main thread, however it basically is an output method, and it will not wait for anything, so it isn't what you want. As others have pointed out, your overall design seems cumbersome.
|
|
|
|
|
but why is that ?
i started to implement some algo as a console for user interactive.
As i already stated, the algo is recursive, each recursion iteration, i get an input from the user, and according to this input algo decide if it should stop or to be executed once again...
now i want to switch the console user interaction with ui.
then how i can referred already written algo to the new ui project ?
Thanks for help
|
|
|
|
|
maybe you should look into the yield keyword, it offers a way to return results from a method while allowing said method to continue execution later on. Not sure how well it fits recursive methods, I read it would work fine but my very first experiment (long ago) failed.
FWIW: if all you need is some kind of continue/cancel input, you can organize that by having the main thread taking care of the user interface (buttons, checkboxes, ...) and setting some variable(s) to reflect what the user did, and your background calculation simply reading those variables whenever it feels like it.
|
|
|
|
|
The first question is why must you use a console application? Can't you extract the logic into a separate assembly and call it from the main app?
It seems you are making a relatively simple process much more complicated than it needs to be. Your background process needs to take some input and return a result. Why does it need to continue processing after returning results as indicated by your need to idle it? Perhaps even consider using a workflow.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
it continue processing because it run in different thread.
any other ideas ?
|
|
|
|
|
It continues to run because you don't stop it obviously. You are in complete control of the code, stop the execution, exit the thread.
Why is it recursive? IMO, from what you have described it doesn't need to be. Accept the user input, complete the search, exit and repeat as necessary.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
i cant stop the execution...
I implement application which is based on decision tree.
you may have progress in breadth and in depth.
The main idea is to ask some question, if the answer is wrong, then the progress is in breadth (another question with the same difficulty level), here comes the recursion.
if the answer the user provide is correct, the progress is to the deeper level (higher difficulty level), this part works by loop.
i cant stop the recursion part in the middle of the progress.
when i started to implement it using console, it was easy, i just waited to user's input by Console.ReadLine() .
But now, i execute the algorithm from the ui, and after some question was generated, the ui updated, but the algorithm continue to run...
How do you think I can solve it ?
Thanks
modified on Sunday, December 5, 2010 5:26 PM
|
|
|
|
|
|
I yield to your yield
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
|
One can only hope you're unique then; two non-yielders would be a recipe for trouble.
|
|
|
|
|
and how it should help me ?
I've no iterations here...
|
|
|
|
|
IMO you could organize your current recursive calculations as if it was returning an enumerable list of results, while no such list ever gets created, all it should take is a yield return each time you have a new result; I look at it very much like a good old co-routine, if you're familiar with that concept...
|
|
|
|
|
i'm not familiar with the concept... any reference ? (google didn't helped much
and question about the yield, if i return each time calculated result, how can i send some data to the loop in order to stop it ? (let say correct answer was given)
Thanks
solved
modified on Saturday, December 11, 2010 11:20 AM
|
|
|
|
|
I created a little article on yield return here[^].
|
|
|
|
|
As Luc had been telling you yield is one way.
When using Console.ReadLine you were stopping the execution at some point correct? Essentially the same as calling the CancelAsync method on a BackgroundWorker object, again as Luc has suggested to you.
Again, IMO, you are making it much more difficult than it needs to be. You should be able to search breadth or depth from any point, not start at the beginning and wait for input.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
if i stop by Console.ReadLine() , the algorithm execution pause until user inserts the input. but the pause in specific recursion level.
after the input was inserted, the algorithm continue to run from the point it paused.
If i'll use CancelAsync and exit the thread, how i would be able to return to the exact point it was stopped ?
modified on Monday, December 6, 2010 5:05 PM
|
|
|
|
|
You have a poor algorithm if it must pause and wait for input and can't be reentered. IMO.
If you have to pause and wait for input then consider a Workflow, which from your description is what you should be using anyway. and I suggested to you yesterday.
http://msdn.microsoft.com/en-us/library/dd851337.aspx[^]
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Thanks for the link...
I'll read it
I assume i was need to use it any way, but a problem that Software Engineering in Uni is not so developed as it should be
|
|
|
|
|
if you want real synchronization between two threads, there are several tools available for that. Have a look at ManualResetEvent and AutoResetEvent classes. The pseudo-code could be:
public string WaitForUser(string message) {
...
myAutoResetEvent.WaitOne();
return someGlobalVariable;
}
public void myButton_Click(object sender, EventArgs e) {
string s=myTextBox.Text;
someGlobalVariable=s;
myAutoResetEvent.Signal();
}
|
|
|
|
|
Why on earth are you interacting with a console application from your WPF application? It sounds like you're really making problems for yourself.
|
|
|
|
|
Pete O'Hanlon wrote: Why on earth are you interacting with a console application from your WPF application? It sounds like you're really making problems for yourself.
I started with console, i'll move it to class library, and eventually i'll add a dll as a reference.
|
|
|
|
|
Do it right the first time and it will save you considerable work and problems.
I know the language. I've read a book. - _Madmatt
|
|
|
|