Value for latest ExternalPlayer in PublishSettings.xml

[benl13565393]

I am writing a processing tool in JSFL. This script will open an FLA file. However one issue I have encountered is the dreaded

[WARNING] The target version of Adobe AIR SDK "AdobeAIR23_0" is not available. The target will be set to the closest available version."

It does not appear that I have a way through JSFL to dismiss this. So my work around plan is to first convert the file to XFL and then modify the value.

However, that being said, is there either a way to discover what the latest version is or a string which represents the latest version?

I want this tool to be automated.

Thank!

[JoãoCésar]

Hi.

What I think you can do is to check the installed players (fl.installedPlayers), compare to the current player (document.getPlayerVersion()), and then set the document to use the closest player available (document.setPlayerVersion()).

[benl13565393]

Thanks for the info. fl.installedPlayers certainly works towards getting the latest version, however the dilemma is getting the document's version. The problem is getting this value relies on opening the document. And opening the document will cause that warning dialog to popup. My goal is to also avoid that dialog, since I want the tool to be animated.

I found there is a method to call which is named fl.exportPublishProfileString. But even doing this call will cause the warning dialog to show up. It would seem that even this call uses the same underlying or similar enough code path as opening the document.

It would have been really slick if they had a means to detect and bypass those dialogs via JSFL.

[JoãoCésar]

What exactly you need to do after opening the document?

I'm asking because it's possible, for example, to copy items from a FLA without opening it. Maybe it's possible to do what you want silently.

[benl13565393]

Just out of curiosity, how do you copy items from an FLA without opening? Sorry if it seems naive. I just started using JSFL this week, so I'm getting used to the SDK.

What I really want to do is publish it or call testMovie, which requires me to have an open document.

This is to automate processing the file to extract assets we need. Our current pipeline (for a game) is that someone manually runs the file. I want to be able to automate this process as much as possible. I have this pretty much working, however there are some issues:

-Some of our FLA files are older, so they post the warning dialog related to the AIR version

-Compiler errors (we use Actionscript to extract what we need)

-Dialog about dismissing all or continuing when something bad is in the file and flash isn't happy about the construction

I believe I know how to get around the compiler issue, but both dialogs will pose a problem in automation.

Or I suppose is there a away to suppress the dialogs at all or auto accept?

[JoãoCésar]

Please refer to this topic to see how to copy items from a FLA: Scripting the import of a moviefile (for animation-reference) .

I think you're gonna have to make use of some third party application to help you suppress this warning, like  or Mouse Recorder - Macro Recorder - Windows Automation or https://autohotkey.com/ . You can create a script that dismiss the warning and then call it with JSFL.

Furthermore, try to contact Adobe support or request this feature at:  Adobe Animate CC Feature Request/Bug Report Form .

[benl13565393 · Accepted solution]

Sigh, okay, so as an FYI, copying items (fl.copyLibraryItem) will suffer the same warning. It seems to me that the mechanism for Animate to open an FLA for any reason uses the same code path, which essentially will encounter the warning regarding not using the latest Adobe AIR version.

I actually worked around this warning in a slightly convoluted way, but it works. I essentially:

-Traverse all the installed players and find the highest Air version

-Create an XFL via bash script (I execute this from JSFL)

-Load PublishSettings.xml

-Modify and save

-Load the XFL

I will eventually save it as an FLA.

I'll have to see if I can work through the other scenarios.

I'll contact Adobe Feature Request/Bug Report. Unfortunately I don't have tremendous faith that they will want to address this, but one never knows.

Thanks again for your suggestions.

[benl13565393]

Not that I wanted to tag myself as being correct, but I am doing this because right now, in regards to answering the original question, my steps above are what I found to be the most effective, although convoluted, way to fix the issue.

The solution seems to be this way because, unfortunately, anytime you use JSFL tries to access any information from a FLA/XFL, whether it be actually opening the file or trying to access an item within the file (eg. fl.openDocument or fl.copyLibraryItem), it would appear an Animate "open file" mechanism will be called, which includes reporting any warning/error dialogs. So while the documentation to fl.copyLibraryItem states: " silently copies a library item from a document without exposing the item in the Flash Pro user interface", reality proves it to be otherwise as I see the WARNING dialog.  The key part of the statement being "without exposing the item to the Flash Pro user interface", but what (after experimenting with it) I believe this means is it doesn't require usage of the Open dialog as opposed to it showing any other dialog.

Due to this issue, the only way to "correct" the WARNING for the target air in an automated tool is to do it in the XFL. And since there is a dependency with opening the file through Animate, it requires the convoluted step of unzipping (I use tar) the FLA to get the XFL using an external script.

Effectively, it comes to a line like this

tar xvf "$fla_file" -C "$xfl_name"

In either case the steps I described, if followed will fix the issue.

Perhaps someone knows of a more elegant way to handle this?