User Profile & Activity

Bernard Xiang Member
Page
of 52
Posted: February 6, 2013 9:24 PM
Hi,

Actually, our component couldn't use this method for compressing. Some of response headers cleared during life cycle. However, our component itself had introduced with GZIP and Deflate compression. You can use the method using our code above to enable compression method on your WebCombo.

<add key="ISNet.WebUI.ISRes_Compressed" value="true" />

This method will automatically compress your web page regarding your browser capability.

For more information, please visit:

Hope this helps.

Regards,
Bernard
Posted: February 5, 2013 9:37 PM

Hi,

You can compress the data inside WebCombo using SmartWebResources compression. To use SmartWebCompression, please add this tag inside your web.config:

<add key="ISNet.WebUI.ISRes_Compressed" value="true" />

Regarding to your problem, could you inform me the method that you used to compress the page that you mentioned above? It will be better if you have working sample so we can trace operation that run in your side.

For more information about SmartWebResources compression, see
http://intersoftpt.wordpress.com/2009/09/21/rich-features-in-low-client-footprint/

Regards,
Bernard

Posted: February 3, 2013 9:52 PM

Hi Ellen,

Using your code that you gave me above, I tried to replicate your issue in our local end. I also put the same structure like yours in my website. Unfortunately, I couldn't use some other assembly and user control like InputMask, GroupValidator, CRISCommandInterface, and etc because we don't have it in our local end. So I delete other control that are not ours, so I can run the website in our local end.

However, when I tried to run it in IE9 browser, Default.aspx can be loaded perfectly and it only used less than 10 seconds to show the website in our local end. Although, when I open RMSDefault, it takes 3 seconds to show the PropertyRecord page but it is expected because there are many WebCombo controls inside that page.

To replicate your issue in our local end, we need a running sample that can replicate your issue in our local end. This is necessary because we need to trace which control that make this issue happen in your local end. Look forward to hear any feedback from you so I can help you further.

Regards,
Bernard

Posted: January 30, 2013 10:14 PM
Hi Ellen, 

I've tried to replicate your issue in our local end using your configuration of WebDesktopManager. Unfortunately, I our local end, WebDesktopManager rendered normally. It just need less than 10 seconds to show all of rendering. The time span also caused by the controls that you're using in the same page.

Therefore, we need to replicate your issue in our local end to trace where the issue come from. If possible, could you send us a simple sample that can be executed in our local end? Look forward to hear any feedback from you so I can help you further.

Regards,
Bernard
Hi Dave,

Actually, this matter happen because the data that requested has different format between the data that stored inside xml or database itself and with your culture. However this matter doesn't occurs from our control. To resolve this, you can configure the project like this page:

http://www.intersoftpt.com/Community/ClientUI/UXScheduleView-and-Cultures/

Hope this helps.

Regards,
Bernard
Hi Andre,

Is this issue has been fixed in your local end? I think there are some errors that happen in you local end when you install our product at first. In here, we have tested all of our component in different environment and that seems fine. If you have any further question, please don't hesitate to ask us.

Regards,
Bernard
Hi David,

I can replicate your issue in our local end. This problem might be happen because you're using other than English (United States) culture in your environment that causing different for format for datetime value. To resolve this, you can simply change the culture of your environment to English (United States). For more information, please visit http://www.intersoftpt.com/Community/ClientUI/Having-troubles-launching-some-of-the-live-demos. Hope this helps.

Regards,
Bernard
Posted: January 29, 2013 9:25 PM
Hi David,

I can replicate your issue here. This issue happen only in documentation in Help Viewer 2 (Visual Studio 2012). We will fix this problem soon and I'll let you know if I heard anything regarding this issue from our developer team. For now, maybe you can use documentation in Help Viewer 1 (Visual Studio 2010 or earlier) instead of using Help Viewer 2. Thank you for your valuable feedback.

Regards,
Bernard
Posted: January 28, 2013 8:51 PM

Hi,

Glad that you have found the problem. Actually WebGrid in version 7, only can be rendered properly using XHTML and HTML4 doctype. This is why if you're using compatibility mode, some rendering won't be rendered like we expected. This problem might be happen because some configuration in your website force your website to show in compatibility view.

It's better if you used WebGrid 8, so you can put the RenderingMode to XHTML, HTML4, or HTML5 regarding your requirement. Our WebGrid 8 support all of three doctypes. If you have any further question, don't hesitate to ask us.

Regards,
Bernard

Posted: January 27, 2013 11:53 PM
Hi Clinton,

I tried to replicate your issue in our local end. But unfortunately, I couldn't replicate your issue in our local end. Could you let me know any configuration or style that you used inside WebGrid and tell me the step to replicate this issue in our local end? If possible, is there any simple sample that can replicate this issue in our local end? When you deploy your website, please ensure if ISNet.dll, ISNet.WebUI.dll, and ISNet.WebUI.Resources.dll has been added to your project's bin folder. Look forward to hear any feedback from you so I can help you further.

Regards,
Bernard
All times are GMT -5. The time now is 1:36 AM.
Previous Next