 |
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Lauren Park - [12/31/07 11:53 AM ]
re-assigned to Peter.
Able to repro using IE7/WinXP (SP2), WIN 9,0,115,0 (debug), Flex SDK Version 3.0 build 191831
Loading a 1.8MB SWF from a remote server with just .../main.html would display a progress bar, but there wasnt any progress bar visible when loading .../main.html# or .../main.html#app=2214&c802-selectedIndex=1 Recommend defer. Is this a problem with the flash player, or with the SWF? I assumed it was the player..
We use a preloader on whirled.com with our 1MB swf, and since we use GWT to generate all the web pages, pretty much everything has a # in the URL, preventing the preloader from ever working. Gosh it'd be nice if this were fixed... It doesn't seem to occur here in FireFox, so I'm going to guess it's an ActiveX player issue.
We've seen this happen with our product on every platform, and all major browsers. The preloader fails to load on Linux, Windows and Mac, under IE, Firefox and Safari... As long as the URL contains "#" for deep-linking, the preloader won't load for us.
Re: Nathan's comment
My app is Flex 3, compiled using the Builder 3 beta on Linux. The url is like 'http://foo.localdomain/#' or 'http://foo.localdomain/#view=1' and our custom preloader appears (briefly, with a full progress meter) in FireFox 3 (32-bit player, 64-bit Linux [OpenSuSE]) with the .124 debug player. The only think I can think of is that in our preloader once FlexEvent.INIT_COMPLETE is triggered, we do some further processing and then do this.dispatchEvent(new Event(Event.COMPLETE)); this.loader.ready = true; when that has finished. Maybe the (default) preloader doesn't draw anything (or pause for breath like ours does) if the load time is small, or jumps straight to 100%. As a test/workaround, could you try setting the protected MINIMUM_DISPLAY_TIME to a non zero value (say 2000) in a subclass of DownloadProgressBar and use that as your preloader ? Re: Tom's latest comment.
I'm replying for Nathan as well, since we work on the same project. The preloader does briefly run, the problem is that it doesn't do it until all the frames are loaded. Using a minimum display time isn't what we want- we want the app to show up ASAP, but to show the preloader when possible while loading the rest of the app. Using the minimum display time doesn't solve this problem, just makes it so that the preloader will continue to show even after the rest of the app is ready. We are using a custom preloader, implementing IPreloaderDisplay, rather than subclassing DownloadProgressBar. I have very simple test code that demonstrates the problem. A preloader is initialized by the (confusingly named) Preloader class, which is created by the SystemManager. Preloader instantiates the IPreloaderDisplay instance and calls a number of setters on it to initialize it. The last thing set is the Preloader itself, so that the display can listen for PROGRESS and INIT_COMPLETE events, etc. Here is our implementation of this method: // from IPreloaderDisplay public function set preloader (value :Sprite) :void { value.addEventListener(ProgressEvent.PROGRESS, handleProgress); value.addEventListener(FlexEvent.INIT_COMPLETE, handleComplete); // TODO: remove the following debugging var mc :MovieClip = value.root as MovieClip; var working :Boolean = (mc.framesLoaded < mc.totalFrames); trace("----> Preloader " + (working ? "DID" : "did NOT") + " work."); } If I put our app in an HTML page and load it directly, mc.framesLoaded == 1 and mc.totalFrames == 2. The preloader is getting set up as soon as possible. If I simply add #foobar to the URL of that page, then mc.framesLoaded == 2. The preloader is not getting set up until the entire movieclip has finished loading. I have the exact same symptom - the # mark as a trigger. we're still looking into it
I have more customer feedback: Yaaaay!!! Thank you!
I can confirm that adding a # to the end of the url will cause the flex built in preloader to not load during the swf downloading phase.
Preloader works when the # is removed from the url. Browser: Firefox 3.03, Windows XP This issue was 1st reported nearly a year ago. Can we please have some feedback on when the fix for this problem is anticipated / be provided with an interim work around.
Deep Linking is essential and simply not being able to feedback to user what is happening while the app loads is not acceptable. Please ignore last post.
We have figured out a work around that allows us to use deep linking and have a pre-loader that works properly... Leonard, is it possible to include an outline of what you did, for the benefit of the other people who'd like that same fix ?
I am having the issue not with preloader.. but the deep linking just seems to get stuck after a navigation out of the page...i.e. opening a new window....
Is there any news? Please give us an update. Thanks
What about a workaround? Could Adobe or someone post a workaround?
Thanks. You can create a small SWF that serves as prealoader that loads your application and in this way you would have preloader that shows up instantly and deep linking working.
Cyprian Kowalczyk,
Can you give me a few more details please? A small SWF created in Flex 3 or in Flash 9? Load the large Flex application with SWFLoader? thanks. @William Chadwick:
Create small Flash app that loads flex app using Loader class. When load completes remember to wait for the flex app to advance to the second frame to know when it's ready for action. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Under Investigation
B
Preloader not showing up when we add deeplinking urls