Sam Hobbs
posted
6447 posts
since
Sep 07, 2009
from
Los Angeles, California, USA
|
|
Re: Constantly update a control in the background
|
|
|
|
|
|
|
|
|
|
|
I told you in your other thread to read articles about BackgroundWorker and use the BackgroundWorker class. You should have posted replies in that thread what difficulties you were having. You should have at least included in this thread what difficulties you are having with the BackgroundWorker class.
I said in your other thread "you can use the ProgressChanged event to update the ListBox" and you are not doing that.
|
|
|
|
|
Thinking is a feeling; pleasant for some and unpleasant for others.
|
|
|
|
|
|
patrick
posted
216 posts
since
May 14, 2009
from
|
|
Re: Constantly update a control in the background
|
|
|
|
|
|
|
|
|
|
|
But I did say the problem I was having with the background worker, I tried background worker a few different ways, but always got either the error that it was busy, or it else it would say i could not access the listbox from a thread other than the one it was created on.
|
|
|
|
|
|
patrick
posted
216 posts
since
May 14, 2009
from
|
|
Re: Constantly update a control in the background
|
|
|
|
|
|
|
|
|
|
|
where would the progress changed event go? I want a continuous while loop, so there isnt really any progress.
|
|
|
|
|
|
Sam Hobbs
posted
6447 posts
since
Sep 07, 2009
from
Los Angeles, California, USA
|
|
Re: Constantly update a control in the background
|
|
|
|
|
|
|
|
|
|
|
You would add an event handler for the progress changed event and then in that event handler you would update the listbox. The BackgroundWorker would take care of the delegates and the invokes and such.
|
|
|
|
|
Thinking is a feeling; pleasant for some and unpleasant for others.
|
|
|
|
|
|
patrick
posted
216 posts
since
May 14, 2009
from
|
|
Re: Constantly update a control in the background
|
|
|
|
|
|
|
|
|
|
|
Here is what i ended up doing, it looks like it will work, but i ran into a new problem
private void fillOrders() { OrderCustomerStrings.Clear(); // this is an object of list<string>, declared at the top of the form.
List<int> OrderNumbers = OrdersDataHandler.getTodaysOrders();
foreach(int i in OrderNumbers) { unPaidCarryoutsStrings.Add(i.ToString() + "-" + CustomerDataHandler.GetCustomerByID(OrdersDataHandler.GetCustomerIDOfOrder(i)).lName); } }
private void bwShowOrders_DoWork(object sender, System.ComponentModel.DoWorkEventArgs e) { fillOrders(); }
private void bwShowOrders_RunWorkerCompleted(object sender, System.ComponentModel.RunWorkerCompletedEventArgs e) { pendingOrdersListBox.DataSource = OrderCustomerStrings; bwShowOrders.RunWorkerAsync(); }
the idea was that the background worker will constantly update the List<String> object OrderCustomerStrings, which will then be drawn in the list box before being updates again by the background worker.
The problem i ran into with this is it runs the cpu at 100% usage, all the time. i dont understand why.
|
|
|
|
|
|
Sam Hobbs
posted
6447 posts
since
Sep 07, 2009
from
Los Angeles, California, USA
|
|
Re: Constantly update a control in the background
|
|
|
|
|
|
|
|
|
|
|
I do not know what getTodaysOrders does.
As I understand your code, your DoWork calls fillOrders, which calls getTodaysOrders and then adds the results to unPaidCarryoutsStrings but I do not know what unPaidCarryoutsStrings is.
I see that your bwShowOrders_RunWorkerCompleted event calls bwShowOrders.RunWorkerAsync. That won't work. The bwShowOrders.RunWorkerAsync will cause bwShowOrders_DoWork to execute and then after bwShowOrders_DoWork finishes, the bwShowOrders_RunWorkerCompleted event will called.
Are you doing this because OrdersDataHandler.getTodaysOrders takes a long time? If so, then as best as I understand things, you cannot show any data until OrdersDataHandler.getTodaysOrders finishes. You should use a background worker for a long-running process so that the UI remains responsive but perhaps for your application it is not possible to show any data until all of it has been obtained.
Do I misunderstand where the data is coming from? Is it coming from someplace where there is a delay in getting pieces of it and is the delay caused by something other than the local processor needing time to process the data? If so, then your DoWork would need to do something to wait and I do not see that happening.
I can understand that all of this is confusing. I wish I could make it less confusing. I am confused about what your requirements are.
|
|
|
|
|
Thinking is a feeling; pleasant for some and unpleasant for others.
|
|
|
|
|
|
patrick
posted
216 posts
since
May 14, 2009
from
|
|
Re: Constantly update a control in the background
|
|
|
|
|
|
|
|
|
|
|
I should clarify. The idea is to get a list of orders that have not been paid for through getTodaysOrders(), which is a function that runs a mysql command and returns a list of order numbers. Then I sort through the orders and get the customers associated for them so I can display [order numer]-[customer last name] in a list box. The database is updated by other systems, so I want to always display a fresh set of orders to the user, while keeping the ui responsive.
Since I last posted, I added a Thread.Sleep(1000) to the beginning of the dowork command.
This seems to work, but I dont think it was the proper way to do it.
Oh the line that read
unPaidCarryoutsStrings.Add(i.ToString() + "-" + CustomerDataHandler.GetCustomerByID(OrdersDataHandler.GetCustomerIDOfOrder(i)).lName);
should have read
OrderCustomerStrings.Add(i.ToString() + "-" + CustomerDataHandler.GetCustomerByID(OrdersDataHandler.GetCustomerIDOfOrder(i)).lName);
where ordercustomerstrings is a variable accessible from both threads, so it gets updated by the dowork, then updates the ui in the workcomplete
|
|
|
|
|
|
Sam Hobbs
posted
6447 posts
since
Sep 07, 2009
from
Los Angeles, California, USA
|
|
Re: Constantly update a control in the background
|
|
|
|
|
|
|
|
|
|
|
The fact that the reason you need to update the data is because the database is being updated by an external program I think was not mentioned previously. That is an important piece of information.
I assume you are using SQL Server. The best solution is to get SQL Server to notify you of changes; that there are changes. I do not know how to do that. Perhaps you can use a trigger, but that is about all I know.
I don't understand how it could work; the code you posted appears to me to not be something that would work. Since it works perhaps you should keep it the way it is.
An alternative is to do away with the background worker. Add a timer to the form and set it to execute every second or whatever. Do the update in the timer tick event. You do not need to be concerned about delegates or cross-thread problems or much of anything. As long as the update can complete fast enough to keep the users happy then that will work. It is not the best but it is the best balance of simplicity and performance.
An alternative would be a combination of the above. You could use a timer and in the timer tick event, use a background worker to get the current data. Then after you have all the updated data, refresh the listbox. I am not sure of the details of how to reuse a background worker but it can be done. This general alternative is possible one way or another.
|
|
|
|
|
Thinking is a feeling; pleasant for some and unpleasant for others.
|
|
|
|
|
|