.. additional info:

I've tried installing the 32 bit windows version of FlashBuilder 4.7 (on a different system, to rule

out incidental system problems) as well, but the problems are the same with that version.

Digging a bit further, it appears that at least the gradient glow and the gradient bevel

bitmap filters are disfunctioning when build with FlashBuilder 4.7.

Upgrade from Air3.4 to Air 3.5 did not yield a change.

Building with air 3.5 using FlashBuilder 4.6 shows proper results. (and FlashPro cs5.5, cs6.0).

So I guess the problem is in the compiler of FlashBuilder 4.7.

To FlashBuilder Team of Adobe: Is this problem ackknowledged?
If no, please let me know what I should do.
If yes, has a bugfix been scheduled? For when?

Thanks in advance

Sure, I guess to this post I can only attach an image or video, so here's a link:

http://www.kidscalculate.com/FB47_FilterTest.zip

The nice thing about this problem is its reproducability: the problem is always there,

wether the build targets mobile as3 for ios, flashplayer or air, 3.4 or 3.5.

The TestButton.fla (created with Flash CS6.0) has created the .swc next to it.
It contains the filtered graphics. (ignore SwcBuild.fla - just a copy).

The FB4_7 project targets flashplayer 11.5. It imports said swc in its project settings,

and its 5 line .as code simply puts the MovieClip instance on stage.

Thanks in advance

Thanks Sinious,

I tried to file the bug at the link that you provided, but it does not accept a post without

specifying product details from drop down lists.

However, there's only a handful of products in the list, and FlashBuilder 4.7 is not among them.

Any advice on that?

Thanks in advance

I followed your suggestion, and filed it as FlashPlayer 11.5 bug w. workaround. In retrospect, I regret the last, as the bug

was positioned as only as "priority 3rd high" - presumably because of the existence of the theoretical workaround.

For me, the work around is not realistic, because I use these filters at hundreds of places. Finding, then removing them,

and adding them programmatically would be an adminstrative nightmare, and I'd loose the WYSIWYG advantage of Flash Pro completely.
Summarized - until fixed, I cannot use FB4.7. to continue the development of my app in.

Anyway, I'll keep my fingers crossed that the "FlashPlayer bug" will make it to the FlasBuilder team (in some coorperations I've worked,
there'd be high chances such "ill-filled in form" would be ignored) - and that they'll give it high priority, which I think it deserves.

Thank you for your prompt help.

I see your point. The bug ID is 3499140.

By the way, how does the voting process work?

Is someone from the flashbuilder team appointed the task of counting votes

on forum pages like this? Or is there a specific webpage where people can vote
which bugs should be fixed first?

I see, thanks.

Mmm.. looks like bureaucracy prevents the bug to be considered (see bugbase link above).
Zhe Wang, a Lead Manager of Adobe seems to have rejected the bug-report, because
"it should be filed as an FB bug instead of a FlashPlayer Bug".

Apparently, there's no way to report a bug to the FB team. I can't hide that its

very frustrating and annoying.

:-)  Thanks Nabren!  I posted the bug on that location as well.

Well, I spent my effort to file the bug - in spite of the lacking of a "proper place" to file it.

You can add your vote as well:

https://bugbase.adobe.com/index.cfm?event=bug&id=3499140

A customer friendly Adobe affiliate, called Sinious on these forums, has been willing to look

into it and has confirmed that it looks like a FB 4.7 compiler bug.

Yet as you can see from the link above, it looks like the bug report is not taken seriously - the

responsible adobe manager Zhe Wang is wining that it should be posted on a forum, and
to me it looks like nothing shows that any action will be taken.

Apart from programmatic filtering, you could redesign the filters of your artwork.
From my short research, it looked like the main problems were caused by use of the filters

that use color-gradients. (gradient bevel, gradient glow).

You could replace them by non-gradient bevel and non-gradient glow filters, and thus retain the

WYSIWYG advantage.
(you can mimic the behaviour of a multi-color gradient glow by stacking multiple

single color gradient glows, for instance).

For me, it would still mean that switching to FB4.7 would cost way too much work.
I'm still waiting for an update with the fix.

Hi DachFlach,

Thank you for hinting this other potential workaround. I'll see if I can reproduce.

This workaround would mean that each of the exported main classes in flash pro would need to be dissected hard-coded into sub-classes in the code, at least for each sub-class (movieclip) that uses such a filter - hard code an extended class for these classes, and then rebuild an analogon of the original main class at runtime that uses these extended classes to in a similar hierarchical buildup.

That is, even if the workaround would work, it'd still cost tons of work for me

to convert everything - WYSIWYG objects in flash pro (complete menus, sceneries, etc)

generally consist of loads of hierarchy of sub-objects, and I've used these filters on hundreds of places.

Apart from that, because of the hard-coded solutions, the result is badly maintainable: Editing (changing hierarchical structure)

of MovieClip internals in flash pro may make them out of sync with the hard-coded solutions.

Anyway, thanks.

Strange - from flashdevelop, btnPink seems accessible, while it does not seem so from FB47..
Could you post the .fla as well?
(also, such that I can verify that the button looks the same in flash pro)

Thanks in advance