In my testing, it appears that once CancelAsync is called, BackgroundWorker will no longer honor the ReportProgress method in ProgressChanged. ReportProgress executes without an exception, but ProgressChanged stops actually doing anything. I'm imagining something like:
<code>
if (CancellationPending) return;
</code>
in ProgressChanged.
Can anyone else confirm or contradict this claim?
While I can see why it might have seemed like a good idea, it assumes that the command object would never do any more user notification once CancelAsync has been called, which seems bogus. It also actually means that you have to at a minimum always check for cancellation before you call ReportProgress, which is pretty klunky. Even then I don't think it would be foolproof against a race (said the threading numbskull ;-).
Turns out that it was my own code that was preventing ReportProgress from working. Duh. Verified that ReportProgress is called even after CancelAsync is called and CancellationPending is set to true.
Related
I'm running a method in an overridden Page OnUnload, but only if the Page_PreRender method has run.
Obviously, I can flip a class-level bool when I'm in Page_PreRender and check it in OnUnload, but if there's a more intrinsic way to tell is Page_PreRender has run, I'd like to use that.
Any ideas?
Thanks for any thoughts.
UPDATE: Let me rephrase my question slightly. I'm looking for the answer to whether there is a simple way, inherent in the Page life cycle, perhaps a property that is set by the ASP.Net frameowork, perhaps something else, that is different after Page_PreRender has run versus when Page_PreRender has not run.
I am currently setting a boolean in Page_PreRender to tell me if it has run. It works, but I don't like this solution if there is a way to accomplish the same thing without adding the extra boolean check. Creating an event that fires during Page_PreRender is the same level of redundancy I'd like to avoid, if possible.
You mention (in your comments on another post) that your problem manifests itself when calling Response.Redirect() because it throws a ThreadAbortException, which leads to your OnPreRender() event not being called. So why not use this instead?:
Response.Redirect("~/SomePage.aspx", false);
The "false" you see there indicates if execution of the page should terminate right there and then. By default, Response.Redirect() uses "true". If you need your OnPreRender() event to run so that your OnLoad() event will have everything it needs, then set it to "false" and just make sure you either jump to the end of your Page_Load() after calling Response.Redirect() or that the code that would execute after it is fine to run.
Maybe you don't like the idea of passing "false" using the overloaded Response.Redirect() method so that's why you didn't go that route. Here is some documentation that may help sway your mind:
Microsoft states that "passing false for the endResponse parameter is recommended" because specifying "true" calls the HttpResponse.End() method for the original request, which then throws a ThreadAbortException when it completes. Microsoft goes on to say that "this exception has a detrimental effect on Web application performance". See here in the "Remarks" section: http://msdn.microsoft.com/en-us/library/a8wa7sdt.aspx
This was posted last year on MSDN:
The End method is also on my “never
use” list. The best way to stop the
request is to call
HttpApplication.CompleteRequest. The
End method is only there because we
tried to be compatible with classic
ASP when 1.0 was released. Classic
ASP has a Response.End method that
terminates processing of the ASP
script. To mimic this behavior,
ASP.NET’s End method tries to raise a
ThreadAbortException. If this is
successful, the calling thread will be
aborted (very expensive, not good for
performance) and the pipeline will
jump ahead to the EndRequest event.
The ThreadAbortException, if
successful, of course means that the
thread unwinds before it can call any
more code, so calling End means you
won’t be calling any code after that.
If the End method is not able to raise
a ThreadAbortException, it will
instead flush the response bytes to
the client, but it does this
synchronously which is really bad for
performance, and when the user code
after End is done executing, the
pipeline jumps ahead to the EndRequest
notification. Writing bytes to the
client is a very expensive operation,
especially if the client is halfway
around the world and using a 56k
modem, so it is best to send the bytes
asynchronously, which is what we do
when the request ends the normal way.
Flushing synchronously is really bad.
So to summarize, you shouldn’t use
End, but using CompleteRequest is
perfectly fine. The documentation for
End should state that CompleteRequest
is a better way to skip ahead to the
EndRequest notification and complete
the request.
I added this line after calling Response.Redirect(), as MSDN suggests, and noticed everything appeared to run the same. Not sure if it's needed with 4.0, but I don't think it hurts:
HttpContext.Current.ApplicationInstance.CompleteRequest();
Update 1
Using "false" in the call to Response.Redirect() avoids the ThreadAbortException, but what about other Unhandled Exceptions that could be thrown on your page? Those exceptions will still cause your problem of OnUnload() being called without OnPreRender(). You can use a flag in OnPreRender() as everyone suggests to avoid this, but if you're throwing Unhandled Exceptions, you've got bigger problems and should be redirecting to an error page anyway. Since Unhandled Exceptions aren't something you plan to throw on every postback, it would be better if you wrapped your OnUnload() logic in a Try-Catch. If you're logging and monitoring your exceptions you will see that an Unhandled Exception was thrown right before logging a NullReference Exception in the OnUnload() event and will know which one to ignore. Because your OnUnload() will have a Try-Catch, it will safely continue processing the rest of the page so you can Redirect to the error page as expected.
Update 2
You should still have your OnUnload() wrapped in a Try-Catch, but I think this is what you're really looking for (remember IsRequestBeingRedirected will be true when calling Response.Redirect or when redirecting to an error page after an Unhandled Exception).:
if (HttpContext.Current.Response.IsRequestBeingRedirected != true)
{
//You're custom OnUnload() logic here.
}
With this, you will know if it is safe (or even worth it) to process your custom logic in the OnUnload() event. I realize I should have probably lead off with this, but I think we learned a lot today. ;)
NOTE: The use of Server.Transfer() will also call the dreaded Response.End(). To avoid this, use Server.Execute() with the preserveForm attribute set to "false" instead:
Server.Execute("~/SomePage.aspx", false);
return;
NOTE: The thing about Server.Execute("~/SomePage.aspx", false); is that IsRequestBeingRedirected will be false, but your OnPreRender() will still execute, so no worries there.
The answer is Yes, you can, but not always :)
According the Reflection code, the ScriptManager class contains the private bool field _preRenderCompleted, which is set to true while handling internal IPage interface PagePreRenderComplete event.
You can use the Reflection to get this field from ScriptManager.GetCurrent(page) resulting object
I am not sure what exactly you mean by this. According to the ASP.NET Page Lifecycle PreRender always runs before Unload. If you perform some if condition inside this PreRender event and you would like to test in the Unload whether the condition was satisfied a boolean field on the page class seems a good idea.
Add trace=true to the page directive.
Set a boolean field in the PreRender event handler, then check if it was set in the Unload event handler.
Create a custom event that fires in the PreRender event.
I don't think there is any sort of state stored because the ASP.NET engine does not really need that, as it knows its state implicitely.
Searching with .NET Reflector, it seems the page render events are raised from this internal System.Web.UI.Page method:
private void ProcessRequestMain(bool includeStagesBeforeAsyncPoint, bool includeStagesAfterAsyncPoint)
You can have a look at it, there is no notion of state. The only information you can get is the trace. If you have access to the Unload event, then you should have access to the trace? or I miss something :-)
Since the trace is in fact a dataset undercovers (see my answer here: Logging the data in Trace.axd to a text/xml file), you maybe could get the information. But
setting trace=true is not recommended in production though...
In my AIR application (with mate-Framework) i did follwing things:
click on a button
call a method in my model "onApplicationBusy"
apply some filter in arraycollections.
In my onApplicationBusy there is this code:
FlexGlobals.topLevelApplication.enabled = false;
FlexGlobals.topLevelApplication.
I trace every step and all methods are called in right order.
But my application never becomes disabled.
Why. Is there a method for this purpose.
I try InvalidateDisplayList or ValidateNow or callLater. But all tries won't work. Probably i try it on the wrong place?
I assume, my application is so busy while applying filters (4 values for 10.000 lines) that the disabled property can't processed.
If i call the method without applying the filters all works fine.
If i call just the disbaled property but never enable the app again, the app will shown as disabled after applying the filters. for me too late.
What i origin want is a clear behavior, when the app is busy and when not (ready for clicking on buttons and all this stuff).
If you can help me or know a method, how can i shown a busy application, please help me
Thanks
Frank
All right, the setTimeout Method solve my issue. I assume, I have to wait for the next screen refresh.
Why callLater won't work and when i have to implement those functions, because i have too less ressources while my filterFunction is running?
Frank
I'm using FlexGlobals.topLevelApplication.stage.mouseChildren = false | true;
Worth noting that I first tried setting the mouseEnabled flag but found various visual elements would not update at all while mouseEnabled = false.
Executing the line:
Response.Redirect("Whateva.aspx", true);
Results in:
A first chance exception of type 'System.Threading.ThreadAbortException' occurred in mscorlib.dll
An exception of type 'System.Threading.ThreadAbortException' occurred in mscorlib.dll but was not handled in user code
The exception is because of the "true" part, telling it to end the current request immediately.
Is this how it should be?
If we consider:
Exceptions are generally considered heavy, and many times the reason for ending the request early is to avoid processing the rest of the page.
Exceptions show up in performance monitoring, so monitoring the solution will show a false number of exceptions.
Is there an alternative way to achieve the same?
You're right regarding the fact that the developer should avoid raising of (and catching) exceptions since the execution runtime consumes time and memory in order to gather the information about the particular exception. Instead he (or she) should simply not let them occur (when it's possible).
Regarding the Response.Redirect: this behavior is "by-design" but you might want to use a well-known workaround. Please read this KB article.
-- Pavel
One approach I generally take in this scenario is to not end the response during the response, but to follow it immediately with a return (or other flow control). Something like this:
Response.Redirect("Whateva.aspx", false);
return;
This depends on where the redirect is taking place in your logic flow, of course. However you want to handle it is fine. But the idea is that, when you want to end the response on the redirect anyway, then exiting the method in question via a return isn't out of the question.
One approach I've seen people take in this matter quite often, and it should go without saying that this is to be avoided but for completeness I'm going to say it anyway (you never know who may stumble upon this question later via Google, etc.), is to catch and swallow the exception:
try
{
Response.Redirect("Whateva.aspx", true);
}
catch (Exception ex)
{
// do nothing
}
This, of course, should not be done, for a number of reasons. As I inferred from your description of exceptions, you undoubtedly already know that this would be bad practice. But, as I said, it's worth noting this fact in the answer.
To work around this problem, use one of the following methods:
For Response.End, call the HttpContext.Current.ApplicationInstance.CompleteRequest method instead of Response.End to bypass the code execution to the Application_EndRequest event.
For Response.Redirect, use an overload, Response.Redirect(String url, bool endResponse) that passes false for the endResponse parameter to suppress the internal call to Response.End.
For example:
Response.Redirect ("nextpage.aspx", false);
If you use this workaround, the code that follows Response.Redirect is executed.
For Server.Transfer, use the Server.Execute method instead.
from:
http://support.microsoft.com/kb/312629/en-us
Same link posted by Volpav.
Regards.
I have a need to validate a field against our database to verify unique-ness. The problem I seem to be having is that the validators doValidation() exits before we've heard back from database.
How can I have the validator wait to return its payload until after we've heard from the DB?
Or perhaps a better question might be (since I think the first question is impossible), how can I set this up differently, so that I don't need to wait, or so that the wait doesn't cause the validation to automaticallly return valid?
If you're using a remote object, you can specify the method call inside your remote declaration and assign a function to the result call. The result call only runs once the remote server returns something, so it won't be run before your validation.
Do your validation call in said result function call (which you will have to create) and you should be good. Your code should go something like this:
<s:RemoteObject id="employeeService"
destination="ColdFusion"
source="f4iaw100.remoteData.employeeData"
endpoint="http://adobetes.com/flex2gateway/"
result="employeeService_resultHandler(event)"/>
**<s:method name="dataCheckCall" result="dataCheckResult(event)"/>**
<s:RemoteObject />
And in your script:
function protected dataCheckResult(event:ResultEvent):void {
**doValidate();**
}
Edit: As soon as you call "dataCheckCall" the method will start running. If, for whatever reason, you want to call this WITHIN your validator, you can do so, and then dataCheckResult will run whenever it returns with it's payload (pretend doValidate is called elsewhere). I've left a message below as well.
You are trying to fit an asynchronous process (fetching data from a DB) into a synchronous process (checking all the validators in turn).
This won't work...
You'll need to either roll your own validator framework, or use a different method of determining the legality of your controls.
P.S. The MX validators are rubbish anyway!
What I've managed to do, seems to work, mostly. I don't like it, but it at least performs the validation against the remote source.
What I've done, then, is to use an 'keyUp' event handler to spin off the database lookup portion. In the meanwhile, I set up a string variable to act as some kind of a Flag, which'll be marked as 'processing'. When the response event fires, I'll examine its contents, and either clear the flag, or set it to some kind of other error.
Then, I have created a new 'EmptyStringValidator' will check the contents of this flag, and do its job accordingly.
Its indirect, but, so far, seems to work.
Does Response.Redirect() cause the currently running method to abort? Or does code after Response.Redirect() execute also?
(That is, is it necessary to return/Exit Sub after a Response.Redirect?)
Response.Redirect has an overload accepting a boolean argument that indicates if the call to Response.Redirect should end the response. Calling the overload without this argument is the same as specifying true to indicate that the response should end.
Ending the reponse means that Response.End is called after the response has been modified to make the redirect happen, and Response.End throws an ThreadAbortException to terminate the current module.
Any code after a call to Response.Redirect is never called (unless you supply false for the extra argument). Actually, code in finally and certain catch handlers will execute, but you cannot swallow a ThreadAbortException.
This may not be a complete answer, but from what I've seen...
Response.Redirect does, actually cause the code to stop executing by throwing a System.Threading.ThreadAbortException.
You can see this for yourself by setting up global error handling in the Global.Asax and testing a Response.Redirect.
EDIT
and here is a link to the documentation that supports my answer:
Redirect calls End which raises a
ThreadAbortException exception upon
completion.
HttpResponse.Redirect Method (String, Boolean) (System.Web)
There is another parameter to Response.Redirect called endResponse. Setting it false is a good idea when you're redirecting in a try catch block because the context still needs control to be correct. So your catch block will pick up the exception.
The caveat to that is that when the page is not Cancelable then it won't try to get control. The most common case of this is Global.asax. So you don't need to worry about this exception in that context. If you don't believe me try reflecting the code for this method and take a look.
So to answer your question it isn't necessary to do much after a Response.Redirect when you set endResponse to true which it is by default (i.e. called with the method that doesn't take a bool).
My understanding is that upon issuing a Response.Redirect(), code following it will not execute. If you think about it, it would make sense not to execute it. You're basically telling your code that you want to go somewhere else.
Example: Think of it as ordering a value meal at McDonalds. After you order it and they start filling your drink, you change your mind and say "you know what, forget my order. I'm going to Redirect myself to Wendy's." At that point, they're going to stop making your fries and burger because, well... you've decided to go somewhere else -- i.e. redirecting the response.