Hi Bernard,

I looked at your changes and can see that you just changed the data given to the WebGrid in InitializeRow. That's kind of cheating. Normally, there would be a database call instead of this hardcoded stuff. Of course we could add this logic into the database, but these text modifications are just for displaying, so I don't think this belongs logically into the database and I don't want to do that.

I also tried to change ListName.Value in the InitializeRow event handler in the same way as ListName.Text, but it had no effect. Probably that value is read-only there or something.

So from what I see now, the only way to solve this would be that after the database call in InitializeDataSource I copy the returned resultset into a DataTable and add a column, loop through all rows and set the display value there instead of in InitializeRow event handler. Then I could remove the code in InitializeRow. That way the underlying .Value has the correct values for sorting. I could also set the SortColumn property, but I would still need to create the data column. I don't like to loop through DataSets, but this seems to be the only solution for now.

Yes, having a property to sort by the displayed text instead of the underlying value would be a good idea. Please suggest such a feature request. An even better way (or additional feature) would be some way to modify the underlying data value (and/or the sort value) within the InitializeRow event handler.

Thanks

Hi Bernard,

Thanks for your reply and your solution. I'm not sure what caused this and why the Session object was empty while debugging, but changing this fixed the issue and now I can see content in the Session object.

Can you explain this a little more, to get some deeper understanding? I think I do understand the code, but this IsFlyPostBack property is not 100% clear to me. Why would that be there? I'm sure that got copied there for some reason, maybe from an example or so. And at least at some point this code worked.

From what I understand, the FlyPostBack is the dynamic postback done by JavaScript from your control and handled on the server-side just lika AJAX, by returning partially rendered content. When would this be called here (for sorting?) and why would we want to test for this property within the InitializeRow event handler?

And why would we need to even test for IsPostBack (in your new code)? Because even for initial load, we would like to expand the nodes as well (from the last visit of that page).

The problem is solved, but I'd like to get more understanding of what happened here and to avoid such mistakes in the future.

Thanks

Update: Today I had this problem again (Session empty in InitializeRow event handler). But it happened only with this sample, not in our real program. I did not make any other changes. Even restarting Visual Studio, closing all browsers, etc. did not help. After rebooting my PC (and deleting browser cache) everything seems to work again. It's probably not related to the cache, because I also tried to set all no-caching options in Page.Init event without success before rebooting. Is there any known bug related to this in V6? Anyway, this just confirms I was not dreaming yesterday that I saw the Session object empty and the questions above are still open.

Hi Yudi. I think I outlined the differences clearly in my initial post. I'm not sure what else you would need. I'll try to explain again.

With Integrated Windows authentication, I have these three requests when clicking on the WebGrid:

--> POST URL page.aspx
    Cookie: ASP.NET_SessionId=..
    Content-Length: 10181
    Content: WebGridRequest=...
<-- 401
    WWW-Authenticate: Negotiate
    WWW-Authenticate: NTLM
--> POST URL page.aspx
    Cookie: ASP.NET_SessionId=..
    Content-Length: 0
    Authorization: Negotiate ...
<-- 401
    WWW-Authenticate: Negotiate ...
--> POST URL page.aspx
    Cookie: ASP.NET_SessionId=..
    Authorization: Negotiate ...
    Content-Length: 10181
    Content: WebGridRequest=...
<-- 200
    Content: <isnet.webui.webgrid><action...

And with the new code with anonymous authentication, for the same action we get:

--> POST URL page.aspx
    Cookie: ASP.NET_SessionId=...
    Content-Length: 0
    Authorization: Negotiate ...
<-- 100
<-- 200
    Content-Length: 95777
    Content: (entire page)

The problem is that for some reason the request has no content, but an Authorization header. I don't know where this comes from. Maybe something from the browser (IE8) or client component doing the request. Maybe the browser/component "remembers" somehow that for this site an authorization was made earlier (on the Login.aspx page) (Connection is always Keep-Alive) and therefore tries to re-authenticate right away. You can see that the request matches the second request in the Windows authentiction requests. As the server doesn't support Integrated Windows authentication on this page, it fails. So I'm not sure how to tell the client not to do such requests. Maybe there's an option in the component to set this that you forgot to set?

Normal requests for images look like this:

--> GET URL myfile.gif
    Cookie: ASP.NET_SessionId=...
<-- 200
    Content-Length: 205
    Content: GIF89a...

As you can see, there's no Authorization header. Maybe as a workaround I can enable Integrated Windows authentication as a second option beside Anonymous. That should work, because the browser always tries anonymous first (by definition). In this case this avoids our optimization, but also avoids the crash. But it would still be good to find the problem.

Hi Yudi,

Yes, this helped me find the solution. To summarize your answer:

• make sure not to forget RunTimeLicenseKey (it was there, I just didn't mention it)
• I don't need any appSettings for ISNet.WebUI.WebDesktop keys
• add the appSettings key "ISNet.WebUI.WebGrid.v6_0_7200.WebDesktopScriptDirectory" (this was the problem)

But even after fixing this, it didn't work. Reason was a typo in your code above. The value for the WebDesktopScriptDirectory should've been "~/Intersoft/WebDesktop/V2_5_2007/" (note the 2007, not 7200).

So yes, this fixed the problem. One important thing to mention: The included help for WebGrid (see page "Application Wide Configurations") doesn't list this WebDesktopScriptDirectory key. That's why I missed it. Actually this key is not mentioned anywhere in your documentation (only the class property with the same name is mentioned). If this is still missing in your latest version of the documentation for WebGrid, please update.

Thanks

Hi Frank! No, it never got resolved. But we moved away from that Windows 2000 server to a "new" platform (IIS6) a few months ago and there I don't remember having any problems with this. The new environment has other issues, but not this one.