I manually deleted most of the core classes to get it to compile.
I’m now getting an error which I don’t know if it’s valid or a bug in Falcon:
public function findKeyStrings(for:String):String{return null;}
public function translateKeyString(for:String):String{return
null;}
When trying to compile a class which contains code like this, I get:
ERROR
/Users/harbs/Desktop/InDesign10.2/src/com/adobe/indesign/Application.as[66:33]:
'for' is not allowed here
Is “for” really not allowed as the name of a parameter, or i it a bug that the
compiler thinks it’s a for loop?
Harbs
On May 1, 2016, at 3:50 PM, Harbs <harbs.li...@gmail.com> wrote:
> Here’s my stab at producing ActionScript files from the OMV files:
> https://github.com/unhurdle/omv2as
>
> The output is actually pretty good. I get error-free output on InDesign files
> with the exception of File types because I don’t yet have the core types
> linked. Photoshop output is not as good, for the most part because the OMV
> files types are not all true types.
>
> I do have a question though (before I even got to the point where I’m trying
> to use this to cross-compile code): When I run the base classes through the
> app, I get a bunch of classes which do not compile into a SWC very well. At
> least part of the problem is due to the fact that they confluct with core
> classes, and I’m not sure how to best handle this. Here’s a link of the as
> code: https://www.dropbox.com/s/pziyrqj7k1ob9p7/ExtendScript.zip?dl=0
>
> I’m not sure how to best handle this. If anyone has good ideas, please let me
> know.
>
> On Apr 25, 2016, at 9:28 PM, Harbs <harbs.li...@gmail.com> wrote:
>
>> I was guessing that the release would probably work. I am concerned about
>> debugging though.
>>
>> I will probably try this suggestion next week and see how far I can get
>> without further help. Chances are I’ll be back here before I’m successful
>> though… ;-)
>>
>> Thanks!
>> Harbs
>>
>> On Apr 25, 2016, at 6:27 PM, Alex Harui <aha...@adobe.com> wrote:
>>
>>>
>>>
>>> On 4/25/16, 8:16 AM, "Josh Tynjala" <joshtynj...@gmail.com> wrote:
>>>
>>>> In the bin/js-release directory, all of the generated JavaScript is
>>>> concatenated into a single file, so it no longer uses goog.require(). That
>>>> should work in environments that cannot load multiple scripts.
>>>
>>> I was about to suggest that as well. By default, the single-file output
>>> is minified so is hard to debug. You can add
>>> -js-compiler-option="--compilation_level WHITESPACE_ONLY"
>>>
>>> to the cross-compile and I think you'll still get a single file without
>>> goog.require but it will be debuggable.
>>>
>>> These options are handled by the compiler code in a Publisher.
>>> MXMLFlexJSPublisher has this default behavior. You can subclass it and
>>> create a different js-output-type get it to spit a single-file to the
>>> js-debug and a minified single-file to js-release. It will take a long
>>> time, though, as gathering in a single file is done by the Google Closure
>>> Compiler. But you don't to know much about compilers to make a custom
>>> Publisher. Everything is compiled at that point and you are basically
>>> dealing with files and configs for GCC.
>>>
>>> A harder task is to make the goog.require replaceable with some other
>>> pattern.
>>>
>>> -Alex
>>>
>>
>
