2009-04-08 6 views
2

J'ai rencontré un problème en essayant de redispatch événements de souris en ActionScript 3, dont je suis un peu incrédule. Je l'ai réduit à la méthode MouseEvent.clone() apparaissant, bien, complètement cassé. Le gestionnaire d'événement suivant:ActionScript MouseEvent.clone() apparaît brisé?

private function handleMouseMove(evt : MouseEvent) : void 
    { 
     trace("mousemove", evt.stageX, evt.stageY); 
     var newEvt : MouseEvent = evt.clone() as MouseEvent; 
     trace("mousemoveclone", newEvt.stageX, newEvt.stageY); 
    } 

Résultats dans la sortie suivante, ad infinitum:

mousemove 167 206 
mousemoveclone 0 0 

Cela correspond à ce que le code que je redispatching MouseEvent à recevait, d'où mon hypothèse de la fonction clone cassé .

Ceci est directement en contradiction avec ce que la documentation liée indique devrait se produire, à moins que j'ai manqué quelque chose. Je suis à une perte complète quant à ce que j'ai fait (ou n'a pas fait) qui pourrait causer ce comportement. Est-ce que les gars AS3 ont vraiment oublié de lire leurs propres documents sur Event.clone()?

Je peux contourner ce problème en utilisant à la place des objets fonction pour mon cas d'utilisation spécifique, mais je préfère ne pas le faire. Des idées? Les membres localX et localY sont correctement clonés il semble, ce qui me fait encore plus de perte quant à ce qui se passe ici.

Répondre

3

C'est un bug connu. Vous pouvez voir le rapport de bug ici: http://bugs.adobe.com/jira/browse/FP-343

Tout le reste devrait être cloné. Vous pouvez toujours affecter manuellement stageX et stageY jusqu'à ce que le bogue soit corrigé.

+1

Je viens de perdre encore plus de respect pour Adobe pour ce bogue qui date de presque un an. Merci pour le lien. –

+0

Yah, il y a quelques bugs comme ça. Cela n'affecte pas beaucoup de gens, et la solution est simple, donc je suppose qu'ils ne dérangent pas. –

+0

Probablement plus comme "Nous ne pouvons pas déranger la réparation, et les gens vont juste contourner le problème". Œuf de poule :) –

2

Je me rends compte que ce thread est dormant depuis 7 mois, mais juste pour le mettre à jour un peu - c'est encore actif dans FP10 et Flex4. Cela arrive aussi si vous répétez l'événement. à savoir:

private function mouseListener(e:MouseEvent):void 
{ 
    dispatchEvent(e); 
} 

que dispatchEvent() appel semble être l'équivalent d'un clone(), de sorte que le stageX et stageY sont à 0

0

C'est une question assez vieux, mais il était ce qui est venu quand j'ai cherché une solution, et ce qui est ici n'est pas assez complet.

La raison pour laquelle cela n'a pas été "corrigé" est que cela fonctionne comme prévu. Les valeurs stageX et stageY sont calculées lorsque vous appelez le getter, en utilisant la cible de l'événement pour effectuer la conversion localToGlobal. Ceci est nécessaire pour que les nombres restent corrects même si l'objet cible a changé de position, d'échelle ou de rotation depuis l'envoi de l'événement.

Vos deux options si vous avez vraiment besoin d'une nouvelle répartition mouseEvent avec stageX correcte et les valeurs stageY sont:

  1. Créer une sous-classe personnalisée de MouseEvent qui l'emporte sur la stageX et getters stageY. Vous pouvez soit stocker la cible d'origine et effectuer vous-même le calcul localToGlobal, soit stocker des valeurs statiques pour stageX et stageY en utilisant les valeurs présentes lors du clonage de l'événement d'origine. Étendez Sprite et ajoutez votre répartiteur à la scène afin que le MouseEvent stock fonctionne correctement.