Issue 95793 - goodies: .met files don't open from command line if OOo launched with -draw
Summary: goodies: .met files don't open from command line if OOo launched with -draw
Status: CLOSED FIXED
Alias: None
Product: Draw
Classification: Application
Component: code (show other issues)
Version: DEV300m31
Hardware: All Linux, all
: P3 Trivial (vote)
Target Milestone: OOo 3.1
Assignee: thorsten.martens
QA Contact: issues@graphics
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-11-03 10:26 UTC by caolanm
Modified: 2009-01-07 12:16 UTC (History)
2 users (show)

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


Attachments
patch to do this (1009 bytes, patch)
2008-11-03 10:26 UTC, caolanm
no flags Details | Diff
demo file (139.36 KB, application/octet-stream)
2008-11-03 10:35 UTC, caolanm
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description caolanm 2008-11-03 10:26:08 UTC
So, taking the attached .met and OOo not running.

If we do... /path/to/soffice /tmp/demo.met it will open fine
If we do... /path/to/soffice -draw /tmp/demo.met it doesn't open

In the "-draw" case sfx2/source/doc/objstor.cxx SfxObjectShell::HandleFilter the
property UIComponent will be set and we will call DoExportDialog in
goodies/source/filter.vcl/eos2met/eos2met.cxx. While in the no "-draw" case we
do not.

If draw has a frame open then rPara.pWindow will be true in DoExportDialog and
we get the MET Options dialog, but for a first start we don't so we fall back
through BOOL    bRet = FALSE; and the .met doesn't open.

Attached changes the default ret of that method to be true so that if we do not
have a top level window we just take the default values and continue to open,
i.e the same result as if no "-draw" was on the command line
Comment 1 caolanm 2008-11-03 10:26:33 UTC
Created attachment 57674 [details]
patch to do this
Comment 2 caolanm 2008-11-03 10:35:42 UTC
Created attachment 57676 [details]
demo file
Comment 3 ooo 2008-11-03 10:44:46 UTC
reassigned to SJ
Comment 4 sven.jacobi 2008-11-03 17:45:47 UTC
Hi Caolán,

the question is, why is "DoExportDialog" called, I think this shouldn't be the
case. I will have a look at it.
Comment 5 sven.jacobi 2008-11-05 12:45:31 UTC
sj->mav: can you please take over this issue, the dialog of the met export
filter should not be called when loading a document. This is something that
should be handled in sfx.
Comment 6 mikhail.voytenko 2008-11-10 08:43:04 UTC
I will try to investigate it for 3.1.
Comment 7 mikhail.voytenko 2008-11-17 18:58:14 UTC
Actually this is a bug that the UIComponent is not set in the first case. The
UIComponent is a property from the filter configuration, and it is empty because
the filter configuration is still not completely loaded.

The dialog is requested correctly, since it is registered in the filter
configuration as a filter options dialog. And this dialog must be called every
time the filter is used if there is no default options set.
Comment 8 mikhail.voytenko 2008-11-20 17:19:43 UTC
Ok, the real problem was the type detection. It has suggested a pure export
filter sometimes in this scenario, the filter has a registered dialog that was
shown in this case. Interesting enough is that the pure export filter was able
to load the document successfully :)
Anyway, the typedetection should be fixed now.
Comment 9 mikhail.voytenko 2008-11-26 10:09:18 UTC
mav->tm: Please verify the issue. Additionally please run the automated tests
related to loading of documents of alien formats.
Comment 10 thorsten.martens 2008-12-08 13:08:18 UTC
Checked and verified in cws fwk92 -> OK !
Comment 11 caolanm 2009-01-07 12:15:48 UTC
integrated DEV300m38