hey hironmay
we've isolated if not solved the problem. elsewhere in the app, COMPLETELY unconnected to the SharedCursorPane, we've got a mx:ToggleButtonBar to which we, just prior to the point the app crashes, do this;
topBar.toggleButtonBar.selectedIndex = -1;
we tried killing some event bubbling thus:
topBar.toggleButtonBar.addEventListener(FlexEvent.VALUE_COMMIT, _onToggleBarChange);
private function _onToggleBarChange(event:FlexEvent):void
{
event.stopImmediatePropagation();
}
which fixed the problem ONCE but then it came back again. basically the line:
topBar.toggleButtonBar.selectedIndex = -1;
if commented out means the SharedCursorPane bug wont appear. but i need to change this toggleButtonBar's selectedIndex to -1, so that won't do.
im going to try to catch and stopImmediatePropagation on some of the toggleButtonBar's other events. dont know if itll make a difference but we'll see............
IMPORTANT UPDATE:
um. im just looking through the FP9 version of SharedCursorPane.as and can't help noticing it's littered with references to "stage". they're everywhere. it looks like that might be the 'null' prop in question thats causing the error. is it not a little presumptuous to think that every SharedWhiteBoard will always have a 'stage' property? my client want a whiteBoard that they can hide from time to time to go nav round the rest of the site, do some stuff but keep the meeting seesion & whiteBoard running, then come back to meeting later on. When this happens i'm far more inclined to do:
removeChild(meetingRoomCanvas);
than
meetingRoomCanvas.visible = false;
cos i know the FP will attempt to draw invisible onstage movieclips, thus being an unacceptable CPU drain. removeChild'ing it should be an option. i gave up using visible = false years ago and don't intend to go back.
