Accordian - Smooth at first, then gets choppy

Here's what I have. I've got an accordian in a web user control. And I've placed it on all my pages. When I go to the first page it runs VERY smooth.. but once I click on a link from the accordian to another page.. the refreshed accordian user control is all choppy.

I also tried this with a datagrid in an update panel as a user control and it did the same thing. So I know it's not the accordian. It has something to do with atlas. I compared the source from a smooth page and a choppy page and there's no difference..

so what do I have to do to keep it smooth? or can you not use it as a web user control?

Apparently.. it's all IE6's fault.. ugh that really sucks.. I don't know if I can get the whole company to upgrade to IE 7 Beta 3.. stupid flickering..
Hi unlikelyband,

Did you discover a specific reason IE6 was causing this? Or is it just only IE6 that it happens in?

Thanks,
Ted

Well. I actually only tried IE 6 and IE 7 Beta 3.. and IE 7 is really smooth..

I don't really have time to text IE 5 or opera or firefox..

All I know is that it kind of sucks people are going to have to deal with the flicker until they manage to upgrade everyone to IE 7

Hi,

Well it's true that the animation in IE6 isn't as smooth as IE7 and Firefox, but we're working on making the accordion snappier. Hopefully it won't be a problem for you and your users after the next release.

Thanks,
Ted

a bug of ServicePath

the ServicePath can't parse "~/", since the control runs at "server", it should can.Agreed - we'll get a fix for this and post the code here.

Good find, mg1616! This issue was also brought up by someone else in a separate instance. I've just checked the following change in to the implementation of CascadingDropDown so it'll be available with future releases of the Atlas Control Toolkit. For now, simply paste the new method below into the implementation of the CascadingDropDown class in CascadingDropDownExtender.cs (perhaps below the OnLoad override). My testing suggests that it enables "~"-based virtual paths as requested.

Thanks so much for your help!

/// <summary>/// Override ExtenderControlBase.SerializePropertyToString to fix up virtual path references/// </summary>protected override string SerializePropertyToString(CascadingDropDownProperties props, PropertyDescriptor prop,bool force){string result =base.SerializePropertyToString(props, prop, force);// Fix up virtual path references for the ServicePath propertyif ("ServicePath" == prop.Name) { result = ResolveClientUrl(result); }return result;}

Regarding this:

if ("ServicePath" == prop.Name)

It seems to me that we have some incestuous knowlege of the name of the property. I suggest that in general the property names should be exposed by the respective Properties class. This would eliminate a whole host of oopsies. That gets us to:

public class CascadingDropDownProperties : TargetControlPropertiesBase<DropDownList>{// Constant strings for each property namepublic const string stringParentControlID ="ParentControlID";public const string stringCategory ="Category";public const string stringPromptText ="PromptText";public const string stringServicePath ="ServicePath";public const string stringServiceMethod ="ServiceMethod";

Of course, that makes the names of the constants appear quite ugly (I thought "Hungarian" notation was dead by now). My coding convention leads to this:

public class CascadingDropDownProperties : TargetControlPropertiesBase<DropDownList>{// Constant strings for each property namepublic static class PropertyName {public static readonly string ParentControlID ="ParentControlID";public static readonly string Category ="Category";public static readonly string PromptText ="PromptText";public static readonly string ServicePath ="ServicePath";public static readonly string ServiceMethod ="ServiceMethod"; };

Yeah, I see your point. I'm not really sure that makes ita lotbetter with respect to your concern. In either case you're still relying on the property string name. Your method is a little better, I'll agree.

But in this case, David and I were talking and think we have an even more general solution in mind that would require none of this. Basically, mapping a property to a client URL is something that will happen regularly so I think we'll bake this into the framework for our next release, probably later this month.

Thanks!