I get the same error for other reserved words:
in,
include,
with,
etc…
On May 1, 2016, at 10:28 PM, Harbs <harbs.li...@gmail.com> wrote:
> 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
>>>>
>>>
>>
>
