How to show and refresh the BusyIndicator

[Jon]

Hii..

I have Busyindicator on a form..  Why doesn't this work.. nothing shows up.. how do I force a refresh? Do have use a dispatcher?  thanks.

public void DoWork()
{
    this.busyindicator.isbusy = true

        // Dowork
   this.busyindicator.isbusy = false


}

[Teodor]

Hello Jon,

Thank you for contacting us.

Usually, there is no need to call the change of RadBusyIndicator's IsBusy property from within a Dispatcher. What we suggest you is to go through the use cases in our online demos:

http://demos.telerik.com/wpf/?BusyIndicator/FirstLook
http://demos.telerik.com/wpf/?BusyIndicator/Configurator

Hope they will be of use. Let us know if you need further assistance.

All the best,
Teodor
the Telerik team

[Jon]

Hi..
I don't understand how to get it to work in my case. Do have use background thread?  thanks

public void DoWork()
{
    this.busyindicator.isbusy = true

        // Dowork
   this.busyindicator.isbusy = false


}

[Teodor]

Hi Jon,

Yes, in most cases when you need to show busy indicator you need to execute the long-running process on a separate thread, so that the UI thread is not blocked. BackgroundWorker class is one of the most convenient way to do this. See more information about it here. Additionally, the First look example demonstrates how it can be used with RadBusyIncicator.

Hope this explains the matter. Let us know in case you need further assistance.

Regards,
Teodor
the Telerik team

[Ristogod]

Using a background thread is hugely inconvenient. The process I need to run wasn't exactly built to be thread safe. So by doing so, it just causes much more issues. Taking the time to refactor the code is not really an option also. Why exactly can't you just set the IsBusy to true and have it show, then IsBusy to false to get it to disappear? 

[Jon]

I agree.

[Teodor]

Hi guys,

The reason why we should execute the long-running operations in the background is to leave the UI responsive even if the application is still processing something. If we do not do this in the a background thread, the UI (like over states of buttons, animations, including RadBusyIndicator) freezes and becomes again responsive after the operation is completed. Thus if we make the following:

busyIndicator.IsBusy = true;
// do work in the same thread
busyIndicator.IsBusy = true;

we set the IsBusy to true (line 1), then RadBusyIndicator begins to update its UI (e.g. show its busy indication), however, the execution proceeds to line 2 where it engages the same thread and blocks it - in this way preventing the RadBusyIndicator from showing itself. 

Hope this explains the matter. We will be glad to assist you further.

P.S.: You may try setting the DisplayAfter property of RadBusyIndicator to TimeSpan.Zero - it may help you show busy indication just before the thread is blocked. Still, the progress bar of the RadBusyIndicator will be frozen while the long operation is running. 

Kind regards,
Teodor
the Telerik team

[Jon]

Thanks for the explanation

[Ristogod]

This still doesn't work even with BackgroundWorker threads. The problem is that I am using a RadGridView bound to a collection of objects. I am using a BindingExpression to keep the ItemsSource property in sync with the collection.

So the problem is that when that collection changes, or is completely replaced, the RadGridView can take a long time to update itself and finish the whole binding process. However, I can't seem to figure out how to get the BusyIndicator to show while that is going on. The work being done that is a long process is being done on the UI thread. I can do the work in the DoWork event of the BackgroundWorker thread, but I have to use the Dispatcher to references the RadGridView, which just puts the work right back onto the UI thread.

So long story short, when other controls are being very slow to update themselves, you can't get this BusyIndicator to show up at all because it doesn't seem possible to separate the work as they both have to happen on the UI thread. Am I missing something?

[Teodor]

Hello Nathan,

Thank you for contacting us.

Since we have increased support inquiries recently, we need some more time to handle your query. We will contact you addressing the matter as soon as we can.    

Sorry for the inconvenience.

Best wishes,
Teodor
the Telerik team

[Teodor]

Hello Nathan,

Thank you for your patience.

Looking at your description, it seems to us that the UI blocks because of the regular updates of the ItmesSource property of the RadGridView. In this relation you can refer to the technique used in the following blog post to update your grid:

http://blogs.telerik.com/pavelpavlov/posts/10-05-20/displaying_live_streaming_data_with_radgridview_for_silverlight_and_wpf.aspx

Besides, if you would like to report busy status in sync with RadGridView, you can simply bind the RadBusyIndicator's IsBusy property to the IsBusy property of RadGridView. 

Hope this helps. Let us know in case you need further help.

Kind regards,
Teodor
the Telerik team

[Tim]

Ok, I completely understand the need for a backgroundworker when doing something like parsing through a database, etc.  My issue is that I have a view with a plethora of controls. (somewhere around 200)... I know.. I know.. But it's a data entry form and splitting it out into separate tabs or views would impede the usability of the project. Not a single bit of "work" is being done. All of the work happens when you submit the form, and that is when databases are updated, emails are sent, etc.  well, I guess hooking all the databindings could be considered work, but I don't have any way to separate those out.

I can't load the view on a background threat and then jump to the primary thread, and multithreading every other view would be a daunting refactoring task.  Is there any solution to update the IsBusy state when all we are waiting on is for is the view itself to build?