I have an issue with the Scheduler on a content page wherein when changing views of opening an AdvancedEdit form will cause a Radmenu control on the underlying master page to lose the color on the menu. The menu items are still there and the behavior is present in the IE series, 8 in particular, browsers, not Firefox or Chrome. Wondering if anyone else out there has seen this behavior.
2 Answers, 1 is accepted
0
Hello Cliff,
Can you isolate the problem in a simple demo and send it to us via a support ticket? Or, please provide us with a live url which we can test.
Kind regards,
Peter
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.
Can you isolate the problem in a simple demo and send it to us via a support ticket? Or, please provide us with a live url which we can test.
Kind regards,
Peter
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.
0
Cliff
Top achievements
Rank 1
Rank 1
answered on 30 Mar 2010, 02:49 PM
We found our issue with the menu control losing color. All controls on these pages were declaritively skinned as Web20. Turns out that we had the menu on a master page WITH the Web20 formatting css in an inline script. The content page then had a AjaxManager on it that, when anything happened with the scheduler along with it, caused the skinning to fail. We were able to make everyhing work by either removing the skinning css on the master page or by removing the AjaxManager on the content page.