• mc的"animationComplete"事件需要冒泡吗?


    作为地图上的互动元素,动画最后一帧会派发一个"animationComplete"事件,那么需要冒泡吗?项目中是冒泡的,直到遇上了今天的情况,我才觉得没有必要冒泡:

      之前项目中互动不管是trigger、singleTrigger或是server类型的都是点击后一旦checkBehavior满足条件会就doIt(),若是server采集类型的就会开始读条了,读条读完显示采集结果,然后就playAnimate()了。今天要做的这个互动,点击后,并不是立马就doIt()-->读条-->playAnimate(),而是先playAnimate(),收到"animationComplete"事件之后才开始读条。我自己写了个checkBehavior_speciel(...,method),一旦距离达到,不是让互动doIt(),而是触发作为参数传进来的method,要做什么就做什么,不一定就要doIt();问题就在,在外部监听这个互动的"animaitonComplete"事件时,监听到了两次,以至于产生多次采集,player被hold()不能移动的bug,几个小时都纠结在这个事件是不是在传递过程中被多个监听者多派发了一次,或者动画里面是不是被不懂代码的美工复制原件时可能把"disptachEvent..."这样的代码也复制到了某个小元件的某一层上。

      结果发现动画结束帧的代码里派发事件的事件类型的逗号后面,有个"true"!然后理了理作为地图最底层对象MapItem上的监听,动画作为content加载进来后被addChild到了mapitem的displayContnet上;

      在displayContent里的content有addEventListener,监听到后displayConent把这个事件实例原封不动的发了出去:dispatchEvent(event),

    mapitem里的displayConent也架了个addEventListener,听到后作为实现了IEventDispatcher的mapitem也是直接就派发了这个event实例。

      那么在外部的mapitem在它的动画播放完的这一刻,收到了content上层的displayContent发出来的event,也意外的收到了最下面的content通过冒泡发出来了event!可能是冒泡的事件先到?貌似是。

      要么用冒泡,中间层不用监听和传递事件,这样到是不用多写事件类;要么不用冒泡。

      个人觉得这个地方不要用冒泡,而且各层传递都有不同的意思,最好做到各层传递时用不同的事件类型。

      

  • 相关阅读:
    转:同步、异步、阻塞和非阻塞
    转:回调函数
    转:同步/异步与阻塞/非阻塞的区别
    转:Socket在阻塞模式下的信息收发和文件接收
    转:直接用socket实现HTTP协议
    链接错误 LINK : fatal error LNK1104: 无法打开文件“XX.obj”
    转:MFC中常用类,宏,函数介绍
    转:线程同步技术剖析
    转:线程同步
    转:C++回调函数用法
  • 原文地址:https://www.cnblogs.com/JD85/p/1969409.html
Copyright © 2020-2023  润新知