VerifyError: Error #1107: Die ABC-Daten sind beschädigt, versuchtes Lesen außerhalb des gültigen Bereichs.
im Zusammenhang mit TweenMax? Bzw, besser gesagt: Im Zusammenhang mit TweenLite aus dem TweenMax-ZIP? Hatte ich auch. Habe auf TweenMax v11.411 aktualisiert, und nehme statt TweenLite nun TweenNano. Die Calls zu TweenMax waren bei mir nicht betroffen; TweenLite allerdings auch in der Version 11.
Der Fehler trat bei mir nur unter Windows auf, nicht unter OS X, also Obacht!
Gegeben: Klasse A, mit Funktion
|
1 |
protected function foo():void{} |
Klasse B beerbt Klasse A, Klasse C beerbt Klasse B. In Klasse B kann ich
|
1 |
override final protected function foo():void{} |
schreiben, also "nachträglich" die Funktion auf final setzen. In Klasse C kann ich sie dann nicht mehr überschreiben - aber natürlich noch aufrufen. FYI.
Folgende Situation: Ich habe einen Context, den ich an mehrere Module hänge. Diese Module sind immer vom Typ AbstractStoryPage, aber manchmal auch vom Typ AbstractStoryLastPage. Im Context will ich nur für AbstractStoryLastPages einen Mediator mappen. Erste Experimente zeigen, dass ich nicht
|
1 |
mediatorMap.mapView( AbstractStoryLastPage, LastPageMediator ); |
aufrufen kann. Offenbar muss ich die konkrete Klasse nehmen, nicht eine Überklasse. Aber: Anders als der Methodenkopf
|
1 |
public function mapView(viewClassOrName:*, mediatorClass:Class, injectViewAs:* = null, autoCreate:Boolean = true, autoRemove:Boolean = true):void; |
nahe legt, kann ich dort nicht nur eine Klasse oder einen Namen übergeben, sondern auch eine Instanz. Und jeder Context hält die Instanz seines Views als DisplayObjectContainer contextView. Was also geht:
|
1 2 3 4 |
if( contextView is AbstractStoryLastPage ) { mediatorMap.mapView( contextView, LastPageMediator ); } |
Now you know. Verzweigungen im Context basierend auf der Überklasse des Views, aber ohne die konkreten Klassen mit reinkompilieren zu müssen.
Vermutlich weiß es jetzt jeder, aber wenn man bei WordPress die Revision eines Eintrages mit sich selbst vergleicht, explodiert alles... oder?
Weil's neulich gerade aufkam: Wenn ein SWF den Focus hat, kann man mit Tab durch zB Eingabefelder springen. Das ist gut. Was schlecht ist: Das jeweils gewählte Eingabefeld bekommt dann so einen gelben Rahmen. Der hat vermutlich denselben Grund wie die "outline" in CSS: Die Bedienbarkeit ohne Maus zu erhöhen. Er hat aber auch denselben Nachteil: Designer mögen ihn nicht 🙂
Wer ihn entfernen will (den Rahmen, nicht den Designer), kann entweder flash.display.InteractiveObject.tabEnabled auf false setzen. Das müsste man aber für jedes Eingabefeld machen. Alternativ setzt man flash.display.DisplayObjectContainer.tabChildren auf false, und zwar auf den root-Clip.
Zum Jubiläum (20ster Post und so) wieder eine Spezialausgabe: "What is the best comment in source code you have ever encountered?" auf stackoverflow.com. Ich sag nur:
|
1 |
stop(); // Hammertime! |
Großartige undokumentierte Funktion, die Kollege Menzel da entdeckt hat: MovieClip.addFrameScript()!
Man denke zum Beispiel an
|
1 2 3 4 5 6 7 8 9 10 |
public function AddClipScriptTest() { _clip = new Clip(); _clip.addFrameScript( _clip.totalFrames-1, _onComplete ); // zero based! addChild( _clip ); } private function _onComplete():void { _clip.stop(); trace( 'hooray, frame #' + _clip.currentFrame ); } |
Kein Event.ENTER_FRAME, kein nix. Was man damit alles machen kann: FLAs/SWCs komplett Code-frei halten. Eine SWF mit Logik, eine mit Design. Viele schlaue Sachen.
# The internals are not documented because they are scary.
