ActionScript MouseEvent.clone() 似乎已损坏？
我在尝试重新调度<时遇到了问题/a> ActionScript 3 中的鼠标事件，我承认对此有点怀疑。 我已将其范围缩小到 MouseEvent.clone() 方法出现，嗯，完全损坏了。 以下事件处理程序：
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);
}
产生以下输出，无限：
mousemove 167 206
mousemoveclone 0 0
这与我将 MouseEvent 重新分派到的代码正在接收的内容相匹配，因此我假设克隆函数已损坏。
这与链接文档指示的应该发生的情况直接矛盾，除非我错过了一些东西。 我完全不知道我做了什么（或没有做什么）可能会导致这种行为。 AS3 人员真的忘记阅读自己的文档 Event.clone()？
我可以通过针对我的特定用例使用函数对象来解决这个问题，但我不想这样做。 有任何想法吗？
编辑： localX 和 localY 成员似乎已被正确克隆，这让我对这里发生的情况更加茫然。
I have run into a problem attempting to redispatch mouse events in ActionScript 3, which I am admittedly a bit incredulous about. I have narrowed it down to the MouseEvent.clone() method appearing, well, completely broken. The following event handler:
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);
}
Results in the following output, ad infinitum:
mousemove 167 206
mousemoveclone 0 0
This matches what the code I was redispatching the MouseEvent to was receiving, hence my hypothesis of the broken clone function.
This is directly contradictory to what the linked documentation indicates should happen, unless I have missed something. I am at an entire loss as to what I did (or did not do) that could possibly cause this behavior. Did the AS3 guys really forget to read their own documents on Event.clone()?
I can work around this by instead using function objects for my specific use case, but I'd prefer not to. Any ideas?
Edit: The localX and localY members are being properly cloned it seems, which puts me at even more of a loss as to what is going on here.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这是一个已知的错误。 您可以在此处查看错误报告：http://bugs.adobe.com/jira/ browser/FP-343
不过，其他所有内容都应该被克隆。 您始终可以手动分配 stageX 和 stageY，直到错误得到修复。
Thats a known bug. You can see the bug report here: http://bugs.adobe.com/jira/browse/FP-343
Everything else should get cloned though. You can always just assign stageX and stageY manually until the bug is fixed.
我意识到这个线程休眠了 7 个月，但只是稍微更新一下 - 它在 FP10 和 Flex4 中仍然活跃。 如果您重新调度事件，也会发生这种情况。 即：
dispatchEvent()调用似乎相当于clone()，因此stageX和stageY设置为0
I realise this thread is 7 months dormant, but just to update this a bit - this is still active in FP10 and Flex4. It also happens if you redispatch the event. i.e.:
that dispatchEvent() call seems to be the equivalent of a clone(), so the stageX and stageY are set to 0
这是一个相当老的问题，但这是我在谷歌搜索解决方案时出现的问题，而且这里的内容还不够全面。
这个问题没有被“修复”的原因是它正在按预期工作。 stageX 和 stageY 值是在您调用 getter 时计算的，使用事件的目标进行 localToGlobal 转换。 这是必要的，以便即使目标对象自事件发送后已更改位置、比例或旋转，数字也能保持正确。
如果您确实需要使用正确的 stageX 和 stageY 值重新分派 MouseEvent，那么您的两个选择是：
创建覆盖 stageX 和 stageY getter 的 MouseEvent 的自定义子类。 您可以存储原始目标并自行执行 localToGlobal 计算，也可以使用克隆原始事件时存在的值来存储 stageX 和 stageY 的静态值。
扩展 Sprite 并将您的调度程序添加到舞台，以便库存 MouseEvent 能够正常工作。
扩展 Sprite 并将
This is a pretty old question, but it was what came up when I Googled for a solution, and what's here is just not comprehensive enough.
The reason this hasn't been "fixed" is because it's working as intended. The stageX and stageY values are calculated when you invoke the getter, using the event's target to do the localToGlobal conversion. This is necessary so that the numbers remain correct even if the target object has changed position, scale or rotation since the event was dispatched.
Your two options if you really need to redispatch a MouseEvent with correct stageX and stageY values are:
Create a custom subclass of MouseEvent that overrides the stageX and stageY getters. You can either store the original target and do the localToGlobal calculation yourself or you can store static values for stageX and stageY using the values that are there when you clone the original event.
Extend Sprite and add your dispatcher to the stage so that the stock MouseEvent will work properly.