This is a migrated thread and some comments may be shown as answers.

RadBusyIndicator and Async calls

25 Answers 920 Views

General Discussions

This is a migrated thread and some comments may be shown as answers.

This question is locked. New answers and comments are not allowed.

25 Answers, 1 is accepted

answered on 05 Aug 2010, 03:19 PM

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.

answered on 12 Aug 2010, 04:38 PM

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(...)):

Dispatcher.BeginInvoke(new Action(() =>

{

this.busyIndicator.IsBusy = false;

}));

Hope this

Greetings,
Teodor
the Telerik team

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items

answered on 12 Aug 2010, 05:13 PM

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?

answered on 16 Aug 2010, 01:16 PM

busyindicatorsample.zip

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

answered on 16 Aug 2010, 04:18 PM

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

answered on 23 Aug 2010, 11:28 AM

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?

answered on 04 Oct 2010, 04:12 PM

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

answered on 11 Apr 2011, 10:03 AM

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.