I am currently evaluating the new ProgressBar control, but I face a problem of setting its value from the codebehind (C#).
It is not a problem how to set the value of the control, but my opservation that the ProgressBar is not advancing like in the Telerik's demo (using JavaScript).
On a simple webform I added a new ProgressBar and older RadProgressArea (with RadProgressManager on top of it) control, in addition to a Button for starting the action. The code is as follows:
public partial class _Default : System.Web.UI.Page{ RadProgressContext progress = RadProgressContext.Current; protected void Button_Click1(object sender, EventArgs e) { for (int i = 0; i < 100; i++) { // 1. RadProgressBar (new control): RadProgressBar1.Value = i; // 2. RadProgressArea (previous control): progress.PrimaryValue = i; progress.PrimaryPercent = i; progress.SecondaryValue = i; progress.SecondaryPercent = i; System.Threading.Thread.Sleep(100); } } protected void Button_Click2(object sender, EventArgs e) { // Clear the progressbar: RadProgressBar1.Value = 0; }}After running the code, the older RadProgressArea is working fine, ie. the bar is advancing at each step as we expected.
However, the new RadProgressBar is not advancing and will only show its final value (in this case 99) at the end of the process.
Could someone point me in the right direction in solving this problem. I repeat, I need above functionality without using javascript.
Regards,
Senad
8 Answers, 1 is accepted
The RadProgressArea control automatically tracks the process on the server via RadProgressManager. The RadProgressBar has to be updated manually either on the client or on the server, depending on the scenario, in which it is used.
If you want to update the progress bar dynamically you can do so on the client via the set_value method. The following demo shows it in action: http://demos.telerik.com/aspnet-ajax/progress-bar/functionality/chunk/defaultcs.aspx
Also, I would suggest checking the help article that compares the two progress tracking controls in the UI for ASP.NET AJAX suite in order to get a better understanding of how each works and choose the one that matches your requirements: http://www.telerik.com/help/aspnet-ajax/progress-bar-vs-progress-area.html
Regards,
Slav
Telerik
Rank 1
I thank you for the reply, but my main problem remains unsolved.
As I said in the original post, I know that we can update the RadProgressBar value manually (ie. RadProgressBar1.Value = i;), but the problem is that bar is not advancing on the screen at each step.
Your suggestion is to use the JavaScript functionality via set_value method, which, to be honest, is way too complicated option. As a matter of fact, it is mandatory for me to update the value from the server side, so those (calculated) values need to be passed to this client function. Unfortunately, I was unable to find a way to do it so far.
On the other hand, the older RadProgressBar doesn't have such problems: all we have to do is simply update its value from the code behind (ie. progress.PrimaryValue = i;) and the bar is actually advancing visually on the screen at every loop without any client intervention.
If your answer is the only option then your documentation should be extended saying so, particularly because there is a comparison between the RadProgressBar and RadProgressBar.
Regards,
Senad
Rank 1
Thanks,
-Sam
Rank 1
yes, we are able to update its value (in the 'for' loop we simply put RadProgressBar1.Value = i;), but the problem is that on the screen the bar is actually not advancing visually. At the end of the loop, it will only show its final value on the screen. To repeat, the problem is that for the new RadProgressBar control, the bar is not advancing through the loops.
On contrary, the older RadProgressArea is doing exactly this: it is visually advancing on the screen after each loop.
Regards,
Senad
The behavior that you describe as a problem in the RadProgressBar is actually part of the intended functionality of the control. Please, keep in mind that the RadProgressBar and the RadProgressArea are two different controls and the requirements associated with them are different and, as is in your case, non-overlapping.
As can be seen by the comparison table - RadProgressArea requires registration of HTTP handler. This is actually the HTTP handler that does periodical AJAX callback to the server in order to get the progress on the RadProgressContext. Since the context is changed in the mentioned for-loop, the periodic ajax requests get the changes and apply them visually on the RadProgressArea. You get this functionality out-of-the-box with the help of the RadProgressManager.
The same behavior is not part of the RadProgressBar. The idea is to provide our customers with a light-weight, thin control that offers progress tracking. There is no server-side tracking of progress in the RadProgressBar control, because it does not make sense in the context this control has been thought for. Still you can use the ProgressBar control to track server-side processes. You need to implement the periodic server calls on your own. In that respect you can take full advantage of any technology that you see fit, which is able to communicate changes from the server to the client side. You can use periodic calls to web services, SignalR, custom implementation, server-side events, etc. You are basically not limited to a single implementation.
As an illustration of the information so far, you can find attached a simple example that I have prepared, which uses the RadProgressBar control to track changes to a server-side integer variable and communicate back the current value. This is a simulation of a task progress. Please, note that the RadProgressBar should be updated on the client-side using the set_value method, thus taking full advantage of the excellent user experience of the control.
Please, note that for every new run of the provided sample page, you need to reset IIS, because the tracking integer is static and will not be reset until the web application gets restarted.
Hope this helps.
Regards,
Niko
Telerik
Rank 1
Veteran
Iron
I gotta say, what you guys call a Progress Bar, is not a Progress Bar, at least as far as the term has been used for decades. A Progress Bar is used to indicate the status of a relatively slow server-side process. It isn't used to indicate the status of fast client-side processes, since it is rare that one needs to do that. By definition, users don't need to be told something really fast is occurring.
In any case, I assume the reason most folks wanted Telerik to develop a stand-alone progress bar was because trying to implement server-side process tracking with the Progress Area (a control developed for the File download architecture) was extremely clunky. It continues to be. However, tracking server-side processes through the "Progress Bar" control is even more difficult, so we are again left with trying to rework a control (the Progress Area) to do something it was not designed to do. While I can envision there being some need to indicate the progress of some discrete process that has a number of steps client-side (like a wizard, or whatever), that is certainly not what people have been using Progress Bars for over many years. So the control you created is woefully mis-branded and just causes annoyance for people who are trying to use it in a way it was not designed for, but should have been.
Rank 1
True that - if this was a server-side progress bar - who wouldn't need that in a business application. on the wish list :)
thank you,
-Sam
I am sorry to hear you feel this way. I must state again that the RadProgressBar control has a distinct niche as Niko explained above and Albert guessed at. The example Niko provided can be extended and encapsulated in an interface-like structure, or class, or user control, so you can reuse it according to your current application toolset. For example, you can easily mix it in with SignalR, which is not something you could do with RadProgressArea.
If that or the built-in handler calls for the ProgressArea do not fit your needs, I encourage you to explain what you envision in such a control in terms of API and functionality, and how that is different from the current controls, in our Feedback Portal (I know this is not what you want to hear, Albert, but this is still the way we operate): https://feedback.telerik.com/Project/108/Feedback/List/Feature%20Request.
Regards,
Marin Bratanov
Progress Telerik