Mon 26 Feb 2007 09:29:07 AM UTC, comment #11:
Closing this, as the original testcase works fine.
As for testcases, I'd just ask everyone reading this tracker
to please try at providing self-contained testcases
or testcases + test runners for the bugs.
|
Tue 20 Feb 2007 10:14:28 AM UTC, comment #10:
The mouse.swf movie runs fine now. Still we miss a specific
testcase for this. THere's some testing in attachMovieTest.swf
but something related to attachMovie is preventing
to succeed (altought you can visually see it's working).
|
Tue 13 Feb 2007 12:33:54 PM UTC, comment #9:
Ok, we want a testcase for this, similar to the ButtonEventTest.c
and associated ButtonEventTest-Runner.cpp.
Added Klaus in Cc as he knows well how to generate onClipEvent
with Ming.
|
Tue 13 Feb 2007 11:04:39 AM UTC, comment #8:
More precisely: onClipEvent() works always, even if you click on a (different) button. Both will receive the event.
|
Tue 13 Feb 2007 10:37:25 AM UTC, comment #7:
I could not find any reference in the docs ( http://www.adobe.com/support/flash/action_scripts/actionscript_dictionary/actionscript_dictionary614.html ) or elsewhere but apparently that's true (at least for kbd & mouse events)
|
Tue 13 Feb 2007 10:28:31 AM UTC, comment #6:
Interesting. So, should every character on stage receive the on_event(MOUSE_DOWN) call ? I tought this was only possible
by adding self to _global.Mouse as a listener...
|
Tue 13 Feb 2007 10:02:36 AM UTC, comment #5:
Ok, the button is now clickable again.
As for the "moving target" problem: When I subtract a little offset from the mouse coordinates (so that is actually in the middle of the visible pointer), then it works indeed. However, this should not be necessary as the onClipEvent() handlers work regardless of the current mouse position, AFAIK.
For example, I once made a presentation in Flash where a little off-screen MC catched mouse and keyboard events using onClipEvent() to advance the presentation.
|
Mon 12 Feb 2007 09:00:32 PM UTC, comment #4:
I committed a patch for the failing assertion.
The "moving target" problem is that the mouse pointer is permanently on the edge of the custom pointer.
Try changing the custom pointer origin so that the mouse
is always in the center of it, to see if it makes a difference.
|
Mon 12 Feb 2007 07:58:30 PM UTC, comment #3:
I see that it works sometimes now.
However:
- Can you explain the "moving target" problem? onClipEvent() works only with MovieClips/sprites and they can always move. However, even if I don't move the mouse pointer, it still does not receive eventy most of the time...
- Regression: now clicking on the green "play" button crashes Gnash with an assertion failure:
gnash: button_character_instance.cpp:478: virtual void gnash::button_character_instance::on_button_event(const gnash::event_id&): Assertion `0' failed.
Aborted
|
Mon 12 Feb 2007 07:26:52 PM UTC, comment #2:
I just committed a patch for this.
No, it wasn't only the "moving target" problem, but that's
still a problem.
You can generate the events, but only if you're quick enough
(seems a game: catch the pointer)
|
Mon 12 Feb 2007 05:49:38 PM UTC, comment #1:
Might be related to the fact that the clip event is attached
to a moving target (moving along with the mouse).
If you can provide an ad-hoc testcase that would help.
COnsider attaching the event to a non-moving target.
We can test this with the MovieTester, but we need something
to check (a variable set to a value on events).
|
Mon 12 Feb 2007 04:48:33 PM UTC, original submission:
The attached movie is a test case for the mouse (not specifically written for this bug). The mouse pointer is a mc with this ActionScript code associated:
onClipEvent(mouseDown) {
trace("click!");
_root.mouse.gotoAndStop(2);
}
onClipEvent(mouseUp) {
trace("release!");
_root.mouse.gotoAndStop(1);
}
This should print a debug message and show a little star around the mouse pointer showing that the click has been received.
It appears that Gnash does not even execute any of these statements.
|