SharedObject created in AS2 results in RangeError "The supplied index is out of bounds" on call to getLocal.

Question

To ensure forward compatibility, I want the old AS2 Shared Objects to work in the new, AS3 version of my application (Publishing in Flash Player 11.1). For some reason, this is not the case.

The AS3 code is simple:

var so:SharedObject = SharedObject.getLocal("ExistingAS2SharedObject", "/");

Shared Objects created in AS3 work perfectly fine in this scenario, but they break when they were originally created in AS2, causing the RangeError "The supplied index is out of bounds" on the line of code above. I do not have access to AS2 code (I use CC), but it saves and loads fine by itself, as well, so there should be no other problems.

I made sure to set default encoding to AMF3, although I believe that is redundant. Are there known issues with AS3 opening AS3 shared objects? Do I need to take a different approach? Thoughts?

Zanzlanz · Accepted Answer

i don't understand your last message. here's what i used to test in as2 and as3:

var a:Array = ['a','b','c'];

trace('init: '+a);

var so:SharedObject = SharedObject.getLocal('test_so1','/');

if(!so.data.testvar && !so.data.a){

so.data.testvar = 'hi';

so.data.a = a;

trace('save: '+so.data.a);

so.flush();

} else {

trace(so.data.testvar);

trace(so.data.a[1]);

}

Well I worked on this bug for a couple more weeks. I'm one hundred percent convinced it's a problem with Flash. Either way, here is the solution that I believe fixes the issue:

- Use AMF0 encoding. If you must use AMF3, set the "Local playback security" to "Allow local files only". Running the SWF in the browser will override this, so the issue will still occur, however the issue will no longer happen in standalone.

- Set the "Local playback security" to "Allow network only". It will not work otherwise.

Some other things that affect the bug include:

- If the AS2-created shared object was accessed by AS3 at any point, the bug will no longer occur. I believe this is because it is converted to AMF3. This is likely to happen if you test under "Allow local files only", for example.

- The bug may no longer be reproducible if Flash Player is using a lot of RAM. For example, I had Flash Player using 1.4 Gb of RAM, and the bug seemed to have stopped misbehaving, making it difficult for me to debug.

- The behavior of the bug may change whether or not the SWF is running through the debugger or standalone. I didn't test this enough to confirm though.
- Putting a try/catch around the code does not stop the shared object from being destroyed. Additionally, the code will return if a different shared object tries to access it too. Everything behaves as expected if the bug is not occurring in the first place.

Some things that do not affect the bug include:

- Other code and library items loaded in the app don't affect the issue (assuming it isn't meant to interfere with the code of course). The bug also happens in classes, and SWC files.

- Flash Player version and IDE version have no affect on the bug, so it seems.

I hope this helps someone else in the future! And I hope that I never had to run into this bug again, haha.

kglad · Answer

i don't see that problem.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded