Issue 54593 - crash: drag slides bewtween 2 impress presentation, close one, save other
Summary: crash: drag slides bewtween 2 impress presentation, close one, save other
Status: CLOSED FIXED
Alias: None
Product: Impress
Classification: Application
Component: editing (show other issues)
Version: OOo 2.0
Hardware: PC All
: P2 Trivial (vote)
Target Milestone: OOo 2.0.1
Assignee: wolframgarten
QA Contact: issues@graphics
URL:
Keywords:
: 54635 55523 (view as issue list)
Depends on:
Blocks:
 
Reported: 2005-09-14 12:34 UTC by radekdoulik
Modified: 2005-11-10 13:40 UTC (History)
2 users (show)

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


Attachments
backtrace (4.58 KB, text/plain)
2005-09-14 12:36 UTC, radekdoulik
no flags Details
backgrounds presentation (113.17 KB, application/vnd.oasis.opendocument.presentation)
2005-09-14 12:37 UTC, radekdoulik
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description radekdoulik 2005-09-14 12:34:30 UTC
When draging 3rd slide from backgrounds.odp
presentation to another one, close the backgrounds presentation and save the
other one. it crashes during saving.
Comment 1 radekdoulik 2005-09-14 12:36:00 UTC
Created attachment 29551 [details]
backtrace
Comment 2 radekdoulik 2005-09-14 12:37:46 UTC
Created attachment 29552 [details]
backgrounds presentation
Comment 3 wolframgarten 2005-09-15 09:25:25 UTC
This is reproducible. But from the behaviour this might be duplicate to i54635? 
The ID of the error report is rn43c8.
Comment 4 clippka 2005-09-15 16:53:50 UTC
yes it is duplicate to issue 54593. You can verify it if you try to insert slide
3 through insert->file, it also crashes. The problems are the animated shapes on
slide 3, please see my evaluation in issue 54593
Comment 5 wolframgarten 2005-09-16 09:04:37 UTC
Target changed.
Comment 6 wolframgarten 2005-09-16 09:05:39 UTC
*** Issue 54635 has been marked as a duplicate of this issue. ***
Comment 7 clippka 2005-09-16 10:51:08 UTC
Fixed,

the problem was that when inserting a slide the containing shapes got a new
model. Since some of the shapes had an animation effect assigned there where
living api wrapper objects for the shapes. The api wrapper object from svx
already got the update that the model changed, because of fix in issue 44633.
But the derived class in sd, SdXShape, still had a dangling pointer to the
SdXImpressModel that was already deleted.

Fixed for shapes by adding virtual callbacks to the SvxShapeMaster interface so
the SvxShape can inform its master SdXShape about model changes.
Since this issue was already an oversight while fixing issue 44633, I also fixed
the protential problem that a reference to a slide is hold while the slide got a
new model.
Now SdrPage::SetModel also informs SvxDrawPage of model change. I also changed
SdGenericDrawPage but since I can't make incompatibel changes now I used a
trick. Before using the SdXImpressModel pointer of SdGenericDrawPage I check if
the SdrModel is still the same.
Comment 8 clippka 2005-10-11 09:28:25 UTC
@cl->wg: this was fixed in cws c03v1 but it seems I missed to register it at the
cws, please verify the fix on master cov680m3

re-open issue and reassign to wg@openoffice.org
Comment 9 clippka 2005-10-11 09:28:37 UTC
reassign to wg@openoffice.org
Comment 10 clippka 2005-10-11 09:30:50 UTC
reset resolution to FIXED
Comment 11 wolframgarten 2005-10-11 09:43:25 UTC
*** Issue 55523 has been marked as a duplicate of this issue. ***
Comment 12 scagni 2005-10-23 17:51:36 UTC
I am sorry to write this but it seems to me that the problem is not completely
fixed. I am using rc3 51014 and I still cannot insert any page (or a whole file)
of a presentation file into another with the "insert>file" command. The saving
will invariably give you an "impossible to save" error. This was actually issue
"55523: Saving impossible after inserting other file" that was marked as a
duplicate of 54593, I think incorrectly: the drag and drop of slides from one
open presentation file to another is now working (and that's 54593 fixed), but
the use of the above menu command still does not, at least for me.
Comment 13 wolframgarten 2005-11-10 13:40:13 UTC
Tested in m139. Lets last mentioned problem is not reproducible in m139.
Comment 14 wolframgarten 2005-11-10 13:40:43 UTC
If it still occurs please writer a new issue. Closed.