Hi, I'm using a treeview control on my application, and in my Dev, Test and UAT environments, I'm seeing the arrows for the expand/collapse icons.  However, on my Prod environment, which theoretically is the same as my UAT environment, I see the plus/minus signs.

Looking at the css coming down as a WebResource, on UAT, I see:

/* START Telerik.Web.UI.Skins.TreeViewLite.css */

 

But on the css that comes down from Prod, I see this:

/* START Telerik.Web.UI.Skins.TreeView.css */

I've gone through my code trying to figure out why, can't see anything.  Also, after looking through documentation on this site, I have added the following lines to my web.config, but with no change:

   <appSettings>

      ...
      <add key="Telerik.Web.UI.RenderMode" value="lightweight" />
   </appSettings>

...

   <system.webServer>

...

      <httpProtocol>
        <customHeaders>
          <add name="X-UA-Compatible" value="IE-Edge" />
        </customHeaders>
      </httpProtocol>
   </system.webServer>

 

Is there any other things I should know about my production environment that might be causing this behavior?

I'm currently using version 2017.1.228.40 of the Telerik assemblies &  running .NET 4.5.1

Thanks,

Phil

Hi Phil,

We are not aware of such problem and, unfortunately, was not able to reproduce it. Is it possible to give us a live URL where the problem can be reproduced so we can examine the cause for it further at our end?


Looking forward to your reply,
Vessy
Progress Telerik

Thanks for the reply Vessy

Ugh, I don't have any sort of reasonable way to provide a link or source code.  I was guessing that it would be related to what the control would do by default for varying environments.  What makes the control decide which skin to use?  I was thinking that maybe if you a) don't specify a skin or b) specify a skin that isn't available on the server, that the control would pick a response based on something like OS version, .NET version, etc.

What I do know is that the files (binaries, .css, etc.) in the application folder (\inetpub\wwwroot\myapp) are the same in both my UAT and Prod environments.

And this morning I remoted onto my Prod server, and accessed my page via IE, via http://localhost/<mypage>.  The result was that the expected 'arrows' were rendered instead of the plus/minus.  That doesn't really make sense to me, so I think my next step is to look at caching on that box.

Hi Phil,

The controls rendering does not depend on the environment, but rather on the refered Telerik.Web.UI and Telerik.Web.UI.Skins DLLs.  Basically the Telerik skins behave as follows:

• if no skin is set, the controls are rendered with Default skin
• if a specific !-Default skin is set, the controls are looking for the Telerik.Web.UI.Skins.dll and are loading the needed resources from there
• If a specific !-Default skin is set, but it is not found on the server (or no Telerik.Web.UI.Skins.dll is referred), a server-error that such skin does not exist is thrown, and the controls are not rendered at all

Long story made short - If both the Telerik.Web.UI and Telerik.Web.UI.Skins DLLs are referenced in your project, all skins should be working properly.

The only possible reasons I can think of (if the render mode of all controls is one and the same) is that the browser is running in compatibility mode or a JavaScript error is thrown on the page. Can you, please, verify that neither of this is the case?

Can you also examine the output HTML of the page holding the TreeView and check whether the controls version used on both machines is one and the same? The version of the controls is available in one of the first comments on the page - screencast.

Regards,
Vessy
Progress Telerik

Sorry it took me over a year to reply.  Yes, what this finally turned out to be was that I had some instances of controls that did not specify a skin.  Once I set the skin to match what we were using for other control instances, this was fixed.  I don't know why we were getting different result on different web servers, maybe it was based on what version of Windows they were running.  However, our Production server (the only server that was giving us the 'bad results) should have been the same as our other test servers.

Anyway, thanks for the info.  It was helpful.

Hi,

Thank you for sharing the cause of the problem with our community, Phil - I believe that it will be helpful for the developers that stem upon the same problem.

Kind regards,
Vessy
Progress Telerik