You seem to be using the same proxy name for the ProjectProxy instance and for the corresponding LoadupResourceProxy instance.  So, when the latter is registered, it supersedes the former.  So, when you retrieve the proxy, it is the LoadupResourceProxy you are retrieving.
----Philip

Have you registered the proxy? - must be registered before it can be retrieved.
----Philip

Tek, thanks for the above posts on Loadup and AssetTypeMap.  I'm sure the Pure AS version of the class would be useful to people.
----Philip

Maybe Loadup utility could help.  In this case, rather than a set of different ILoadup proxy classes, sounds like you would have one class and you would create a separate instance for each coordinates.
----Philip

will do.
----Philip

Just 2 alternatives to consider.
1. you could drop PROJECTS_RETRIEVED, just use PROJECTS_LOADED in the LoginMediator, use the body (i.e. the proxy name) to retrieve the project proxy and use that to get the data property.
2. use of 'app.appView.selectedIndex = 2' in a mediator might be considered too closely coupled to the internals of the viewcomponent - I think the slacker demo has an example of mediator/component interaction where the component contains a view stack - see MainDisplay.mxml and MainDisplayMediator.
----Philip

'loaded' notifications are sent by your app, they are not sent by Loadup, they are consumed by Loadup.  You must include the proxy name of the ILoadupProxy as the body of the loaded notification - note ILoadupProxy refers to the proxy in your app that has the load() method for the resource; it does not refer to the monitor.  If you don't supply a recognisable name in the body, you get the 'Unknown ILoadupProxy' Error.

When Loadup judges that loading of all resources is complete, on account of having received a loaded notification for each resource, then Loadup sends a LOADING_COMPLETE notification.
----Philip

Just to clarify about 'loaded' notifications in the Loadup utility.  The release notes in version.txt state:
    On loaded and failed notifications sent by the client app, if
    the monitor proxyName is not the default name, the notification
    type MUST BE the monitor proxyName.

So, type should be empty unless the LoadupMonitorProxy has been given a custom name.

This business of SRNAME may have arisen from the LoadupAsOrdered demo, where there are code instances like sendLoadedNotification( blah_LOADED, NAME, SRNAME ). This 'sendLoadedNotification' method is local to the demo; it is not part of the Loadup API.
----Philip

BTW, the startup manager is now at v2.0 and has been renamed as Loadup; Loadup was released recently.
----Philip

Thanks for the code; it looks fine.

I had hoped that the point I made in my last post about the sequence of notification sending might be the explanation for your query.  Have you checked out the link I included?

If that is not the  explanation, then
- I think we need to get onto some solid ground as regards the sm code and versions
- if you don't need to customise the utility in some way, then the swc should be used
- I suggest you get a specific swc; version 1.6.1 is the latest release of StartupManager
- if there are compile issues with that, and there shouldn't be, let's deal with them.

----Philip
BTW, the startup manager is now at v2.0 and has been renamed as Loadup; Loadup was released recently.

Sounds very mysterious.  If the only change you make is to remove the requires, and then they all load then it is strange. Just a few comments, in the hope of being helpful.

You say...

then they all load fine and their notifications are sent perfectly.

You know that it is your app that sends the loaded notification, for each resource, when it is loaded.  Otherwise the SM doesn't know whether the load completed; the SM starts the resource load, but you must tell it when it is finished.  This 'loaded' notification must have the IStartupProxy proxy name in the note body, so that the SM knows which resource has loaded.

So, if there are no requires, then the SM will start all the loads and they will run to completion, but you won't get a 'loading complete' notification from the SM unless you have sent a 'loaded' notification for each resource.

If there is a requires on a resource, SM won't start that resource load until the resources it requires have been loaded, that is, loaded notifications have been sent, by the app, for those resources.

Sorry if I'm repeating stuff that you are well aware of, but trying to be helpful.
----Philip

Well I had to throw in my own loading flags so its done now.

You'll understand that I'm not happy that you had to do this.  There has been no feedback on the forums indicating the sort of problem that you have had. Could you help me out by answering some questions?

What version of StartupManager swc are you using?

Since

both resources are getting managed and loaded

, I presume the utility is processing the second loaded notification.  When is the loading complete being sent? Do you mean after the first  loaded notification is sent by your app and before the second loaded notification is sent by your app?

An important point is whether your observance of the sequence of notification sending is based on the handling of notifications in a mediator.  See this topic regarding the sequence of processing of a "data loaded" notification.
http://forums.puremvc.org/index.php?topic=1049.msg4816#msg4816

If there is any of your app code that you could send me, or post here, that might enable me to reproduce or diagnose your problem, that would be great.

As regards non-recognition of setTimeout(), this could be a misunderstanding of versions and API; there was a timeout property (public access) in StartupResourceProxy pre v1.3, replaced by a retryPolicy property in versions 1.3 and following.  V1.3 was released 21-May-2008.
----Philip

What version of StartupManager are you using?

From the topic title and the content of your post, I take it that the manager is issuing the loading complete note before you have sent all the loaded notifications.

The getResourceList() method of StartupMonitorProxy could be useful; this returns an IResourcelist which offers a length property, which will tell you how many resources the monitor thinks it is managing.  IResourcelist also offers getResources() which returns the array of StartupResourceProxy objects that the monitor is managing.

The getLoadedResources() method of StartupMonitorProxy could be useful; this returns an array of StartupResourceProxy objects.  This would show you the resources that the monitor thinks have been loaded.

Hope this helps.
----Philip

As you say, it seems to be outdated classes.  In the version.txt file, I see that version 1.3 had the following information (see the full text for other migration information)
- replace monitor.defaultTimeout = nn, by
  monitor.defaultRetryPolicy = new RetryPolicy(new RetryParameters(0,0,nn))

So, I'm thinking that you're aiming at a pre v1.3 utility but using a swc for a later version.  In fact, the multicore swc only became available after release of 1.3.

As regards latest releases, note that the final release of StartupManager is 1.6.1.  The new version, version 2.0, is called Loadup, released at the beginning of this week.
----Philip

There was a glitch in the released version as regards the live demo link; load of one of the assets was failing due to an error in the asset filename. This was clearly reported in the messages text area.  The filename has been adjusted and the file is now loading.
----Philip