We've encountered a problem with WARP and WebTab that seems to be what is documented by this post:
http://news.labs.infragistics.com/forums/t/2440.aspx
and a couple more like the post above pertaining to WARP. We think that the async postback functionality of WebTab and WARP make them susceptible to a new error that manifests after installing .NET Framework 2.0 SP1. These errors don't manifest under .NET framework 2.0 without the service pack.
We have a support request in, if we could just get IG to take it seriously. Seems they tested under .NET framework 2.0 without SP1, didn't see the error, and don't think there's a problem. We've followed up with them to let them know about the problem being specific to SP1. Hopefully, we'll see some response soon.
To validate the SP1 issue, we created a test project under VS2005 and VS2008 using CLR 2.0 versions of IG ASP.NET 7.1, then ran it against machines configured with .NET 2.0, and .NET 2.0 SP1. As I mentioned before, the problem manifests under SP1, but not under the non-SP1 2.0 install.
-Jason
Vince
Your assumption is correct. Though we were less than enthusiastic about the initial response that we got from support, hindsight suggests that we probably didn't know as much about this at the time that we received the first response from your support teams as we do today. If there was any lack of clarity or detail on our part, we do take responsiblity.
I think that the suggestion of dismissal came about due to a statement in the second followup to additional information that we sent along, when support stated "as such there is no incompatibility between WebTab control and MS validator." This type of statement, when we're watching the failures manifest before our eyes, is not well taken, as I'm sure you understand.
So, that leaves the customer to troubleshoot the possible reasons for the problem, and to start IG's troubleshooting work in tracking down the problem that -- were it but for a bit of trust on the part of IG -- could have, should have, been a presumptive fact.
We do development, too, and we ALWAYS take our customers reports seriously and NEVER tell them that the problem isn't there. We just assume we have to find the conditions that caused it.
Jason,
I assume that the support request that you're referring to is incident number WBT3116? We had originally tested this using .NET Framework 2.0 RTM. Now that we know that you're using .NET Framework 2.0 SP1, and that you also aren't encountering the problem using the RTM of the framework, we're testing your issue in .NET Framework 2.0 SP1 as well. The Developer Support Engineer on this incident will follow up with you once his test is complete.
Please rest assured that we are taking your support request seriously. Developer Support occasionally doesn't have enough information to diagnose a reported problem immediately, and so we try to give all of the apparently-relevant information as to what we've seen so far - including a sample project, if we're able to make one. It's important for us to do this, so that you can give us feedback as to what is being done different, and so that we can recreate the issue you're encountering - or, in some cases, to confirm that what we did differently works as a solution for your situation. Just because we can't reproduce the problem doesn't mean that we believe that there's no problem, but instead means that we don't yet know enough to see what's happening so that we can determine why.