Skip navigation
Currently Being Moderated

Bugs and Annoyances in Toolkit for CreateJS

Aug 28, 2013 10:30 PM

After the third project exported to HTML5, I have a few bugs and notes.  I have successfully made it work, exporting Flash apps to HTML5, twice. 


It is now almost September, and this '.name' bug is still present.  Pardon my 'impatience', but actually I only came here to report this bug, and seeing it has been around for at least half a year is demoralizing.


// Work-around for NAMING bug (four letter words and debug assertions removed for clarity)

// Call on a DisplayObject (or call on a collection thereof) that are to be found by name.


    function WhoAmI(dobj)


        if( != null )


        var property;

        var curr;

        for (property in dobj.parent)


            curr = dobj.parent[property];

            if( curr == dobj )


       = property;






Of course, completely forget about iterating for text fields and looking for matching labels in an XML file to do text substitutions with; my preferred method for internationalization.  Also forget recursively 'finding' children in a MovieClip by their name, something I do quite a lot of, because it makes it much easier to 'skin' projects, later on (or survive the waves of art 'changes'). Because every programmer should miserably slog line by line through ever-changing labels and text fields and text, mirroring arbitrary changes in artwork in their code.

I may as well complain to the cats about how Toolkit for CreateJS also throws away empty 'placeholder' MovieClips, which was astoundingly annoying.  How 'tidy'. 


The work-around for this was to put 'something' in the placeholders, and then scrupulously remove the 'something' in the code... and of course, mirror this in the FLASH code, because afterwards the container has 'garbage' in it that didn't belong there, too.


while( 0 != mcplaceholder.getNumChildren() )





Another little annoyance is that every single bitmap in the Flash project gets exported into the load list.  This can be 'fixed' by finding unused art in the .fla file and cleaning it up.  If you have some 'extra' bitmaps in your project providing guides or just laying around after a 'wonderful new idea' about chaning something for the 50th time, your javascript export is probably a lot bigger than it needs to be.  (Also, run some kinda png optimizer on the output before you deploy it: the png files flash exports are bloated pigs.)


Throw away what I NEED, and keep the bulkiest garbage.  Thanks!


My final note on Toolkit for CreateJS is, WHY can't it simply prompt for a .js file to insert into your 'index.html'?  It would be so easy.  Import the end user's 'applet_main.js' and spit it into the right place in the html, and, I dunno, maybe call an 'applet_main' constructor.  Perhaps and/or slurping in a user supplied 'body.html', containing an alternate version of 'body', which could have its own imports and other things.  Just replace the default <body>...</body> with what's in the 'body.html', verbatim.


Or perhaps just take that whole sinkin' 'var manifest = [...];' block and stick it in its own 'manifest.js' file that it can overwrite as much as it likes, because that's the root of the load-time and export-time misery.  HAND EDITING html over and over again, as 'updates' to the art, beyond your control happen, well that gets extremely old the very first time it is done, and absolutely miserable the hundredth time.  Especially when you're 'debugging' why an export didn't work as expected.

  • Currently Being Moderated
    Aug 30, 2013 4:59 PM   in reply to pingnak

    Adobe - Wishlist & Bug Report

    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points