Hi Barry, IMO, I've seen all of these questions asked before, but I don't know if it would be "frequently". For #1, #2 and #3, most folks use an IDE which tends to prevent getting caught like this. IIRC, you were trying to not use an IDE?
For #4, there are a variety of application patterns like MVC that help you share things. Folks use Singletons, or Locators, or just global variables. Each has their advantages and disadvantages. -Alex On 2/20/14 1:23 PM, "Barry Gold" <barrydg...@ca.rr.com> wrote: >Has anybody considered a FAQ of mistakes made by beginners? Or are >people's mistakes too idiosyncratic to bother? > >Here's my contribution: > >1. The default scope for a class you create is "internal": it can be >seen by other classes in the package, but not outside the package. To >make it visible throughout your project, declare it: > public class className {...} > >Figuring this one out was especially hard because the following doesn't >generate an error message: > >import packageName.className; >(where className is actually internal to its package) > >Instead, the compiler flags every use of className inside your code, >leaving you (or at least me) scratching your head... "But I imported >it..." > >2. Functions need a return type, even if they don't return a value: > public function name(...): void > >3. Don't forget to use "var" when declaring the local variables in a >function. The error message from this one is a little mystifying. > >4. Accessing mxml components: In examples in published books, mxml >components are used as if they were global variables. For example, ><s:Group id="mainmenutop" visible="false" left="0" top="0" > width="100%" height="100%"> >... ></s:Group> >The example simply refers to "mainmenutop" as if it were a global >variable. It isn't. It's an instance variable in the Application >object. So if you want to refer to these in other classes, you either >need to provide access functions in the Application object, or pass them >to the object that will use them. > >In the above example, I have a "GameSequence" class that will show or >hide the various components that make up the top-level mxml file, as the >user goes from one part of the game to another. So I will either need >to provide accessor functions: > public function getMainmenutop():Group { return mainmenutop; } >or pass them to the sequencer: > sequencer:GameSequence = new GameSequence(); > sequencer.addPage("mainmenu", mainmenutop); > >Btw, I'm soliciting comments on which of the above is less ugly from an >OO point of view, and or other suggestions for structuring this code. >