|
Rank: Newbie Groups: Member
Joined: 7/3/2014 Posts: 3
|
Hello, I am using the progress bar within my C# code, but in order for me to update the progress, using the extraData field, I need to make a call to e.UpdateProgress(progressMade, msg) twice. The first time I call it it doesn't ever call my javascript OnProgress function (the progress bar is set up as follows)
Code: HTML/ASPX
<eo:ProgressBar ID="ProgressBar1" runat="server"
BorderColor="Black" BorderStyle="Solid"
BorderWidth="1px" ControlSkinID="None"
Height="13px"
IndicatorColor="Red"
ShowPercentage="True" Value="0"
DesignOptions-BackColor="Red"
ClientSideOnValueChanged="OnProgress"
ClientSideOnTaskDone="Done"
OnRunTask="ProgressBar1_RunTask">
</eo:ProgressBar>"
If I call it again though with the exact same parameters, it will make it to the client side and update appropriately. I end up having to do two calls:
Code: C#
if (!e.IsStopped) //if the progress bar still hasn't been stopped
{
e.UpdateProgress(progressMade, msg); //doesn't actually seem to do anything
e.UpdateProgress(progressMade, msg); //will actually make it to the client side web page and update appropriately
in order to get my client side to update at all. Is this common or is there a workaround for situations like this? One other small query--I assume that it is common practice to check e.IsStopped every time any time e is used? I'm just wondering because in your examples you only check it one time--in the main loop iteration. I am running into the issue though where in between calls to e.UpdateProgress the user has clicked stop, which means that when I actually make the next call to e.UpdateProgress, the object has been disconnected. This leads me to put checks around almost every call I make. Is there a better solution to this? Thank you!
|
|
Rank: Administration Groups: Administration
Joined: 5/27/2007 Posts: 24,196
|
Hi,
Please check that if you have caching enabled for that page. UpdateProgress sends data directly to the client side, however if caching is enabled on that page, the output might not reach the client immediately.
You are correct about IsStopped. It can be flagged at any moment and in fact even if you check it right before calling UpdateProgress, it might be flagged before your code reaches UpdateProgress. Currently UpdateProgress throws an exception if it sees IsStopped as true. We probably should change it to return false instead of throwing out an exception in that case. This would allow user to determine what to do in such situations. Usually they do not need to do anything since the task has already been stopped.
Thanks!
|
|
Rank: Newbie Groups: Member
Joined: 7/3/2014 Posts: 3
|
From what I can tell, I have caching disabled for the page, yes. I thought maybe it was a Firefox specific issue, but when I tried it in Chrome it did the same thing. Sometimes the very first call I make to UpdateProgress works fine (calling it only once), and subsequent calls later on in my code do not. Other times none of the calls work the first time. For example:
Code: C#
//trying with only one call to UpdateProgress each time instead of twice in a row, just to see what happens
e.UpdateProgress(0, "Running...<br>"); //when this does work, which is rare, but I have seen it work...
//...
//code here
//...
//next update
e.UpdateProgress(progressMade, msg); //...this one doesnt
But as I mentioned, sometimes neither one works. And as before, if I make two calls in a row that seems to work fine. Any other thoughts?
|
|
Rank: Administration Groups: Administration
Joined: 5/27/2007 Posts: 24,196
|
Hi,
We have not been able to reproduce this problem. In all our test the ProgressBar updates immediately as soon as UpdateProgress is called. The problem might be some kind of additional layers that are enabled on your transportation level. So you may want to use a network package monitor such as fiddler to monitor the traffic and see if you can see the data is sent to the client right away. Please also check if IIS compression is enabled. If that is enabled, you will need to disable that.
We have also posted a new build that changed the return value for UpdateProgress from void to bool. This way UpdateProgress will no longer throw an exception if the task was stopped. Thus it is no longer necessary for you to check IsStopped or wrap the call in a try catch block. Please see your private message for the download location of the new build.
Thanks!
|
|
Rank: Newbie Groups: Member
Joined: 7/3/2014 Posts: 3
|
Ok I figured out the UpdateProgress() issue--I need to call it twice when my config file is set with the attribute <compilation debug="true" targetFramework="4.5">. If I set debug = "false" it updates the first time I call UpdateProgress(), every time. Wohoo! As for stopping the progress, thanks for the new build! I still check for e.IsStopped though just to cover the instance where e has been closed client side (because the stop button was pressed) and the server hasn't been updated about this yet. Without this I get an HTTP exception saying, naturally, that e doesn't exist. I am still having issues actually stopping the progress though. Under the condition that I run Firebug on my page, when testing locally, and I step through my javascript Stop() method, e.IsStopped gets updated correctly and my code exits appropriately. However, if I do not debug through the javascript, it will not update e.IsStopped and my code continues until it breaks because e doesn't exist. In doing this it is hard to tell whether or not stopTask() is even being called of course, but it seems to be the only way to get the progress bar to not stop correctly. Please if you think that it is an issue on my side let me know--I don't want to have you guys debugging all my code if its an error on my side. main process loop:
Code: C#
for (int i = 0; i < requiredNoteIDs.Count; i++)
{
if (!e.IsStopped) //check this just in case between the last iteration and this one
//the Stop button has been pressed, making e unavailable
{
//main stuff is done here
didEOUpdate = e.UpdateProgress(progressMade, msg);
currentIterations++;
//if the progress bar did NOT update
if (!didEOUpdate)
break;
System.Threading.Thread.Sleep(1000);
}
else
{
break;
}
}//for loop
So the Stop button (below) will call the Javascript stop method, which should call stopTask(), which then sets e.IsStopped to true, which then, on the server side will cause the main loop to stop. But like I mentioned, it is only stopping correctly when I debug the js Stop() method. Other than that e.IsStopped never seems to get set to true and the main loop keeps running until e doesn't exist, and then it breaks.
Code: HTML/ASPX
<button id="btnStopTest" class="button floatRight" tabindex="22" disabled="disabled" onclick="Stop();">Stop Test</button>
Code: JavaScript
function Stop() {
unsetHourglass();
// Stop progress bar
eo_GetObject("ProgressBar1").stopTask();
var txtBox = document.getElementById(OutputLabelClientID);
txtBox.innerHTML = txtBox.innerHTML + "Testing was stopped.";
}
Thank you so much!!
|
|
Rank: Administration Groups: Administration
Joined: 5/27/2007 Posts: 24,196
|
Hi,
Thanks for the additional information about calling UpdateProgress twice.
As to stop, please check if your code does something else after Stop is called. Stop does not immediately send a request to the server ---- rather it schedules a request to be sent in the background (Note that here it's not our code that schedules the request. It's the browser that does it. So we have no control over this part). Under various circumstance, this request will not be sent. A typical scenario is you immediately redirect to another page, or post back the same page afterwards. In this case the browser will usually discard the previously scheduled request and replace it with the new one. The fact that it works when you were debugging through Stop indicates that there had been enough time for the request to be sent when you were debugging, but when you were not debugging, something else happened immediately afterwards that canceled the request.
Thanks!
|
|