<?xml version="1.0" encoding="utf-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc = "http://purl.org/dc/elements/1.1/" xmlns="http://purl.org/rss/1.0/">
	<channel rdf:about="http://livedocs.adobe.com/">
	<title>LiveDocs Comments - flash - 9.0 - main - 00000068.html</title>	
		<link>http://livedocs.adobe.com/</link>
		<description>Macromedia LiveDocs - online documentation with user feedback.</description>
		<copyright>Copyright 2009, Macromedia, Inc.</copyright>
		<dc:date>2009-11-26T11:13:02</dc:date>
		<dc:language>en-us</dc:language>
		<items>
			<rdf:Seq>
				<rdf:li rdf:resource="http://livedocs.adobe.com/flash/9.0/main/00000068.html#83389" />
				<rdf:li rdf:resource="http://livedocs.adobe.com/flash/9.0/main/00000068.html#82603" />
				<rdf:li rdf:resource="http://livedocs.adobe.com/flash/9.0/main/00000068.html#82141" />
				<rdf:li rdf:resource="http://livedocs.adobe.com/flash/9.0/main/00000068.html#82044" />
				<rdf:li rdf:resource="http://livedocs.adobe.com/flash/9.0/main/00000068.html#74411" />
				<rdf:li rdf:resource="http://livedocs.adobe.com/flash/9.0/main/00000068.html#74380" />
				<rdf:li rdf:resource="http://livedocs.adobe.com/flash/9.0/main/00000068.html#71456" />
			</rdf:Seq>
		</items>
	</channel>
	
	<item rdf:about="http://livedocs.adobe.com/flash/9.0/main/00000068.html#83389">
		<title>flash/9.0/main/00000068.html</title>
		<link>http://livedocs.adobe.com/flash/9.0/main/00000068.html#83389</link>
		<description>I am trying to use inheritance by attaching external classes (classes in a *.as file), to an existing movieclip on the stage. To put it simply, I have a movieclip with just a button inside called btnOK. Using the Linkage option in the Library, I link the movieclip to my class, DialogBox.as. DIalogBox inherits from MovieClip and I can access btnOK within the class without redeclaring. Perfect. It works. Yeah!&lt;br /&gt;But now I want to derive a class from DialogBox.as so I can put all the general dialogbox features in DialogBox.as, and the specific features in SpecialDialogBox.as which inherits from DialogBox.as. If I make it so SpecialDialogBox inherits from DialogBox and link my movieclip to SpecialDialogBox, the compiler complains the the reference to btnOK in DialogBox is an undefined property. I believe I'm using inheritance correctly. If I understand this correctly, FLASH is only allowing me to reference objects created on the stage one level deep in the inheritance chain. I kind of understand, but my objective is to put all the common features of all my dialogboxes in one class and create specialized classes that reuse the commonality of the dialogbox class but adds its own special features too.&lt;br /&gt;Please help.&lt;br /&gt;Thanks,&lt;br /&gt;Vinny</description>
		<dc:creator>vinnyguido</dc:creator>
		<dc:type>0 0</dc:type>
		<dc:date>2008-04-24T15:17:09</dc:date>
	</item>
	<item rdf:about="http://livedocs.adobe.com/flash/9.0/main/00000068.html#82603">
		<title>flash/9.0/main/00000068.html</title>
		<link>http://livedocs.adobe.com/flash/9.0/main/00000068.html#82603</link>
		<description>in the Access control specifiers and inheritance example why does defining the str variable as protected return an error?&lt;br /&gt;&lt;br /&gt;I thought the protected definition gives access to all subclasses.</description>
		<dc:creator></dc:creator>
		<dc:type>0 0</dc:type>
		<dc:date>2008-04-03T05:37:45</dc:date>
	</item>
	<item rdf:about="http://livedocs.adobe.com/flash/9.0/main/00000068.html#82141">
		<title>flash/9.0/main/00000068.html</title>
		<link>http://livedocs.adobe.com/flash/9.0/main/00000068.html#82141</link>
		<description>@No screen name:&lt;br&gt;&lt;br&gt;You're right, of course, that that type of inheritance doesn't work in ActionScript 3.0. I can't offer a great reason why -- it's just a decision that was made by the designers of EcmaScript, which ActionScript 3.0 is based on.&lt;br&gt;&lt;br&gt;As far as I know there isn't any workaround to make this work, other than just casting variables (messy!).&lt;br&gt;&lt;br&gt;In any case, for your (and others') interest, here are a few articles on the subject:&lt;br&gt;http://kuwamoto.org/2007/01/22/covariant-property-types/&lt;br&gt;http://kuwamoto.org/2007/01/24/covariant-property-types-round-2/</description>
		<dc:creator>adbe_paul</dc:creator>
		<dc:type>1 0</dc:type>
		<dc:date>2008-03-20T11:53:33</dc:date>
	</item>
	<item rdf:about="http://livedocs.adobe.com/flash/9.0/main/00000068.html#82044">
		<title>flash/9.0/main/00000068.html</title>
		<link>http://livedocs.adobe.com/flash/9.0/main/00000068.html#82044</link>
		<description>I am not an OOP expert, but I believe there to be some inconsistencies with the way Adobe handles inheritance and interface implementation.&lt;br /&gt;&lt;br /&gt;When you override a method or implement an interface you are required to have the same number of parameters with the same data type as well as the same return type.  This all makes sense, but what if you wish to use a subtype as a parameter or as a return type.  Technically it is still the same data type through polymorphism, but the compiler will throw an error. &lt;br /&gt;&lt;br /&gt;If there is a work around for this, please post!&lt;br /&gt;&lt;br /&gt;Thanks.</description>
		<dc:creator></dc:creator>
		<dc:type>0 0</dc:type>
		<dc:date>2008-03-18T08:11:22</dc:date>
	</item>
	<item rdf:about="http://livedocs.adobe.com/flash/9.0/main/00000068.html#74411">
		<title>flash/9.0/main/00000068.html</title>
		<link>http://livedocs.adobe.com/flash/9.0/main/00000068.html#74411</link>
		<description>@M. Koevets:&lt;br&gt;&lt;br&gt;Thanks for pointing out the errors in the sample code.&lt;br&gt;&lt;br&gt;The only reason the AccessControl class extends MovieClip is so that it can be used as the main class of an ActionScript-only project in Flex, or the document class of a FLA in Flash (so that it can be run and tested). Otherwise, as you point out, there isn't any MovieClip-related functionality that's needed for this example.</description>
		<dc:creator>adbe_paul</dc:creator>
		<dc:type>1 0</dc:type>
		<dc:date>2007-10-03T13:07:55</dc:date>
	</item>
	<item rdf:about="http://livedocs.adobe.com/flash/9.0/main/00000068.html#74380">
		<title>flash/9.0/main/00000068.html</title>
		<link>http://livedocs.adobe.com/flash/9.0/main/00000068.html#74380</link>
		<description>Forgot to mention that, in the 'Access control specifiers and inheritance' example,  the name of the file holding the AccessContol class should of course be AccessControl.as and not ProtectedExample.as, as is suggested. &lt;br /&gt;All the examples in this section seem to have been rather hastily put together. Classes keep on extending the MovieClip class for no reason at all.</description>
		<dc:creator>M. Koevoets</dc:creator>
		<dc:type>0 0</dc:type>
		<dc:date>2007-10-03T02:43:53</dc:date>
	</item>
	<item rdf:about="http://livedocs.adobe.com/flash/9.0/main/00000068.html#71456">
		<title>flash/9.0/main/00000068.html</title>
		<link>http://livedocs.adobe.com/flash/9.0/main/00000068.html#71456</link>
		<description>There are still some unanswered questions on this page.&lt;br /&gt;Although I can simply compile the code myself and test, perhaps the page could be improved by explicitely stating the results of the following:&lt;br /&gt;&lt;br /&gt;for the example under:&lt;br /&gt;&quot;Static properties and the scope chain&quot;&lt;br /&gt;&lt;br /&gt;We know that Extender can access static var test within itself, but in the StaticExample class, can it be accessed by typing: Extender.test?  It can't, right?  You would need to type Base.test in the scope of StaticExample, correct?&lt;br /&gt;&lt;br /&gt;And then, under:&lt;br /&gt;&quot;Static properties and the scope chain&quot;&lt;br /&gt;&lt;br /&gt;We see from the example that the public var test in Extender takes precedence to the 'inherited' static var test from Base.  Well, what happens if public var test is defined in Base as well (as opposed to in Extender).  I imagine the same rule applies.&lt;br /&gt;&lt;br /&gt;This may seem nit-picky, but if you're going to try to explain the subtle aspects of static variables, you might as well go all the way and make it fool-proof.&lt;br /&gt;Otherwise, we are still going to have to go back and run code tests to confirm these cases ourselves.</description>
		<dc:creator>jpwrunyan</dc:creator>
		<dc:type>0 0</dc:type>
		<dc:date>2007-08-05T19:23:10</dc:date>
	</item>
	</rdf:RDF>

