When using a GoView control inside our user control inside our aspx page, the first rendering of the control works fine.
If I immediately interact with the control using the client-side Zoom in/out/1:1/to fit functionality, things are fine.
If I let some time elapse (like 5-10 seconds) between the first rendering of the GoView and the time I click on the client buttons, then I get the image refreshed with a broken image icon and the ALT text in the subject.
Then IE7 asks me if I want to refresh the entire page. If I cancel IE's page reload request, the broken image icon and ALT text are displayed again and I'm almost immediately prompted again by IE to reload the page. This continues indefinately until I select refresh at which point everything works again until I pause for a time and then try to interact with the view again.
I've looked at the trace and I don't quite understand it. For the failing refresh case, I have the following in my trace.axd:
I believe the first GET to GoWebImage.axd is the one that caused the refresh, although the response code is 200 so it doesn't look like the handling of that URL itself failed.
The POST to newhost.aspx is when I say "reload" to IE and my page is refetched again from scratch. I don't understand the intervening 12 calls to /WebResource.axd, but I assume that is something internal to Northwoods.
I see the hashtable in the session state on the POST but not on any of the other requests. This behavior occurs irregardless of the EnableViewState setting for the control.
GoDiagram is not getting WebResource.axd. That’s part of an internal ASP.NET mechanism for downloading JavaScript.
So you got the GoView-inside-the-user-control to work the first time, at least? At least that's progress, because it shows that the GoView is being stored in session state.
Any errors that occur in GoWebImageHandler, the IHttpHandler for GoWebImage.axd, are written to trace listeners. Perhaps you can get that output. (But of course there isn't any trace output if there isn't any exception.)
Where will I see errors generated by GoWebImageHandler in the trace output? If it encountered an error, would it still return a status of 200 for the request?
If I say refresh, causing the whole page to be posted back, then I get a correct image. However, the whole refresh/cancel thing comes back up again if I don't keep interacting with the control through the client side post.
I meant that all error output in GoDiagram is written to System.Diagnostics.TraceListener, not that the output is rendered/streamed as part of some HTTP response.
Search for "Integrating ASP.NET Tracing with System.Diagnostics Tracing" in the ASP.NET help. Basically you need to change the config file.
Returning to your particular application, I still don't understand why everything works fine as long as you keep interacting with it, but that it fails if the user waits for more than a few seconds. Very odd. Just to be sure, how long is the sesson timeout parameter in your config file?
Thanks, that was it… previously someone had set the session timeout to 1 minute in order to debug some other problem and it caused this as a side effect.
OK, that explains why you were losing state after a wait.
But it sounds like you need to implement a GoView.SessionStarted event handler to handle the situation whenever there's no GoView stored in the session.
In my Control directive I am not turning off EnableViewState and the documentation says that the default is true. I posted the whole of my SessionStarted handler so no I am not checking Page.IsPostBack there.
None of the other session handlers in the samples do this, nor do I remember the docs discussing this. Why would mine have to be different?
Sorry – I was just asking how you knew that each postback was causing the SessionStarted event handler to be called. Did you look at the value of Page.IsPostBack in that event handler, for debugging purposes only, to determine that?
But let's step back for a minute. The initial problem, losing state after some seconds of inactivity, was caused by a very short session timeout value. OK, that's an understandable, and presumably inadvertant, error.
However, I believe you still have a problem, not strictly dependent on GoDiagram Web, that your web application might not be handling session timeouts correctly.
If your user does something for a while, goes away for an hour and comes back, and then starts interacting with your web app again, there are at least a couple of possibilities.
If the user first clicks or drags in the GoView, your SessionStarted event handler should be called, so you can reinitialize appropriately.
But if the user first causes a postback on some other WebControl, your web application also needs to deal with the session timeout. I suppose it's possible the rest of your web application doesn't depend on session state at all, other than your use of GoDiagram Web. But it sounds from your description ("... the time I click on the client buttons ...") that you need to handle this situation.
Yes, I thought adding a SessionStarted handler would take care of it. When I do a postback, InitializeComponent will be called and that will add my session handler. Then the GoView will call that because it can’t find its information in the session state. Isn’t that the way its supposed to work? This seems to be exactly what the samples are doing.