John -

You are correct that the token replacement done in the embedded script when PerformSubstitution="True" is done in the ScriptResource.axd (class System.Web.Handlers.ScriptResourceHandler) which is added in the < httpHandlers > section of web.config. Although httpModules normally process the same event in the order in which they are added in the < httpModules > section I don't beleive the ordering of httpHandlers makes a difference.  Since the UrlRewriteModule is an httpModule, it is in a different section from the ScriptResouceHandler.  Just on a chance that the processing order might change, I did try reversing the ordering of the entire < httpModules> AND < httpHandlers > sections in web.config so that < httpHandlers > came first. There was no change in the behavior of the SliderExtenderControl.

In the ScriptResourceHandler, the substitution for the < %=WebResource ( . . . ) % > token in embedded scripts is done using the method GetWebResourceUrl which Ived used a number of times with success in custom extender or script controls. Testing this method at both the DNN module level and in a modified and recompiled SliderExtender.cs both return the proper relative path to WebResource.axd in the website root.  When GetWebResourceUrl is called from within ScriptResourceHandler to perform the substitution it appears to return the incorrect relative path which includes "subfolders" injected by the friendly url rewriting. Taking a look at the code for GetWebResourceUrl (found in the System.Web.Handlers.AssemblyResourceLoader class) shows that the path information is returned via the HttpRuntime.AppDomainAppVirtualPath property. Testing the value of this property at the module and SliderExtender control level shows the correct path being returned while a call from within ScriptResourceHandler apparently returns the path after friendly url rewriting has taken place.

Probably the best advice for now for control developers is to not use PerformSubstitution in scripts to resolve web resources in an environment where url rewriting is taking place. Instead, it appears better to access embedded resources in the extender or script control itself using a direct call to GetWebResourceUrl.

---

Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner

Thank you William,

That explains a lot.  I found that upgrading to the latest AJAXControlToolKit (build 11119) corrected the problem with the handle not being able to move (it also corrected another issue I found with having the slider inside an UpdatePanel where the handle was being put on the far right of the page and was un-movable even with Friendly URLs turned off).  To get my project working I set the handle like you suggested, upgrade the toolkit and set the friend URLs back ON and now everything works accordingly!

Thanks!

yogs