Issue 62994 - need workaround for files that cause OOo to crash
Summary: need workaround for files that cause OOo to crash
Status: UNCONFIRMED
Alias: None
Product: Impress
Classification: Application
Component: open-import (show other issues)
Version: OOo 2.0.1
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-10 00:47 UTC by tmber
Modified: 2014-10-30 21:56 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description tmber 2006-03-10 00:47:51 UTC
Several times, I have ended up with OOo Impress files that could not be opened
because OOo would crash when loading them.

That sort of thing is very seriously and makes Impress nearly unusable for
preparing presentations: a user can't use a presentation tool if he has to fear
that making even a small change will result in a presentation file that cannot
be loaded or displayed.

Somehow, this needs to get fixed.  Frankly, I don't have much confidence that a
huge C/C++ project like this is ever going to catch all the bugs that cause the
application to crash.  But at least a workaround for these kinds of problems
would be good.

My suggestion would be to create a robust import function that gives the user
more control over what slides get loaded.  In particular, it might give the user
the following options:

-- exclude all embedded images
-- exclude all linked images
-- exclude all objects
-- remove aniations
-- exclude specific slides
-- remove all theming

Such a workaround is less than perfect, but until OOo stops crashing, it's
necessary.
Comment 1 wolframgarten 2006-03-10 07:49:51 UTC
I have never met an application from the normal user variety that does not have
defects or crash. Every software has defects.
If you have crashed: did you ever sent a crash report if you where offered to?
Which email did you use, which description? This would help us to fix the
problem. If you cannot give us a detailed stp by step description or a document
with which the problem occurs we go on to search for the needle in the haystack.
But your idea makes sense. I will change this issue to enhancement and reassign
it. Thanks for your help.
Comment 2 tmber 2006-03-11 03:16:43 UTC
"I have never met an application from the normal user variety that does not have
defects or crash. Every software has defects."

The problem isn't that OOo has defects, the problem is in the way it handles
them: if it encounters a defect, it just throws up a dialog box and says "sorry,
report it and maybe we'll fix it some time".  A lot of other software doesn't do
that--it attempts to fail and recover gracefully.

"If you have crashed: did you ever sent a crash report if you where offered to?"

Yes, multiple times. So, what do you suggest?  That I postpone my presentation
until you get around to fixing that particular bug?

Making software robust and dependable doesn't mean fixing all the bugs, it means
having it fail gracefully in the presence of the bugs that are inevitably there;
OOo doesn't, and that's a major defect.

If you don't like the workarounds I suggested, maybe you can find some other
solution.  But if you want people to take OOo seriously, the situation that a
user saves a file and then can never load it into OOo again because OOo
reproducibly crashes right after loading it simply is not acceptable.
Comment 3 Bugcruncher 2014-10-30 21:56:00 UTC
no activity for 8 years, should be closed