Vincenzo,

When you set a cell as not editable at client-side, please use SetForceNoEdit() method instead of setting the property.

With the method call, it will properly mark the cell as not editable, which will then be skipped by WebGrid during keyboard navigation (such as when pressing tab).

Let me know how it goes at your end.

Hello Giuseppe,

Did you install our products in the deployment server using installer?  

Also, have you specified the RuntimeLicenseKey for WebGrid licensing in your web.config?

Our all products used Minimal trust in deployment through AspNetHostingPermission(SecurityAction.LinkDemand, Level = AspNetHostingPermissionLevel.Minimal) attribute. Thus, it should be no problems hosting in your medium trusted server.

Dan, thanks for sharing your results. It's great to see the compression worked at 72% level for you.

Several points for your questions:

• The ISRes_Compressed variable is cached internally for performance reason. So it may have no effect after you set it to false without restarting the application pool. However, you should still use the "true" value to ensure it works across application restarts.
• IIS Compression checks for the response filter when ASP.NET passed the final output stream to the IIS 7 handler. When IIS 7 detected that the response is already compressed, it won't go for another compression to avoid redundant compression. Smart logic.
• The duplicate javascript requests is due to the different version being requested, not because of the capitalization. For example, notice that WebAnimation.js is requested twice, one is for version 2.5, and another is for version 3.0. The number behind the request name indicates its requested version.
  
  That said, could you ensure that you have used all 2009 products? eg, use WebDesktop 3 assemblies instead of 2.5? If you've used all latest products and there are still request for version 2.5, then we will investigate it at our product level.

Another interesting point regarding Javascript caching: SmartWebResources will automatically cache the javascript and other resources in the client browsers when your application is running in the production server (eg, compilation debug="false" in web.config). So the answer is yes, and it's automatic, so there're no efforts needed at your end for the caching.

The built-in cache setting sets the expiration to occur when the files are modified since last access (based on modified date of each resource).

Let me know if you have other questions. Thanks!

Agustin, you can try to use grid.RootTable.Rows[0].Expanded property to determine whether a row is expanded or not.

The value of this property also depends on when it's accessed. It might not be available in AJAX context for built-in data operations. 

Do you access it in Page_Load after a full postback or in initial load?

Dan, thanks for your response.

Here are the answers to your questions:

1. Yes, this feature is actually a late-breaking enhancement that we added in 2009 release. We plan to cover some of the new late-breaking features through interactive medias such as blogs and community, and then sum them up in the next release's documentation.
   
   Here are some details for the compression feature:
• This feature can be used together with other settings such as Xml Compression and CSS Compression.  
• This feature works in conjunction with SmartWebResources feature. So, make sure you have configured SmartWebResources properly. Click here to learn how to configure SmartWebResources, and here to ensure it's working.
• When enabled, it used server-side resources to perform the compression. It does use a bit of the server-side CPU processing and memory for the compression. But our testing indicates the resources usage is still under acceptable range with decent performance.
• As for the client-side, the performance and memory usage is almost not noticable since the compression feature is built natively in the browser.


2. The Deployment Manager documentation can be found here.
3. I'm not quite sure if you can see the compression results in the Safari browser without external plug-in, although I'm pretty sure Safari has supported gzip compression since its earlier version. However, you can check the compression results using IE7 or IE8, or Firefox browsers. When using IE, make sure you have HttpWatch installed in your development machine.
   
   The following screenshot shows how the compression results look like when you're using IE and HttpWatch. Notice on the red-highlighted shape for the compression results.