I have several async calls where I set the IsBusy property to true and then back to false in the async callback.  Usually this works correctly, but sometimes the BusyIndicator just remains on the screen and will not go away.  I've even stepped through the code and verified that IsBusy was getting set to false and the animation still remained.  Again, this is sporadic.

I saw that at least one other user has also reported this.  Any ideas what it could be?

Hello Michael Rodriguez,

Will it be convenient for you to prepare a sample solution that will allow us to reproduce the issue?

Regards,
Milan
the Telerik team

Not really.  It is very sporadic and only seems to happen when certain async data calls either chain up or take more than a second or two to complete.  If you close the screen and go right back in then it works.  Very frustrating.

Hi Michael Rodriguez,

Unfortunately it is very hard for me to give any guidance without being able reproduce the issue. If you are unable to send us a sample project if would be great if you could give us more information about your scenario - some XAML of the RadGridView setup, what kind of async operations are used, etc.

All the best,
Milan
the Telerik team

Hi,
I'm getting the same problem.

The project just migrated to Silverlight 4 so i started to use the RadBusyIndicator.
I use it as a container within a border which is itself the content of a TabItem. Within the RadBusyIndicator, there is a scrollviewer which contains a RadGridView among other things.

There is a search page, when user clicks on Search, it opens the silverlight page described above. 70% of the time it works fine, the RadBusyIndicator is hiden when the Async call returns. But as Michael mentioned, sometimes the grid is populated, but the page stays disabled as if the RadBusyIndicator was still on. If i change page and come back then the page is enabled again.

The database returns a dataset to the Silverlight-enabled WCF Service through a web service layer and a data access layer. The dataset is converted to an IEnumerable<Dictionary<string, object>> which is returned to the completed method in the silverlight project.

It would be difficult for me to send you a sample project, so i hope this little information helps to understand the issue.

Hi Lauren,

Could you please send us a sample code illustrating how you use RadBusyIndicator. It would be of great help to us. 

Looking forward you reply.

Best wishes,
George
the Telerik team

I am having a similiar problem as the thread creator.  The aforementioned behavior occurs when my WCF async call returns really quick (before RadBusyIndicator has a chance to fully change from the Not Busy to the Is Busy state).  Setting the DisplayAfter property seems to have no effect.

Until Telerik corrects this issue, my solution was to add a Thread.Sleep(250) before I change IsBusy property to false in the async callback.  This allows the RadBusyIndicator to change states before the state is switched again.  While this is not ideal it is better than allowing the user to make a change to the form prior to all data being loaded.

 

I've exactly the same problem. If the async data loading is really quick (actually i'm loading from isolated storage) then the busy indicator, in my case, dissapears, but the content "underneath" it remains disabled. If I add a small sleep in the code then it works correctly.

Need a fix asap!

Hi All,

Thank you for reporting your experience with RadBusyIndicator.

We have tested the control in some scenarios where it shows for a short moment, however, did not manage to reproduce the issue described. Any working project that exhibits the behavior would be of great help to us. 

Reading about the use case, this seems to be resolvable if you set the IsBusy property as late as possible in your code. That is why calling it in a Dispatcher could be reasonable(rather than using Thread.Sleep(...)):

Hope this 

Greetings,
Teodor
the Telerik team

Unfortunatly the project I am working on is not something that is easily transportable (multi-layer/multi-platform), but have you tried using the MVVM pattern to test this.  In my project I have a DialogService which I use to create RadWindow popups.  The way the service works is I first instantiate a ViewModel and then pass that model to the DialogService with a string indicating the type of dialog to open.  The DialogService then sets the ViewModel as the View's datacontext.  In the ViewModel's constructor I call a WCF service to fetch data and set IsBusy to true (RadBusyIndicator montiors the property using databinding).  When the call returns I then set IsBusy to false.  The first time the data is fetched WCF takes just long enought to not cause an issue.  In a subsequent call for the same data WCF returns really quick (possibly due to caching in IIS/SQL).

From RadBusyIndicator's point of view when it is loaded into the visual tree it is loaded in the IsBusy= true state.  From what I can tell RadBusyIndicator has a two step IsBusy transition.  Step One is to disable the child controls (assuming this is the case because all the child controls go gray as if they are disabled).  Step Two is to display the busy indicator UI.  If we change the state while Step One is under way we do not see the busy indicator and the child controls remain disabled. 

Another thing to note is that the issue does not happen if you test while attached to the VS2010 debugger.  Which makes this a pain to troubleshoot.  The debugger must slow things down enought to avoid the issue.  This leads me to believe that the issue may not present itself when we are in production where the layers are running a multiple machines.  Currently in my dev environment I have all the pieces running on my high end dev box.

As for your suggestion regarding using the Dispatcher, I tried that before hitting on the Thread.Sleep solution.  Ensuring the change happens on the UI thread had no effect.  This appears to be a timing or thread issue.  Are you using a backgroundworker thread to disable the controls/do something?

Hello Jeremy,

Thank you for the detailed reply.

The current version of RadBusyIndicator does not use any BackgroundWorker threads in its code. It uses, however, a DispatcherTimer to delay the display of the busy indication according to the DisplayAfter property. We have not experienced any issues with it so far though. 

Could you please point out what do you use to make asynchronous calls (threads, thread pool, background worker)?  

Along with this post, you will find attached a simple project demonstrating a use case of RadBusyIndicator bound to a ViewModel class. Please, feel free to modify it so that the issue is reproducible and send it back to us for investigation.

Let us know about any progress.

Sincerely yours,

Teodor
the Telerik team

Hi,

I think I found out when this behavior happens, namely when the IsBusy property is set (to "True") BEFORE the control is loaded in the visual tree. While this might seem a little far-fetched :), in my case it isn't so, here's the order of events:

