Classes and Subclassing
Classes have a few quirks which confused me while learning them for some time, but overall are much like classes from other languages, so lets start with a simple class definition, the entire contents of a file named cControlHTMLTextArea.as.
For anyone wondering, this class fixes a glitch in the TextArea component that ships with Flash CS4 using ActionScript 3 - which prevents the TextArea.styleSheet property from being set. I'm using this as an example primarily because that was a tricky solution to determine, since I mistakingly assumed a 3 year old language/SDK would have the glitches worked out. Taking it apart piece by piece we have:
This line defines the package, another quirk to mention, Adobe forces you to a specific naming convention by making this equal to the path to your .as file relative to the parent .fla file. This is case sensitive on some platforms (even Windows).
This line imports the TextArea component we subclass below from the fl.controls package shipped with Flash.
Define the class, and make it an extension of the base class (referred to as super in ActionScript 3). Another quirk/forced naming convention to note here, your filename must be the name of this class (you only get 1 per .as file) plus the .as, this is case-sensitive. So in our example we must name the .as file "cControlHTMLTextArea.as" within the directory "./code/" from the root .fla file (which would be located at "./example.fla" - for example).
Nothing to abnormal compared with most languages here, the constructor is the same name as the class name, case-sensitive of course, and if you notice when comparing to the function definition below, the constructor has no return type.
On the first line of this snippet we call the constructor of the base class (TextArea) - this is only needed when your subclassing another class (using the extends keyword), the second line closes the constructor block.
Here we tell the Flash Player we want to override the function fl.controls.TextArea.drawTextFormat with our custom one - in this case it is done to fix the aforementioned glitch whereby the native TextArea does not support it's own styleSheet property (at least not if you attempt to render it).
This line checks if a styleSheet property has been set for the component's textField property and if not calls the native drawTextFormat function.
If the TextArea.textField.styleSheet property has been set we implement our fix, either way we end our function, class, and package in that order with the last 3 lines.
- Code:
package code {
import fl.controls.TextArea;
public class cControlHTMLTextArea extends TextArea {
public function cControlHTMLTextArea() {
super();
}
override protected function drawTextFormat():void {
if(!this.textField.styleSheet) super.drawTextFormat();
else {
setEmbedFont();
if(_html) textField.htmlText = _savedHTML;
}
}
}
}
For anyone wondering, this class fixes a glitch in the TextArea component that ships with Flash CS4 using ActionScript 3 - which prevents the TextArea.styleSheet property from being set. I'm using this as an example primarily because that was a tricky solution to determine, since I mistakingly assumed a 3 year old language/SDK would have the glitches worked out. Taking it apart piece by piece we have:
This line defines the package, another quirk to mention, Adobe forces you to a specific naming convention by making this equal to the path to your .as file relative to the parent .fla file. This is case sensitive on some platforms (even Windows).
This line imports the TextArea component we subclass below from the fl.controls package shipped with Flash.
Define the class, and make it an extension of the base class (referred to as super in ActionScript 3). Another quirk/forced naming convention to note here, your filename must be the name of this class (you only get 1 per .as file) plus the .as, this is case-sensitive. So in our example we must name the .as file "cControlHTMLTextArea.as" within the directory "./code/" from the root .fla file (which would be located at "./example.fla" - for example).
Nothing to abnormal compared with most languages here, the constructor is the same name as the class name, case-sensitive of course, and if you notice when comparing to the function definition below, the constructor has no return type.
On the first line of this snippet we call the constructor of the base class (TextArea) - this is only needed when your subclassing another class (using the extends keyword), the second line closes the constructor block.
Here we tell the Flash Player we want to override the function fl.controls.TextArea.drawTextFormat with our custom one - in this case it is done to fix the aforementioned glitch whereby the native TextArea does not support it's own styleSheet property (at least not if you attempt to render it).
This line checks if a styleSheet property has been set for the component's textField property and if not calls the native drawTextFormat function.
If the TextArea.textField.styleSheet property has been set we implement our fix, either way we end our function, class, and package in that order with the last 3 lines.
