Issue 118965 - InstanceLocker can't usefully stop user closing a document because the frame is closed first
Summary: InstanceLocker can't usefully stop user closing a document because the frame ...
Status: UNCONFIRMED
Alias: None
Product: App Dev
Classification: Unclassified
Component: api (show other issues)
Version: 3.3.0 or older (OOo)
Hardware: PC Windows XP
: P3 Normal
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-23 18:17 UTC by DonJaime
Modified: 2013-02-24 21:06 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Tests InstanceLockers on document and frame and records events in order (18.08 KB, application/vnd.oasis.opendocument.text)
2012-02-23 18:17 UTC, DonJaime
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description DonJaime 2012-02-23 18:17:00 UTC
Created attachment 77242 [details]
Tests InstanceLockers on document and frame and records events in order

When a document is closed from the ui, the frame is closed first, and then the document. If the document close is aborted by throwing an exception (using com.sun.star.embed.InstanceLocker), the document is left in an unusable state since it is no longer attached to a frame and no longer has a controller.

When .Close() is called on the document from the api, the document is closed first. However, the disposed document is still visible in its controller's frame, which can be retained by aborting its close. Trying to do anything with the ghost document causes a crash.

Closing a document should always lead to closing of its controller's frame. The ui should call .Close() on the document, not the frame.

I am entering this under api and not under ui because as long as there is no recourse to the api it doesn't matter what order things happen.