Apache OpenOffice (AOO) Bugzilla – Issue 95793
goodies: .met files don't open from command line if OOo launched with -draw
Last modified: 2009-01-07 12:16:06 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
Created attachment 57674 [details] patch to do this
Created attachment 57676 [details] demo file
reassigned to SJ
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.
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.
I will try to investigate it for 3.1.
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.
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.
mav->tm: Please verify the issue. Additionally please run the automated tests related to loading of documents of alien formats.
Checked and verified in cws fwk92 -> OK !
integrated DEV300m38