|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | OO crashes when 'revieve focus' event switches on the Filter Mode | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Base | Reporter: | drewjensen.inbox | ||||||||
| Component: | code | Assignee: | marc.neumann | ||||||||
| Status: | CLOSED FIXED | QA Contact: | issues@dba <issues> | ||||||||
| Severity: | Trivial | ||||||||||
| Priority: | P2 | CC: | issues | ||||||||
| Version: | 680m167 | ||||||||||
| Target Milestone: | OOo 2.1 | ||||||||||
| Hardware: | All | ||||||||||
| OS: | All | ||||||||||
| Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||||||
| Developer Difficulty: | --- | ||||||||||
| Attachments: |
|
||||||||||
Created attachment 36498 [details]
subject database
Created attachment 36499 [details]
Crash report
Couple of further tests on this. The crash happens under release 2.0.2 also. It only happens when this particular macro is called - using dispatch to enter form filter mode. It only happens if dispatch is used to enter form filter mode, from the 'when receiving focus' evnet. If I instead call the macro from say, 'on mouse key release' instead then there is no problem. uhoh, this is ambitious. When switching to filter mode, the controls in the form are exchanged with special "filter control" versions. So when you do this from within a focus notification, you're probably destroying the control which just calls you. Not sure how this can best be fixed. Of course OOo should not crash. Notifying the events asynchronously might be an option. Created attachment 37078 [details]
DB doc with form with macro contained
The attached file has the respective macro contained in the form (i.e. is self-contained), so you can reproduce the crash directly. slightly adjusting the summary to reflect that the crux is switching on the filter mode reassign to the right developer accepting The immediate crash is fixed in CWS 204b, i.e. for 2.0.4. However, it still crashs when focusing the control with the mouse. Instead of also fixing symptoms only here, we need a more comprehensive solution for the cases where a Basic macro is called synchronously, and does unwanted things via the form UNO API (issue 67147 is another example for this). I have an idea, but the fix is risky, and checks need to be made whether existing macros are affected, so this will be for 2.0.5 only. fixed in CWS dba205a find more information about this CWS, like when it is available in the master builds, in EIS, the Environment Information System: http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=SRC680%2Fdba205a fs-> msc: please verify in CWS dba205a targeting to 2.1, since the fix is part of a CWS aiming for this release verified in CWS dba205a find more information about this CWS, like when it is available in the master builds, in EIS, the Environment Information System: http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=SRC680%2Fdba205a Hi, this is fixed in the current master. The current master is available at http://download.openoffice.org/680/index.html I close this issue now. Bye Marc |
NOTE - this is found in dev. build 169... Attached is a database with a form 'eventAttendees2'. This form contains a text field that has the events recieve and lose focus set to call two macros. The receiving focus event calls the sub setFormFilterOn sub SetFormFilterOn dim document as object dim dispatcher as object rem ---------------------------------------------------------------------- rem get access to the document document = ThisComponent.CurrentController.Frame dispatcher = createUnoService("com.sun.star.frame.DispatchHelper") rem ---------------------------------------------------------------------- dispatcher.executeDispatch(document, ".uno:FormFilter", "", 0, Array()) end sub With the above macro assigned entering the text field will crash OO.