Q2 breaks my custom skins! Help!

[Jeff]

After updating my dll with the Q2 version, my custom skins are broken, particularly with the panelbar. On closer inspection, I see many new classes in the panelbar css for the newest versions of the embedable skins, and it looks like the new dll is looking for these new classes when rendering the controls. Is it possible that I can update to Q2 without recreating all of my custom skins (I have dozens)? Help! Help! Help!

[Kamen Bundev]

There were major changes to skin rendering in Q1 2009, but I guess you missed that one. From which version are you upgrading from? We offered free upgrade of your custom skin, you only need to open a support ticket and send the broken skin to me (along with any images and additional information if it needs any).

All the best,
Kamen Bundev
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.

[Jeff]

Actually this was a one version upgrade from Q1 2009 to Q2 2009 so we had already gotten over the pain of the major Q1 skin redo and thought things were settled down.  Now, when we installed the new Q2 DLL our RadPanelBar expand arrows got all dorked up (they repeat all the way across the panel instead of just showing up 1 time on the right side).  We did a compare of the Q1-09 panelbar css and the Q2-09 panelbar css and it seems you guys added a huge chunk of new CSS with new styles, etc.  Digging deeper (Beyond Compare is very cool by the way) it turns out you guys touched every single control CSS to some degree or another between Q1 and Q2.  If we only had "canned" skin sites or only had a few custom skin sites this would be one thing but we are customizing the skins to some degree for each of our clients and we currently have 20 custom skin sites with literally thousands to come.  I am very concerned about moving forward at this point if we are going to have a skin nightmare 3 times a year when you guys rollout a new Q.  Can you give me a better feel for if skins will continue to be tweaked this way with each new Q and, if so, what my migration path is for customized skins?  I don't want to be stuck in an ancient version of Telerik because I can't upgrade without breaking all my client site skins and I can't afford to totally redo all my client custom site skins 3 times a year.  HELP!!!

Thanks!

[Alex Gyoshev]

Hi Jeff,

