We've recently made changes to allow keywords in more places. I
personally don't enjoy doing that work, but maybe Josh will.
-Alex
On 5/1/16, 12:34 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>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[6
>>6: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
>>>>>
>>>>
>>>
>>
>