1. User is on a page.
2. User clicks a button to navigate to another page
3. (some) Framework resolves the navigation request somehow, let's say it decides it needs to load Page2.xaml and hook up its Page2ViewModel.
4. Framework creates view+view-model:
    var page = new Page2();
    var vm = new Page2ViewModel();
    page.DataContext = vm;
    ((ISomeInterface)vm).Initialize();
5. So the framework supports view models that are ISomeInterface aware and calls their Initialize method. Note that at this point the view still isn't in the visual tree.
6. Initialize() method of the view-model sets some IsLoading property to True, to which the IsBusy property of RadBusyIndicator is bound. Then the vm starts loading some data on another thread.
7. Finally the Page2 view is loaded in the visual tree.
8. The data loading in the view-model ends and the vm sets the IsLoading property to false.

The problem appears between steps 6->8. As far as I can tell what happens is that RadBusyIndicator's OnApplyTemplate method is called, which calls the ChangeVisualState() method. But at this point the IsBusy property is true and the ChangeVisualState() method goes to the Busy state which disables the "background". Theoretically this should be no problem, because as soon as the data is loaded the IsBusy property is set to false, which causes the IsBusyIndicationVisible property to be set to false. However, it looks like when this is done the property changed callback for the IsBusyIndicationVisible property is not called, and so the ChangeVisualState back to Idle is not called either, resulting in the disabled "background". Why this doesn't work I don't know, but maybe you can tell me :)

I hope I'm making some sense here, I have a small repro app which you can get from here: http://cid-5a652c421a7d71ae.office.live.com/browse.aspx/telerik?Bsrc=GetSharingLink&Bpub=SDX.Docs

For information, I have the exact same issue: using the RadBusyIndicator with async calls, and same: The IsBusyIndicator happens to stay in "Is busy" state sometimes ...

Looking for a solution as this is really annoying and critical bug. And in my case I do use databinding to set the IsBusy State. Therefore would be quite hard for me to delay the change of state to make it work...

Hi Christian Burkhardt,

Thank you very much for the project provided and for your detailed explanation of the use case.

We managed to reproduce and resolve the bug in RadBusyIndicator and will ship a fix for it with the next internal release. We hope this time frame is acceptable.

Any further feedback is appreciated.

Sincerely yours,
Teodor
the Telerik team

Sure, no problem, glad to help. Could you please write a reply here when this internal release is available?

Thanks

Hello Christian,

The internal release is due to be available for download later today so stay tuned.

All the best,
Teodor
the Telerik team

Hello,

I have downloaded the internal build of the 21 of august, to check for the fix of the Busy Indicator staying on. I know have the following exception at runtime:
"Failed to create a 'System.Type' from the text 'telerik:RadProgressBar'."

I guess the exception comes from the custom progress bar style that I defined:

  <Style x:Key="ProgressBarStyle" TargetType ="telerik:RadProgressBar">
    <Setter Property="Foreground" Value="#FF027DB8"/>
    <Setter Property="Background" Value="#FFD2D5D8"/>
    <Setter Property="BorderThickness" Value="1"/>
    <Setter Property="Maximum" Value="50"/>
    <Setter Property="IsTabStop" Value="False"/>
    <Setter Property="BorderBrush">
      <Setter.Value>
        <LinearGradientBrush EndPoint=".5,1" StartPoint=".5,0">
          <GradientStop Color="#FFAEB7BF" Offset="0"/>
          <GradientStop Color="#FF919EA7" Offset="0.35"/>
          <GradientStop Color="#FF7A8A99" Offset="0.35"/>
          <GradientStop Color="#FF647480" Offset="1"/>
        </LinearGradientBrush>
      </Setter.Value>
    </Setter>
    <Setter Property="Margin" Value="0,0,0,-18"/>
  </Style>

All worked fine with previous major version.

Any idea?

Is the latest internal release with the fix available. I was "tuned" Friday, but no further messages were posted here :)

If so, where can I get it from?

Self answer: forget my previous issue: wrong reference to old assembly in one of my projects. Everything works fine
Sorry for that.

For me so far: the latest internal build fixes the issue.
Since it is not an issue that happens all the time, more time is needed to really confirm this but seems good!

Hi Walter,

We are glad that everything works for you as expected in the end.

Adrian, 

The latest internal build should be available for you at this link after you log in:
http://www.telerik.com/account/downloads/internal-builds.aspx

Hope this helps. Let us know in case you have further queries.

Best wishes,
Teodor
the Telerik team

Was this fix applied for WPF as well?
We are having same isue in ur project.

Hi Thomas,

Thank you for contacting us. 

This was fixed in both technologies - Silverlight and WPF. If you are not using the latest version of our controls we suggest you to update and try your application with it. In case the issue persists at your side, can you provide us with a repro sample, so that we can examine the use case locally?

Let us know if you need further assistance.

Sincerely yours,
Teodor
the Telerik team

What I've found is that, if you set your Bussy indicator in code to IsBusy = false; the code doesn't work as it should. Sometimes, the Bussy indicator thinks it's not showing when it is, so it ignores the call to IsBusy = false;.

To force the Busy Indicator to hide itself, do as followed:

RBI.IsBusy =

 

true;

 

 

RBI.IsBusy =

 

false;

 

This will make sure the Busy Indicator things it's showing, and thus, it will always respond to the IsBusy = false.

@Telerik: you should be able to fix this with ease; just remove the code that checks if the indicator is showing itself, and always execute the steps required.

Hello Nick,

Thank you for the feedback. 

What version of our controls are you using? Can you send us some code or a repro solution so that we can debug the issue locally?

Thank you in advance.

Greetings,
Teodor
the Telerik team