I have a Flex 4 application that loads Flex 4 applications into it by using the mx.controls.SWFLoader component. I load the same swf-subapp several times as each subapp also runs standalone, and the content of the subapp is determined by a XML that I pass into it via the loader context.
This has worked until recently, but now, the second time I load the same swf (with a different xml) the loaded swf stops executing anything after the FlexEvent.INITIALIZE is triggered (I'm not doing anything in my initialized event handler). In other words, I don't get a CreationComplete event, which is where I start my code (and worse, no errors either).
As I've been working on a different part of my main application, I can't quite remember which change crashed my project, but what I do remember is that I updated my Flex SDK and I've hade similar silent errors in relation to a SDK upgrade earlier.
In my main application I do cleanup after myself before loading a new swf, so it shouldn't be garbage laying around.
Please help!
Solved it.
There was an enterframe handler that kept the first instance of the swf in memory, that in some way blocked the next one from loading (eventhough I used the removeAllElements on the parent container and hoped that would do the trick).
Now I use a NativeSignal and remove all listeners from that on onRemove handler (RobotLegs). Works like a charm.
Related
Im creating an android game and started using TextureAlias for game assets, creating it as: TextureAtlas(Gdx.files.internal("assets.atlas")) and getting AtlasRegions simply by atlas.findRegion("my_asset") then setting this region into a sprite. Everything works fine, textures are rendered properly but after I put my app into background (methods pause and hide are called) and then bring it back to front (show is called) my assets are broken, they are grayish, not totally black as they would appear after calling dispose on TextureAlias - what am I missing? Should I be recreating TextureAtlas each time show is called?
When you as an Android user leave an app, there are 2 things that could happen.
One thing definitely happens, and that's "actually pause", which means the app is still running but not active.
If Android needs the resources, it might "actually kill" your app even though you think it's running.
(You can search Android App Lifecycle for more info)
In the first case, nothing would happen, your GL context would still exist and everything should work.
In the second case, however, your original GL context won't exist anymore, which means the textures would be bust.
The correct solution is to put your TextureAtlas load functionality into the create() function of your Game, so it will be reloaded only if the app was killed and not if the user switched out and in again.
You will of course also need to reconstruct the screen so it uses the new textures.
I have an http handler built and running on my website server. Code in flex generates a http request then navigates to the handler, which generates and streams back file information for the user to download.
Basically the request sends image data and the return result is a pptx stream with the image data in a powerpoint slide.
This worked fantastically this morning until about an hour ago. I have no idea what changed, but every swf I am building which attempts to access this handler is now giving me:
* Security Sandbox Violation *
Connection to https://g1.localhost/Turm/BounceBack.aspx halted - not permitted from https://g1.localhost/Turm/FlashApps/ImageAndExporting.swf?debug=true
I even fully qualified the BounceBack.aspx name (it was a relative url until just now) in case something was confusing the flash player, but as you can see, the url request and the swf are loaded from exactly the same domain (even the same virtual app in the web domain).
I have even added the physical filepath as a 'trusted folder' in my flash player security settings.
What gives? Anyone have any suggestions?
Using the Apache 4.9.1 SDK and latest version of flashplayer.
As mentioned, this worked all day yesterday and this morning. I cannot figure out what has changed, but am having no luck resolving the issue, source code has not changed.
Finally figured out what changed. I move the navigation to my ASPX handler into a seperate method that delays invoation till after a UI update. Becuase I use the same ui components for printing as well as exporting, I tested the updates with the print feature and that worked without error. About an our later, I noticed the handlers were failing. Since the url request is not handled inside a UI interaction event (Like MouseEvent.CLICK) the flash player was preventing the call. Once I moved the navigation back into the event handler, the sandbox violation went away.
If you ask me, not a very good error message due to the actual problem encountered, but ... you learn something every day.
I'm developing a plugin using FireBreath on Windows (for now) that among other things is displaying a webcam feed using OpenGL. I'm using a windowed plugin and I'm drawing from a separate thread. The code can be viewed here:
Header file
https://github.com/EvilTengil/kinect-at-home-plugin/blob/0007beecf136ff2e5e1aa50be94d4906447a8f43/Win/KinectAtHomeWin.h
Source file
https://github.com/EvilTengil/kinect-at-home-plugin/blob/0007beecf136ff2e5e1aa50be94d4906447a8f43/Win/KinectAtHomeWin.cpp
(Ignore the strange code in onWindowResized, it's just some testing that remained in the commit.)
The problem is that as soon as the browser window is re-sized so that the visible region of the plugin is changed or the the extension is somehow scrolled outside the visible area of the scroll box, the plugin crashes in Chrome. I haven't got Firefox installed but I'm guessing it's a NpApi thing, since it's working in Internet Explorer.
I believe what is happening is that Chrome releases and creates a new HDC whenever the visible dimensions of the plugin is changed. This probably results in that the Rendering Context is invalid, but it is still being used in the plugin and that causes the crash.
I've noticed NPP_SetWindow get's called when this happens, but those calls are ignored in NpapiPluginModule_NPP.cpp, so my there is no way of hooking in to this event.
I've Google for several hours now but without finding any help. Does anyone have any experience of this?
I have an idea that it could work if I created my own child window to the plugin window where I could handle my own DC. I did some quick testing that failed, which is probably because of my lame Win32 skills. But could this work with some more work? Another idea I have is to track the visible region somehow, but I haven't looked in to this yet.
Windows handles getting invalid should not cause a program to crash per so. But OpenGL, namely its extensions require some special precautions, especially if the host program makes use of OpenGL as well.
Any kind of plugin or DLL that makes use of OpenGL must take care, that is puts its required resources into a sane state before using them, and put them back once done. For OpenGL this means, everytime before you start using it you should rebind your context:
HDC hOldDC = wglGetCurrentDC();
HRC hOldContext = wglGetCurrentContext();
// first unbind old context/DC from current thread
wglMakeCurrent(NULL, NULL);
// then bind our context
wglMakeCurrent(hMyDC, hMyContext);
// this is essential, as in Windows the addresses of extensions
// may depend on the active context, so you must reinitialise
// extension function pointers!
reinitialize_extensions();
/* NOW USE OPENGL FUNCTION
// cleaning up once we're done:
wglMakeCurrent(NULL, NULL);
wglMakeCurrent(hOldDC, hOldRC);
// remember that we also need to reset extension
// function pointers to the other context
reinitialize_extensions();
Since in Window extension functions pointers depend on the context it makes sense to put them into a structure and call them through that one. This saves the whole extension reinitialisation thing. In C++ you could wrap the whole OpenGL context in a class for this.
Remember that you need to go through this setup/teardown everytime your plugin gets called through NP-API.
I have a Flash AS3 application that uses FileReference.browse() to request a SWF from the user. If the chosen SWF is AS3, I'm good to go. However, if it's AS2, I need to load it into an AS2 wrapper first (so my app can alter it). All of these files (including my app and wrapper) are intended to exist locally on the user's machine, but the file they select can exist in any directory. So to be clear: Main application (AS3) -> Wrapper (AS2) -> User's file (AS2)
I know how to get the uploaded file's ActionScript version from the Loader's loaderInfo.actionScriptVersion variable, and that's working correctly. My issue is how to pass the file from the AS3 application to the AS2 wrapper so it can load it.
My first thought was to dump the ByteArray from the FileReference's load() function into a SharedObject "cookie". This method seemed pretty bad from a user-experience point of view, but it seemed most likely to work. However, I've been unable to find any method within AS2 to load the ByteArray as a movie (in fact, AS2 doesn't even seem to have a ByteArray class). So the first potential solution to my problem would be if anyone knew of a method for loading a movie from a ByteArray in AS2.
My second thought was to pass the uploaded file's path to my wrapper via the already-setup LocalConnection bridge, and then just have it load the file from that. However, I can't find any way to get the file's path, and my Googling suggests the security model intentionally prevents it. Not to mention, I'm not sure I can load an arbitrary file from the user's machine.
My "hands up in the air; I give up" solution was to just create separate buttons for loading AS3 and AS2 files (leaving it up to the users to guess which it is!) and have the AS2 button actually within the AS2 wrapper. However, it looks like AS2 doesn't have a file browsing uploading API, and the PHP-hybrid solutions I've found aren't an option (because this is meant to be run locally).
So, I would be eternally grateful if anyone could point me in the right direction for solving any of these three roadblocks. Alternative workarounds are of course welcome.
(Edit)
Ok, I found the documentation for AS2's version of the FileReference class. It supports the same file-browsing capability, but does not support directly loading the selected file into the SWF.
However, the security sandbox doesn't seem as strict for local files as I expected, and it looks like I can load any SWF on the user's machine once I have a path to it. So I should be able use JavaScript and an HTML form with a file input to get and pass the file path to my application. It's not ideal having to do all of this from within a web browser, but it should work. If it turns out satisfactorily I'll submit it as an answer.
(Edit 2)
Scratch the HTML-form idea. Looks like the path is hidden from JavaScript for the same reasons Flash hides it. The only option I can think of now is to have the user copy and paste the path to the file...
After reading over your post, you may be able to retry one of your previous attemps with some new information. Actionscript 2 DOES have a method for looking up files from a browser, same as AS3 does. AS2 also has a FileReference class. Check out the documentation here:
http://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html?content=00001040.html
Also, here is a tutorial:
http://markshu.ca/imm/flash/tutorial/fileReference.html
Well, all of my other leads have dried up, so I'm submitting the two answers that will actually work, although neither is ideal:
A) Use Adobe AIR, which will give more access to the filesystem (such as for getting path info) at the cost of requiring the separate AIR runtime to be installed.
B) Have the user enter the path to the file themselves (cumbersome for the user)
I have some fairly large movieclips in the library which need to be dynamically loaded at runtime. I don't want to export them all in frame 1, because that would slow down initial loading of the movie.
I tried putting an instance of each of these clips later in the timeline where they wouldn't normally be encountered. When I then tried to load one from the library dynamically, I was able to successfully get an instance of the movieclip, but its currentFrame property was 0 and I couldn't see anything on the stage. As soon as I enabled "Export in frame 1", it worked properly.
Does this old trick of putting an instance on the timeline somewhere no longer work in AS3?
I have had similar issues with large library assets and to solve my issue I would always just put the assets into separate swf's and load the external swf file when I needed it.
Check out the Loader class 'content' property - http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/display/Loader.html#content
The only downfall to this is managing the assets in separate files.
I hope this helps.