The necessary styles to solve the problem are the following (just append them to your skin files and you're good to go (remember to change the suffixes)):

/* <background positioning> */
.RadPanelBar_Vista .rpLink,
.RadPanelBar_Vista .rpExpanded
{
	background-position: 0 0;
}

.RadPanelBar_Vista .rpFocused,
.RadPanelBar_Vista .rpLink:hover,
.RadPanelBar_Vista .rpExpanded:hover
{
	background-position: 0 -200px;
}

.RadPanelBar_Vista .rpSelected,
.RadPanelBar_Vista .rpSelected:hover
{
	background-position: 0 -400px;
}

.RadPanelBar_Vista .rpFirst .rpLink,
.RadPanelBar_Vista .rpFirst .rpExpanded
{
	background-position: 0 -1px;
}

.RadPanelBar_Vista .rpFirst .rpFocused,
.RadPanelBar_Vista .rpFirst .rpLink:hover
{
	background-position: 0 -201px;
}

.RadPanelBar_Vista .rpFirst .rpSelected,
.RadPanelBar_Vista .rpFirst .rpSelected:hover
{
	background-position: 0 -401px;
}

/* <root items (disabled)> */
.RadPanelBar_Vista .rpDisabled:hover
{
	cursor: default;
}

.RadPanelBar_Vista .rpDisabled,
.RadPanelBar_Vista .rpDisabled:hover,
.RadPanelBar_Vista .rpDisabled:hover .rpOut
{
	background-position: 0 0;
}
/* </root items (disabled)> */

/*      <expand arrows> */
.RadPanelBar_Vista .rpExpandable .rpText,
.RadPanelBar_Vista .rpExpanded .rpText
{
	padding-right: 20px;
	background-repeat: no-repeat;
}

.RadPanelBar_Vista_rtl .rpExpandable .rpText,
.RadPanelBar_Vista_rtl .rpExpanded .rpText
{
	padding-left: 20px;
}

.RadPanelBar_Vista_rtl .rpGroup .rpText
{
	padding: 0 10px;
}

.RadPanelBar_Vista .rpExpandable .rpText { background-position: 100% 0; }
.RadPanelBar_Vista .rpExpanded .rpText { background-position: 100% -176px; }
.RadPanelBar_Vista_rtl .rpExpandable .rpText { background-position: 0 0; }
.RadPanelBar_Vista_rtl .rpExpanded .rpText { background-position: 0 -176px; }

.RadPanelBar_Vista .rpExpandable.rpSelected .rpText,
.RadPanelBar_Vista .rpExpandable.rpSelected:hover .rpText
{
	background-position: 100% -337px;
}

.RadPanelBar_Vista .rpExpanded.rpSelected .rpText,
.RadPanelBar_Vista .rpExpanded.rpSelected:hover .rpText
{
	background-position: 100% -476px;
}

.RadPanelBar_Vista_rtl .rpExpandable.rpSelected .rpText,
.RadPanelBar_Vista_rtl .rpExpandable.rpSelected:hover .rpText
{
	background-position: 0 -337px;
}

.RadPanelBar_Vista_rtl .rpExpanded.rpSelected .rpText,
.RadPanelBar_Vista_rtl .rpExpanded.rpSelected:hover .rpText
{
	background-position: 0 -476px;
}

/*      </expand arrows> */

.RadPanelBar_Vista .rpGroup .rpLink,
.RadPanelBar_Vista .rpGroup .rpLink .rpOut { background-position: 0 200px; }

.RadPanelBar_Vista .rpGroup .rpLink:hover,
.RadPanelBar_Vista .rpGroup .rpFocused { background-position: 100% -22px; }
.RadPanelBar_Vista .rpGroup .rpLink:hover .rpOut,
.RadPanelBar_Vista .rpGroup .rpFocused .rpOut { background-position: 0 0; }

/*      <subitems (selected)> */
.RadPanelBar_Vista .rpGroup .rpSelected,
.RadPanelBar_Vista .rpGroup .rpSelected:hover { background-position: 100% -222px; background-color: transparent; }
.RadPanelBar_Vista .rpGroup .rpSelected .rpOut,
.RadPanelBar_Vista .rpGroup .rpSelected:hover .rpOut { background-position: 0 -200px; }
/*      </subitems (selected)> */

/*      <subitems (expand arrows)> */
.RadPanelBar_Vista .rpGroup .rpExpandable .rpText,
.RadPanelBar_Vista .rpGroup .rpExpandable:hover .rpText { background-position: 100% -938px; }
.RadPanelBar_Vista .rpGroup .rpExpanded .rpText,
.RadPanelBar_Vista .rpGroup .rpExpanded:hover .rpText { background-position: 100% -1078px; }
.RadPanelBar_Vista_rtl .rpGroup .rpExpandable .rpText,
.RadPanelBar_Vista_rtl .rpGroup .rpExpandable:hover .rpText { background-position: 0 -938px; }
.RadPanelBar_Vista_rtl .rpGroup .rpExpanded .rpText,
.RadPanelBar_Vista_rtl .rpGroup .rpExpanded:hover .rpText { background-position: 0 -1078px; }
/*      </subitems (expand arrows)> */
/* </background positioning> */

Indeed, we changed the PanelBar skins between the two releases - we (or more specifically, I) made the mistake of writing the background-position into the base stylesheet - with the intent to make the skin files as small as possible. This, however, led to tremendous complications with custom skins - it actually forced you to use specific sprites or write a pile of overrides. We strive to keep such changes to a minimum, and I learned a valuable lesson. Please excuse me for the caused trouble.

That said, we will always be here to help you with the migration, if such issues occur.

Greetings,
Alex
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.

[Jeff]

Thanks for the info Alex.  I see the changes I need to make to my custom skins to add the new RadPanelBar css classes but I guess my real question is this:

If my intention is to use Telerik controls to develop a subscription web service where each of my clients can have a customized version of one of the core Telerik skins (changes to colors, heights, etc.) and if the number of those clients will ultimately reach 4000+.  What can I do to make it so that I don't have a complete nightmare each time a new Telerik Q release comes out and the skins have been tweaked?  Right now, when I get a new client I am grabbing the telerik skin that looks closest to the way they want their site to look and then I tweak the CSS to make it look exactly how they want it.  This may be a little and it may be a lot, but either way I end up with a new custom skin.  With this approach, If I had 4000 clients right now, in order to move to Q209 I would have to add these 10+ new CSS classes to the panelbar.css for all of those 4000 clients.  Is there a better way to accomplish this than what I am doing now?  Something that won't cause the Q update nightmares that I am foreseeing in the future as my client base grows?

Any help would be greatly appreciated.  I love the Telerik tools and very much want to keep using them.

Thanks.

[Alex Gyoshev]

Hi Jeff,

Difficult situation, indeed.

We keep the changes to the skins to a minimum - with the Q1 release we broke all imaginable scenarios and made the commitment to not do this again. The changes in the PanelBar were a big exception.

To recap - no matter how much we want to, we cannot promise that upgrades will not break your custom skins. What we can do is to provide you with a way to make customizations easier (the Visual Style Builder), and what is more important for you - we can promise to provide a migration tool for such changes. Do you think that this is a reasonable solution?

Greetings,
Alex
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.

[Jeff]

If by a Migration Tool you mean something I can run that will update my custom skins with any changes or enhancements added in the newest Q release then I say that sounds GREAT.  Do you have such a tool now for Q209 or is one coming in the near future?  And are you saying you will be providing such a tool for each future Q release?  If so, that gives me a much greater feeling of comfort moving forward with my current Telerik plan.  Looking forward to hearing more.

Thanks very much for your time and feedback Alex. 

[Marc Messer]

I just spent about an hour yesterday comparing Q1 to Q2 skins... would there be any way in future releases to get a changelog for the CSS?

[Jeff]

A changelog would be good but a migration tool to automatically add new and changed styles to any existing custom skins would be fantastic.  I am hoping that is what Alex is talking about.

[Alex Gyoshev]

Hello Jeff, Marc,

My initial idea was specifically for this version of the controls, yet I guess it would be nice to provide such one where it is possible. Unfortunately, we don't have such a tool in the moment, but I'll deliver it until Wednesday, 22. July. It will be only for migration of 2009.q1 to 2009.q2, and I will strive to provide it with further releases, too, if we are to introduce severe breaking changes, as it is with this case.

I'll update this thread once the tool is ready. If you have any preferences (e.g. you would like to integrate it into your build process, etc) - please let me know. I'll see what I can do about it.

Sincerely yours,
Alex
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.

[Jeff]

Fantastic, that will be very helpful, thanks Alex. 

[Marc Messer]

Sounds good, I just use winmerge and compare back and forth.

[Alex Gyoshev]

Hello guys,

Please find attached the Universal Migrator! (I am good at naming things)

I'm sending both a binaries release and the source. Just to clarify, the "create backup" checkbox works with a copy of the source folder, instead of the actual one (the copy is suffixed with "_Migrated").

Let me know if this is a plausible solution.

[Update] Jeff pointed out an obvious mistake. Source and binaries have been updated.

Sincerely yours,
Alex
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.

[Jeff]

Hey Alex,

Thanks for the migration tool.  However, when I ran it today on one of my Q1 customized skins it didn't add the radpanelbar additional styles you posted about on 7/15 so my skin was still messed up after the conversion.  It did make some other changes but not those.  Any ideas?

[Alex Gyoshev]

Hello Jeff,

The tool highly depends on the file naming - the custom skins should be named PanelBar.SkinName.css. Other than that, I think there are no other requirements. If that is not the case (i.e. your skins are named this way), please send me a few so that I can debug it. I've tested it with the Skins directory from the Q1 release and it migrated it right away.

Sincerely yours,
Alex
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.

[Jeff]

Hey Alex,

My custom skin css files are following the naming convention (ex. PanelBar.CamelRed.css).  As I said earlier, the migration program does add some new classes to the css file but not the critical ones that solve the "repeating dropdown graphic" problem.  I have opened a support case and attached the before and after conversion skin for you to review.

Thanks.

[Dave]

Do you have a similar tool available for converting my 2009.Q2 custom Dock skin to 2009.Q3?

The article referenced in your support section is not very helpful:

Custom RadDock skins are not compatible with the improved rendering of the control that was introduced with Q3 2009.
An article that explains how to rework old custom skins is available on the following page:
http://www.telerik.com/community/forums/aspnet-ajax/docking/using-old-custom-skins-with-raddock-q3-2009.aspx

[Pero]

Hi Dave,

We do not have such tool that will convert the custom skins compatible with the new rendering. But if you open a support ticket, and send us your custom skin, we will help you rework the skin.

Greetings,
Pero
the Telerik team

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.