I want to send a message to the client when the ASP.NET session ends. I did not want to use timers so I tried using "server sent events" to call the client from the session_end event in global.asax. Is there a way to call a specific client from global.asax? I tried using the 'SignalR' library for this propose, but had problems calling a specific client from Global.asax (I have managed to call a group of clients but not a specific client)
What are the best practices for this propose?
I'm not sure if this is what you need, but does this help?
(Of course you don't need to use DevExpress for this, you can implement your own popup window)
Related
I am loading a gridview using a code based on this:
http://msdn.microsoft.com/en-us/library/ms366515%28v=VS.80%29.aspx
I am using callbacks to populate the grid, sometimes there is a lot of data or the user wants to cancel.
How can I cancel the callback from being processed on the server when user hit cancel??
thanks
Searched quite extensively and found that it is possible to Cancel Server Tasks with ASP.NET & AJAX
Although I'm not good with AJAX, Found some links that will help you,
Here's how to Canceling Server Tasks with ASP.NET & AJAX and here's a forum thread on something similar to your problem.
Hope it helped !
AFAIK, you cannot cancel the server side call back processing once initiated. At the most, you can have some client (browser) side logic that will ignore callback results.
Regardless, I will suggest you to use ASP.NET AJAX (UpdatePanel or Script Services) rather than using ICallbackEventHandler. It's quite simple to use and more flexible. Besides, you also have options such as cancelling callbacks : see this article for cancelling update panel callback (note that cancel really means stop waiting for (& ignoring) callback results, the server side processing would happen).
Once you've initiated a request to the server, the client cannot cancel it. Ignoring the mechanics around any possible "cancellable method", you've started a request with the server. Any further communication will result in a new request, so that original request will continue until it has finished. Remember HTTP is a stateless protocol, each request has no knowledge of any previous request, and because of that, how could it cancel a previous request?
You're best bet would be to just ignore the server response, or if you actually need to cancel a long running task that may still be processing on the server, you need to bake in that support yourself, as the web server will not natively support it. To do that, you'll likely need some way of persisting the task state across multiple http requests, and have the original request (the one running that task) be monitoring some sort of cancellation flag.
Just remember though, in the above scenario, you wouldn't be cancelling the request, but the task the request is running.
I was wondering if anyone had an easy way to wire up javascript event handlers to events happening on the server-side. I have a long running process that includes a lot of steps, and would like the client to be continually updated with new information as the steps transition. Will this involve some sort of polling mechanism?
Send an AJAX or JSON request from the client every so often asking for status.xml. Then, on the server, when something changes, just quickly write a new line to status.xml the same way you would to the console. You can use setInterval( function, timeBetweenRuns ) in Javascript to do this regularly.
would it be possible to use an update panel to do this with maybe a timer? it's sort of how I would do it.
Course, this depends on what you're doing already. I'm assuming you're using Forms...
Ajax calling a Web Service is how I would do it.
How do you capture errors that happen on client side when building RIA apps using Flex and Silverlight? What are the common practices? I have seen some asynch js calls to a web service implemented but would like to know how the community is dealing with it.
First, I use client side logging all of the times.
the way I handle it depends on the entire application.
if I use an AMF gateway then there's a call for an application error, with every error that occurs the server is notified, in the server side a bug is open in BugZilla (this is what we use, you can use any other hook you want).
If I use a web-service based application then there's a web-service call for a client error.
one would say you shouldn't sample the server with every error, I disagree with this comment because an error in the client side is rare, it goes thorough QA before being released to the client so I want to know immediately on every error the client is experiencing.
In Silverlight I like to use a WebClient to log back to a web service somewhere -- you can do this directly in the Silverlight application without calling out to JavaScript.
To catch exceptions that are fired when your code isn't on the stack, you can use the Application.UnhandledException event.
I've used the same approach as Avi Tzurel - you need to know on the server side when an error appeared in the Flex client. If you want to collect more data (all the log messages, warnings) I would use an internal buffer and I will flush it asynchronously.
Anyway, you need to take into consideration if your customers are ok with this approach..maybe you need their agreement before sending the error message to the server.
I basically percolate all errors to the top, and capture them in the unhandled exception. I display a friendly message to the user. However, throughout my application I implement an ILogger interface. This interface can be initialized with various levels and handles any messaging. You can set it up so the user can add an init param to determine whether or not to transmit the errors to a service, and I typically have the logger write the messages with Debug.WriteLine if the debugger is attached to make it very easy to trace issues in debug mode.
In Silverlight you may want to consider the Logging and Exception Handling Application Blocks from the Silverlight Integration Pack for Enterprise Library.
I created a simple web application where a search form is filled out, submit
button clicked, and a message is sent with the search parameters via
nServiceBus. I also have a handler in the same project that picks up the message
(from the same queue). For some reason, the web server process blocks until
after the message is picked up, is there any reason for this? I set a breakpoint
in the message handler and it breaks before the request finishes... locking the
browser until I allow the code to continue. I would expect control to return to
the browser regardless of when the handler gets fired...
Thanks,
D.Niemeyer
Are you using .RegisterWebCallback() in your code, as that is what is responsible for preventing ASP.NET to complete the HTTP call?
This was answered in the nServiceBus forum. This is a phenomenon caused by having the debugger attached, which stops all threads if a breakpoint is hit before the response is returned. Placing a sleep in the handler demonstrates this.
I'm using a separate class and unique method for sending mail.All my web pages, will call the method to send the mail. But, I'm using Client.SendAsync() to send the mail. The following error occurs while sending the mail asynchronously.
"Asynchronous operations are not allowed in this context. Page starting an asynchronous operation has to have the Async attribute set to true and an asynchronous operation can only be started on a page prior to PreRenderComplete event"
I set Async=true in #page directive, but, as I'm using separate class, so no use of it. Is there any other way to overcome this problem?
Seems you just need to start your async task before PreRenderComplete event; do you mind to post some relevant ASP.NET code?
Also, read this: Running an asynchronous operation triggered by an ASP.NET web page request
This article may be of some help to you:
Fire and Forget Email, Webservices and More in ASP.NET
Setting Async to true is OK if that separated class is declared, instantiated and within the context of the page request.
However you probably need to handle SendCompleted event.
See the sample codes in this MSDN Reference.