Skip navigation
Currently Being Moderated

Error: In initializer for 'source'

Apr 5, 2013 1:23 PM

I have a strange problem.  When I try and compile the application, I get two errors, one of which is below, but they are essentially the same. 


If I edit FaqEventMapButtonSkin.mxml and update ButtonSecondaryDefault to ButtonSecondaryDefaultTEST, and change the corresponding ButtonSecondaryDefault.fxg to ButtonSecondaryDefaultTEST.fxg, everything works fine.


The compiler must be caching something.  I've looked and looked for information on this topic without any luck.  I'm not using incremental compile.  Any ideas on how to clear things out?



FaqEventMapButtonSkin.mxml(44): Error: In initializer for 'source', type com.thomson.convene.ui.assets.ButtonSecondaryDefault is not assignable to target type 'Object'.


    [compc]                     <assets:ButtonSecondaryDefault width="100%" height="100%" />

  • Currently Being Moderated
    Apr 6, 2013 9:46 PM   in reply to dev2277

    Do you have both an .mxml and an .fxg file with the same name?  That might confuse the compiler.

    Mark as:
  • Currently Being Moderated
    Apr 9, 2013 9:30 AM   in reply to dev2277

    Maybe if you post more code we can better understand what your scenario is.

    Mark as:
  • Currently Being Moderated
    Apr 9, 2013 1:24 PM   in reply to dev2277

    I don’t know the compiler well enough to know if it caches stuff or not.  The compiler source code is available in the Apache Flex repository if you want to try to look yourself.  I’ve seen some compiler code that implies there are three ways of running a compile:



    1.  incremental: when editing and saving in FB

    2.  full: when cleaning and building in FB

    3.  standalone: when running mxmlc from ant or command line


    I’m pretty sure stuff is cached between builds for #1.  It is possible that there is caching between builds in #2.  There should not be caching between builds in #3, but I would not put money on it.  When you say you are not using incremental compile, are you using #2 or #3 or both?


    What does happen in #3 (and hopefully #2) is that SWCs found in the library path are read in and parsed and all of their classes go in a lookup mechanism to be used when trying to resolve symbols from other compilation units.  Plenty of folks have been burned when there is some stale SWC in some folder of SWCs pointed to by some configuration file that is supplying a competing definition.  And that’s what makes it machine specific.

    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