Please reply back to the last e-mail you received from support to inquire as to the status of your incident.

Jumping in here...

I have been trying to get resolution on a number of similar problems. I place a variety of Netvantage controls inside the ASP.net FormView control to handle drop down lists, editting controls, webgrids, and A nifty Tool bar to do all the FormView actions, etc, all inside an AJAX update panel.

This worked fine until the .net 2.0 sp1 update installed back in late January. Since then, none of my forms are working that have an AJAX update panel with any Netvantage control in it.

In addition, AJAX controls from Netvantage (WARP panel and Async features of WebTab) are all giving similar errors.

 After several goes with Support trying to convince them this was not just a fluke, they finally initialized an investigation with the engineers. That was back on Feb 12,2008. Nothing since then.

I hope they are indeed working on this problem.

I had to strip all the AJAX capabilities out of my project and modify code where required to make the pages work again. This has been a very frustrating time for me, and my customers are losing confidence in my product.

Vince

You're very welcome for whatever clarity I may have shed on this transaction with my last response, but it occured to me in reading your response that I'm breaking one of my own cardinal rules in not telling you what I DID like about the interaction with your support staff, and not just the part that didn't work for us.

 Your support tech took the extra step of providing screen capture video of his interaction with the sample project that we sent along with our request for support on this issue.  Watching that video made it clear to us that there was some systemic variation causing results to be different.  That video was a very good point of departure in our internal validation process for reports of this type.  It demonstrated to us SOMEONE needed to do a variant or multi-variant analysis on this problem, and -- since it apparently wasn't going to be IG -- we set out to look for reasons why your results were different than ours.  That project led us to look for documentation of similar experiences and to look for recent changes in our systems that may be included in variant analysis.

We could exchange many messages about where that variant or multi-variant analysis should have been homed: here or IG. 

One last point.  We've found that a good analysis tool is a system information report (SIR) for each production or development platform representing a source for a bug report.  Windows XP professional, for example, includes this mainstay Microsoft tool We have developed internal tools that perform string searches and comparisons between system reports generated by our customers and submitted with bug reports, and our internal test platforms on which we validate reports of bugs/problems.  If we get different results than our customers report, our first stop is to run a comparison on the differences between the test platform and the customer SIR.  That comparision, to a trained tech, can point to the most promising possible explanations for differing results.

 -Jason

Jason,

Thank you for your follow-up.

It's very important to me that you've mentioned what you found was inappropriate about the response my staff provided.  Looking at the response you were sent in more detail, it is more clear how it seemed as though we were saying, "there is no problem because we don't see it."  The message should have instead said, "we don't have enough information to identify the problem."

Just as how you've described, when we can't reproduce a problem our customer reports, our assumption is always that we don't have enough information to see it, not that the problem isn't there.  It is and always should be a presumptive fact that a customer reporting a problem to us is encountering that problem, whether we can see how it's happening or not.  I'm taking steps to ensure that my staff does a better job of communicating this point, as well as communicating what the next step is.  At worst, if we have no specific troubleshooting suggestions or questions, the "next step" would be that we need additional information.

Regarding the technical issue itself, I see that my staff was able to reproduce the behavior when we tested with .NET Framework 2.0 SP1.  We've reported this to our developers for further research, which in this case I expect will lead to a code change that you'll receive as part of an upcoming hot fix.

Again, thanks for the feedback, I apologize for the miscommunications from my staff, and I hope that this issue is now on the right track to being resolved.