posted ago on twitter


ASSetPropFlags – The correct flag table

by John Grden :: Director Flash Platform BLITZ

Well, after beating on ASSetPropFlags for sometime, I finally came to the conclusion that the flag table that everyone has been referencing is wrong – it’s the same one on every page I’ve found, but in my simple tests and real application tests, the original list is completely wrong and inverted for the most part.

Old Table:
Old ASSetPropFlags table

Correct Table:
New ASSetPropFlags table

At first blush, you might think I’ve just reversed the table and maybe even read it wrong, but compare value/row 3 – that’s not inverted, that’s just wrong according to the code test below. And if you compare the bitflag in #4, it doesn’t follow the settings in adjacent row at all (100 != no, yes, yes) – and it’s completely wrong on top of that. Anyone else notice this at all?

A BIG thanks to Werner Sharp over at Macromedia for confirming this new table:

“Hi John,
Your new table is right. It is three bits.

0×1 is “don’t enumerate��?
0×2 is “don’t delete��?
0×4 is “read only��?

That matches up with your table.
I’m happy to help.


Usually, when you see someone talking about using ASSetPropFlags, they nearly always have:

ASSetPropFlags(obj, null, 6);

They use flag 6. That’s because they’ve read one of those 2 tutorials ;) Yes, 6 makes the properties visible, but it also locks them down, and many people don’t realize that they’re not able to write to these properties now, and therefore, have now potentially introduced a bug into their application.

I have used, and tested using 1 & 0 – they do just what the new chart indicates and don’t introduce any issues:

ASSetPropFlags(obj, null, 0);

The 4th argument:

There has also been a bug reported with running ASSetPropFlags on _global, but I believe we’ve figured out what the issue is with that. There is yet a 4th argument that you can pass to bring your properties back to life. The 4th argument is a clearBit parameter that accepts the same bitFlag as the 3rd (0-7). It seems that if you wish to enable a property to be updated or deleted, go ahead and pass 2 and test.

IE: _global.ASSetPropFlags(_global, null, 0, 2);

Now, this brings me to the explanation of what these 3rd and 4th arguments are: They’re change arguments – they’re used to change the bitFlags of the current propFlags using XOR operations. Hence why sending in a 4th argument can ensure the desired results. If you’re just exposing an objects properties for itteration, you’ll want to set those values back. It seems that it’s not just a matter of sending in “1″ (writeable, deleteable, visible : 111) – most people assume that these are applied to the properties of the object. They’re not: they’re used for changing the current flags. Now, if it’s the FIRST time you’re running ASSetPropFlags on an object, yeah, you’ll get the results you’d expect. However, on the next pass, you won’t.

Consider this scenario below. You pass in _global.ASSetPropFlags(_globa, null, 7) the first time, then later you pass in _global.ASSetPropFlags(_globa, null, 1), expecting writeable/deletable/visible, but what you really get is notWritable/notDeleteable/visible:

<br />
1 = make a change<br />
0 = don't make a change</p>
    <p>001 (currentBit nw/nd/nv)<br />
110 (setBit - 3rd argument, aka "0" in the chart w/d/v)<br />
-----<br />
111 (newBit w/d/nv does NOT give you w/d/v)<br />

Now, Roger had posted a calculation of

(oldBit &#038; ~clearBit) | setBit

that got me thinking and testing, but it didn’t seem to pan out with the tests I’ve run, but his worded explanation DOES explain the calculation for the most part:

Roger’s explanation:

Any bits that are SET in the last parameter are CLEARED in the internal prop flag,
then any bits that are SET in the third parameter are CLEARED in the internal prop flag.

This type of logic uses XOR, instead of bitwise NOT (~):

<br />
(oldBit ^ clearBit) ^ setBit<br />

On all bitFlag settings, this formula works out with the tests – except the 2 flag. For some reason, it doesn’t always calc out to what it ought to, which is why using 2 usually works for most situations.

The app below is the engine I put together to test these situations out. You set the StartingBit flag and hit “Run”. The app creates an object per itteration and applies “7″ to it first, THEN changes it to the bitflag sent in by the loop. It loops through all 8, and for each, it passes all 8 4th arguments. If you use the fomula above, you can see how it all works and how #2 just seems to be living life on the edge.

NOTE: in the first 8 rows, in the 8th row, you’ll see the exact example of what I spelled out above with sending _global.ASSetPropFlags(obj, null, 7), then using _global.ASSetPropFlags(obj, null, 0, 0). It ends up being 001 (nw/nd/nv), but if I hadn’t passed in 0 as the 4th argument, it’d have been 110 (w/d/nv). If I wanted it set back to the true “0″ (110), I’d have had to passed “7″ as the 4th argument (first row in dg):

[kml_flashembed movie="wp-content/demos/assetpropflags_demo.swf" height="775" width="600" /]


P T Withington July 6, 2006 at 3:57 pm

This post looks like a re-hash of the original post I commented on at [ptalk](, which shows that Roger’s formula `(oldBit & ~clearBit) | setBit` is right.

John July 10, 2006 at 10:44 am

I was pointing out that his calculation was wrong but his verbage describing it was correct. Plus, I didn’t feel that the other article explained it well enough. ;)

Roger November 12, 2009 at 4:26 pm

Your formula is wrong .. if using xors worked, then setting twice like this


would set and then reset the flag. It doesn’t

My original formula was correct.

Also note that the bit values meanings are:

bit 0 = 0 allow enumeration, 1 do not enumerate
bit 1 = 0 allow deletion, 1 do not delete
bit 2 = 0 allow writing, 1 do not write