I will put a sample and a Fiddler trace together to help resolve this.  I definitely think the issue is related to having LOTS of instances of IScriptControl derived controls on a page.  This is what concerns me about any effort to do any filtering of my own in each control's rendering processing as well as having the ScriptManager do it.  I can easily have 100 such controls on a page at a time (since some are hidden inside TabPanels that become visible only when the user selects the panel).

 That is a LOT of work in processing against a hash table over and over and over.  This must represent a performance issue under heavy load, but that is a separate story to investigate.

One more thing that could explain this...

 The notifyScriptLoaded() callback that you added to the bottom of the script... you only need to add that if you are referencing the script directly as a .js file. If the script is an embedded resource, you don't need to add it, because the script resource handler adds it for you automatically. If you added it yourself, the resulting script could have 2 of these callbacks at the end, and that will definitely cause some problems. If that is what is happening you should be able to take a look at the response from ScriptResources.axd and see two notifyScriptLoaded callbacks at the end.

I did put those statements at the end of my embedded scripts, so I will remove those and test again.  I will report on the result!

 

Thanks again for looking at this.

I found through testing that you actually DO need that special script at the end of EVERY script file referenced either in the <Scripts> section of the ScriptManager definition OR any return to the call on the IScriptControl interface--embedded or not.  When I removed them, I got errors all over the place, so I had to put them back.

 I am still working up the sample application to use for testing my problem, which I still have.  It will be very complete, show my intended architecture beyond just the IScriptControl stuff, and will represent a good test case for a more extreme use of the whole infrastructure.

I would, at that time, welcome any comments regarding the design and architecture of the sample also, so I know whether it represents a best practice or not.

 

Its not a question of whether they are in the scripts collection or not... if a script is provided through the ScriptResources.axd handler, the notifyScriptLoaded call is added for you automatically. So if your embedded script already contains this script, whether its included through <scripts> or as a ScriptReference from a script control, it will end up having two of these calls. The only time you need to worry about putting in the class yourself is if you are referencing a .js file directly, because you aren't going through the ScriptResources.axd handler that way.

I apologize for waiting a few days to post again on this problem, but in the course of doing the development of a prototype to highlight the problem, the problem was solved!  In general, the following rules definitively work:

• All external scripts must have the following blurb and the end of the file:
  if (Sys && Sys.Application) { Sys.Application.notifyScriptLoaded(); }
• Be sure to include the entire references chain in your return to IScriptControl methods back to where your inheritance tree stops in the references at the ScriptControl level.

I am still not entirely convinced that the queued script loading does not still represent a problem under some circumstances (like when you use a descriptor to pass a reference to a control that might not yet exist at the time the control is processed). In these cases, I pass only a component ID instead of using the descriptor's AddComponentProperty or AddElementProperty methods. I then do delayed, lazy loading of the actual control reference in some "get" method, so I can assure that the reference is available if it ever existed at all.

Great - glad it's fixed for you ..Here's a little more background on the lifecycle and component creation model ..

In your IScriptControl, IExtenderControl, ExtenderControl types, the 'GetScriptDescriptor' returns descriptors for client-side components that the server control or extender 'handles'. That is the scoping of the client-side components are those 'encapsulated' by the server control or extender. In this manner you'll be creating components that you know about and can handle references between them as needed.

AddComponentProperty means that in the client an instance reference from one 'component' to another is set. This is handled in the client by Sys.Application and $create using a '2-pass' model which means components can be created in any order and have circular references if needed. Creation of components at the particular lifecycle stage news the component, sets simple properties and events, registers the component etc., but delays setting complex reference properties for a '2nd pass'. AddElementProperty essentially causes $gets in the $create, and these are simple property sets to DOM elements only, through ID. Note that all this happens after the scripts are loaded.

If a page developer in their app, wishes to $create client-side components directly, then ordinarily they can do this in the pageLoad lifecycle stage in the app. (this is called on GET and async requests). However, in this case, if the components have circular references, then there are two approaches to achieve this. 1) hook to the init stage (Sys.Application.add_init()) and in that hander perform the $creates as necessary. This means that the 2-pass model will handle these; 2) In pageLoad 'wrap' the $creates with a call to Sys.Application.beginCreateComponents before the $creates and Sys.Application.endCreateComponents after.

The alternative model of using a 'string' ID, is a totally valid model therefore only requiring the simple AddProperty through the descriptor. As you state, in the setter you can internally in your component use $find to locate that reference component if needed. This also might be a simpler approach if you really intend your client-side component to allow the page developer to set 'references' from other components that they construct.

 

 

Thanks very much for the information!  This is the best description of the component loading process as it relates to IScriptControl that I have ever seen.  It is a shame that this great information is buried deep in this discussion thread where people needing the information will be lucky to ever see it.  I appreciate your reponse, and I will post it on my blog, although who knows how many people will ever see it there except for those who know me (and realize that I am actually fabulously famous!).

I must say that I saw the two-stage loading code and thought I was safe passing in the component ID's through the AddComponentProperty() method. However, I still ended up with the reference sometimes being null in my initialize method, and I believe this resulted from the fact that the component I was references was ALSO returned as a descriptor in the SAME IScriptControl descriptor enumerator. Although I assured that the component to be referenced appeared in the returned array FIRST, it still did not make it by the time I was wanting to use it. This is why, to be safe, I started using just the component ID's in the AddProperty() method. This seemed to work.

I am not sure if it is kosher to return multiple descriptors from the GetDescriptors() method, but you must require an enumerator to be returned for this reason. I use this mechanism, so I can return a separate "controller" component already attached to my control when the script loads up. The controller knows about all the "sub-components" on my page (text boxes, and other controls), and handles the binding/update cycle as dictated by the "model," which is a singleton for the whole page instance and handled global behavior like when any component web service is active, etc. Is this a good use of these methods?