|
The "completed" event / handler is able to access the UI; it doesn't call "Report progress". It's the equivalent of a "final" report progress; with a (optional) "state object" in the event arg.
BGW is an IDisposable.
You maintain a reference to it somewhere, and use that to: Start and optionally stop; and later dispose of the worker.
An "adapter" (wrapper) make it easy to interface with the BGW and create a diverse collection of worker references that can be managed.
On the same way you used a delegate for "work" and "progress", also use a delegate for "completed" (or 3 interface access points).
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Ok. But I have already done all that. The UI class that manages the worker (the "adapter" as you say) is the same custom control class that manages the tasks (represented by the "Task" class) and displays progress. It has a method "AddTask" that sets up the background worker like this:
public void AddTask(Task task)
{
tasks.Add(task);
counterText = counterTemplate.Replace("#2", tasks.Count.ToString());
task.BackgroundWorker.WorkerReportsProgress = true;
task.BackgroundWorker.ProgressChanged += OnTaskProgressChanged;
task.BackgroundWorker.RunWorkerCompleted += OnTaskCompleted;
}
(The DoWork event handler is set up in the Task class constructor so it has already been assigned by the time the above method is called). Assuming by "completed" you are referring to the RunWorkerCompleted event, as you can see, I have a handler (shown below). That handler makes it so that the BackgroundWorker method for the task is set to null (by calling the task's "InvalidateWorker" method also shown below). This handler is NOT being called before the Task::End() code I posted above.
The OnTaskCompleted method (part of the custom control with the AddTask method above):
void OnTaskCompleted(object sender, RunWorkerCompletedEventArgs e)
{
tasks[currentIndex].InvalidateWorker();
NextTask();
}
The InvalidateWorker() method in the Task class (I suppose I could dispose the BackgroundWorker here if necessary):
public void InvalidateWorker()
{
BackgroundWorker = null;
}
I have a break on the line where the OnTaskCompleted method calls the InvalidateWorker method that is not reached before the End method I posted previously is called (from the OnTaskProgressChanged method if the UI detects that the progress bar has reached its last step). So I am having a hard time understanding why the background worker is "completing" without invoking the event handler for it. I am also assuming that because it is "busy" it hasn't officially completed the call.
The only explanation I can think of is that the "completed" message is queued in the message queue/loop behind the "progress" message that detected the work was technically completed and that the background worker is shut down before "completed" event is invoked. If so, that is just bad design on the part of Microsoft. I figured though that the "IsBusy" would indicate that this is the case (see my End() method in the previous post); but apparently that isn't the case either... which makes Microsoft's code even worse.
modified 3-Dec-17 7:28am.
|
|
|
|
|
I suppose this is all easily fixed by removing the "BackgroundWorker.ReportProgress(100)" call in my Task::End() method. I only included this originally because I did a test program to see how the BackgroundWorker operated before building the logic of my "adapter". I wanted to test how the BackgroundWorker dealt with values over 100 because the BackgroundWorker class was designed without taking into consideration that the programmer might not want to report percentage, but rather tasks (such as files being processed etc...). So I built this test program:
namespace BackgroundWorkerTest
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void OnDoWork(object sender, EventArgs e)
{
backgroundWorker.RunWorkerAsync();
backgroundWorker.DoWork += backgroundWorker_DoWork;
}
void backgroundWorker_DoWork(object sender, DoWorkEventArgs e)
{
for (int i = 0; i < 10; ++i)
{
for (int x = 0; x < 10; ++x)
{
for (int j = 0; j < 1000000; ++j)
{
bool b = false;
}
}
backgroundWorker.ReportProgress(500);
}
}
private void OnProgressChanged(object sender, ProgressChangedEventArgs e)
{
progressBar1.Value += e.ProgressPercentage;
}
private void OnWorkComplete(object sender, RunWorkerCompletedEventArgs e)
{
MessageBox.Show("Worker Done!", "Worker Message");
}
}
}
When I run the test, the "OnWorkComplete" method is called, posting the "Worker Done!" message box long before the DoWork method is completed... indicating to me that the "complete" event is also raised when ReportProgress is called with a value of over 100 (this was the behavior I was testing). I added my line in my "End()" post in order to make sure the "completed" event occurred. Apparently both this and completing the DoWork callback can invoke the "complete" event while only the second scenario shuts the worker down. Again... more terrible design on the part of Microsoft.
EDIT NOTE: The BackgroundWorker in this particular test is connected to the last two handlers by the Designer since the test only uses one worker that I directly tied to the GUI.
modified 3-Dec-17 7:59am.
|
|
|
|
|
You shouldn't get hung up on this "reporting %"; it's a totally artificial construct you have to maintain yourself. If your process is indeterminate, it is totally useless.
Most of the time (all the time), I never need the BGW "completed event".
I have a BGW that may handle a queue; nobody cares if the queue is empty, only if it's not being serviced ("DoWork").
Your last iteration is getting to the heart of what I was about (but without the "task" clutter; saving a few lines of code is not always in the best interest).
public interface IDoWork {
void DoWork( object sender, DoWorkEventArgs e );
void ProgressChanged( object sender, ProgressChangedEventArgs e );
void WorkerCompleted( object sender, RunWorkerCompletedEventArgs e );
}
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
You said: "You shouldn't get hung up on this "reporting %"; it's a totally artificial construct you have to maintain yourself. If your process is indeterminate, it is totally useless."
I only care about it because Microsoft has forced us to. This is exactly why forcing us into a percent scheme rather than allowing the user to implement how the user handles the data (integer) passed to BackgroundWorker::ReportProgress(int), and raising the "RunWorkerCompleted" event when the "percent" is at or over 100 is a really stupid design on the part of Microsoft. In addition to the problems already mentioned, I have to use BackgroundWorker::ReportProgress(int, object) to pass an integer higher than (or equal to) 100 in order to prevent the "complete" event from being invoked.
|
|
|
|
|
% is usefull if your "UI" is a progress bar.
Besides being able to pass a "state" object INTO the BGW process (which could have its own "%"), and TO progress and completed events; as well as being able to access "shared properties", "% reporting" is a "bell and whistle" and not a limitation.
That's why I said not to get hung up on it.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
If it was just a "bell and whistle" as you say, then using it versus the state object would be optional. There would be an overload for just sending a state object. I find it annoying to have to worry about an unused parameter and how it could screw up someone's program if they aren't careful. If you disagree then that is your prerogative. Functionally it works fine, so I will use it; I just try to make my shared classes as versatile to different use cases as possible; I am a bit surprised, (and annoyed because that is my prerogative), that Microsoft didn't do the same here; especially when their own documentation says that it is up to the user to do something with the data.
|
|
|
|
|
It is "optional". You seem to think it somehow controls the event processing; it doesn't. 0, 100, nada makes no difference.
Depending what "examples" one finds, one "assumes" one is more significant than the other (state object vs % vs BOTH vs NONE) based on the code emphasis. You just happended to be focused on the "%" ones.
Belt, suspenders or both?
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
modified 4-Dec-17 12:55pm.
|
|
|
|
|
Actually it does make a difference. If I send an integer >= 100 as the percentProgress parameter to BackgroundWorker.ReportProgress, then the BackgroundWorker.RunWorkerCompleted event fires even if the DoWork callback is not completed. I tested this before I even started this thread to find out what happens when I send a number greater than 100 (because the documentation implies that the number should not be greater than 100).
|
|
|
|
|
I'll take your word for it.
I found no use for it; since few processes I deal with are "determinate".
"Exiting" based on a calculation seems like a bad day.
(The value sounds more like an "input" to a progress bar (i.e. the "ui" part of "reporting progress"); the usual assumption).
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
hello, i want to promote the student one class to another class, by using what field to update automatically the student promotion to the next class and next year.can you give some ideas.
|
|
|
|
|
No, because we have no idea what your code or data organisation looks like.
What you've asked is like phoning a travel agent at random, saying "I want to upgrade my hotel room" and putting the phone down. The travel agent doesn't know who you are, which hotel you are supposed to be staying at, when you are staying, or even what country the hotel is in!
Remember that we can't see your screen, access your HDD, or read your mind - we only get exactly what you type to work with. And at the moment, we don't have anything at all ...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Use the "promotion transaction".
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Member 12898590 wrote: by using what field to update automatically the student promotion
First, promotion is a 'process' which means you must write a method that changes some data (for you to figure out) in an existing instance (a student) to represent that.
Second 'automatically' means that something must trigger that method. Up to you to figure out what that means but it could one of the following
1. A method, which really does nothing but call the first method above
2. A timer that runs at some periodic basis which then calls the above method.
3. Some other method, for example something like 'determine final grade' could call the first method above.
|
|
|
|
|
Hi Friends,
I want to calculate the distance between the HD Camera (industrial grade, small tiny one 16mm 1/2" 5MP) There are few formulas that I had found in the net. But not sure which to use.
Can someone suggest the correct formula to calculate the correct distance between the camera and the object. (preferable with the angle of inclination)
Thanks (in advance) for the help
Regards,
Dorairaju
|
|
|
|
|
Well without some frame of reference you can't.
|
|
|
|
|
If you don't have to details on the lens being used by the camera, it's impossible to calculate. You also need to calibrate the system with known points in the image. How accurate you get is also dependent on the object you're measuring distance to. You're not going to get an accurate distance to the center of a ball in the image.
Also, the accuracy is going to be rather poor if you're only using one camera and nothing else.
System.ItDidntWorkException: Something didn't work as expected.
C# - How to debug code[ ^].
Seriously, go read these articles.
Dave Kreskowiak
|
|
|
|
|
Place reference objects / lines in the "frame".
Wonder why there is a "ruler" on the side of doors leading in / out of banks?
Or the "lines on the road" used to measure speed / distance over time (from above).
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
my projects link button not work in iphone 6s but desktop work properly why?
|
|
|
|
|
???? What? Sorry, but what has this got to do with C#? Is it code related? If so, what code do you have? Remember that we can't see your screen, so you have to give us a lot more detail than this if you want us to be able to help you.
This space for rent
|
|
|
|
|
Because there's a secret bug in your secret code.
Seriously, how do you expect anybody to be able to help you based on the complete lack of information you've provided? 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
You may be surprised to know that an iPhone 6 and a Desktop are actually different devices.
|
|
|
|
|
Maybe it's a "Windows-only" link.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Hello,
I would like to validate strings to datetime format using regex please
modified 15-Nov-17 6:00am.
|
|
|
|
|
Not with regular expressions! 
Use DateTime.TryParseExact[^] to validate the string against your required format.
However, there's a small problem. Your "valid" string doesn't actually match the format you're validating against. Your format requires the letter "T" between the date and time, but neither of your strings have that.
string input = "2017-09-19T08:04:31.123";
DateTime parsedDate;
bool isValid = DateTime.TryParseExact(input,
"yyyy-MM-ddThh:mm:ss.fff",
CultureInfo.InvariantCulture,
DateTimeStyles.AssumeUniversal,
out parsedDate);
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
