| Summary: | Draw2d event dispatcher holds mouse capture on mouse up | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] GEF | Reporter: | Randy Hudson <hudsonr> | ||||
| Component: | GEF-Legacy Draw2d | Assignee: | Pratik Shah <ppshah> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | ahunter.eclipse, nyssen | ||||
| Version: | 3.3 | ||||||
| Target Milestone: | 3.3.0 (Europa) RC1 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Randy Hudson
Pratik, are you interested in trying to create a patch for this? The problem was something like mouseTarget is not set to null, and code in other places checks if the field is set. Look for calls to asyncExec in our current project. Created attachment 67296 [details]
Patch for SWTEventDispatcher
The problem is that the currentEvent is not getting cleared out. When the figure removes itself, the mouseTarget becomes null, and currentEvent is only ever updated if there's a mouseTarget. So, the stale event which had been consumed would stay around and prevent any events from propogating to the domain (editor). I've attached a simple patch that clears out the event in SWTEventDispatcher#receive(). I've tested it with our editor and with the logic example (circuit's scrollbars). I think this fix should be good enough since the currentEvent is only used with the mouseTarget.
Randy, please approve.
That seems like it would work. The only caller of getCurrentEvent is checking for null already. However, NULL is not mentioned in the javadoc, but the method isn't really "real" API that clients need to be calling. Probably the javadoc should be updated too. Anthony, can we commit this for RC1? Fixed. Comment on attachment 67296 [details]
Patch for SWTEventDispatcher
Removing iplog+ as contributor was committer (who applied the patch).
|