The other I was working on a Form container. Where in I have few form items and a default button for submit. I was also using validators for validating the fields.
The validators are bound to the input fields, so that the 'errorString' is automatically populated for each input field. I do have submitHandler() to be triggered when the button is clicked. The order of event execution is not as desired by me. First the custom handler is triggered, next the event in the validators are triggered, which is vice-versa I wanted.
Setting styles to combobox is not just as simple as assigning a 'styleName' property.
The style doesn't apply that easily to the 'prompt' text. By default the font weight is bold and it screws up if the font specified in the styles doesn't have a bold face.
Ideally, it can be like this:
ComboBox {
cornerRadius: 0;
fillAlphas: 1, 1, 1, 1;
fillColors: #ffffff, #ffffff, #ffffff, #eeeeee;
font-family: Avangmb;
font-size: 11;
dropdownStyleName: comboBoxDropdownStyles;
}
Flex again proved to be a strange/weird technology for its instable behaviour.
Never try to override the updateDisplayList() of Application container.
When you override this method, the percentWidth/percentHeight properties doesn't work properly. I was trying to use the graphics object for some background and this enforces the percentWidth/percentHeight not to work properly.
There are two case scenarios:
1) When you don't call the super()
This is just an addition to the already many existing tips on the web. These are few tips that helped me get resolved some of ASDoc errors.
1) CSS – All the paths to images/swf/external assets should be resolved to absolute. Relative paths are recognised by the asdoc/compc tools. 2) build.xml spaces – Sometimes the spaces in the file paths are not resolved; enclose them in quotes. 3) external-library-path – To give you understanding, whatever libraries referenced here are excluded from compiling into swf/asdoc/swc. 4) When creating a library SWC ensure to mention source-path argument, all the files you are referencing should be in the source path. Else the external assets are recognised by the compc.
Ant has become my favourite tool again after started using it in flex. I remember using while I was working on java stuff. Now I start to compile my flex apps and libraries with Ant, though I use Flex builder. I just ignore the flex builder problems/errors and look up for the Ant tasks console. Because,flex builder can ignore few errors/warnings out of the project scope. Compiling with Ant/command-line is stricter and helps your code keep clean. Here I am going to describe primarily about how to generate AS docs for a flex project, it can be a library project as well. Though, I focus on the Ant build tool, pretty much the commands can be used on the command-line compiler also.
The <exec> sets the asdoc.exe file to run AS doc engine from the flex builder directory. This token should have been initialized in the build.properties file. Look into the build.properties file, if not it should be like this:
# points to your asdoc.exe for ASDoc creation later
asdoc.exe =${FLEX_HOME}/bin/asdoc.exe
<argline='-source-path ${SRC_DIR}'/> - Set the source-path with src directory of your project
<argline='-external-library-path ${LIBS_DIR}'/> - This is where you set all your external libraries, which are compiled into SWC. AS Docs are not generated for these libraries.
<argline='-doc-classes MyProjectClasses'/> -(There’s also an alternative command to achieve this.) This line implies which classes should you generate AS doc for. This is the trickier bit and this is how Adobe compiles the framework classes. MyProjectClasses.as file is a dummy class that stores the references for the classes you want to generate. It can be something like this:
/**
* It is a good practice to maintain this class at the root of src directory.
* MyProjectClasses.as
*
*/
package
{
/**
*@private
*/
internalclass IBFrameworkClasses
{
import com.classA; classA;
import com.classB; classB;
import com.classC; classC;
import com.classD; classD;
}
}
Specify, all of your classes you want to document here. This seems to be frightening task, but I suggest this approach as it is a onetime task and really helps you maintain all your classes.
Ok, you are not comfortable!! Take this approach...
<arg line='-doc-sources ${SRC_DIR}' /> - This command is simple and straight forward, it documents all the classes in the src directory. I know that is what you want!!! In this approach, ensure that all the class libraries are supplies in SWC format, else you would run into creating documentation for all n number of classes.
Next few commands should be pretty straight forward, labelling the documentation and storing the AS docs in the DOC_DIR.