Hi Mikhail,
Thanks you very much for your instructions. Sorry I'm not very familiar
with this wrapper concept, so I may need your help on these questions:
- Does a wrapper of an interface basically has the same intention to an
implementation of an service, only the latter implements multiple
interfaces?
- How can a implemented wrapper be used in further programming? Since
there's not registration as a component I guess we should just make an
instance of the class and call its member functions?
Thanks and Best Regards,
Felix.
Mikhail Voitenko 写道:
Hi Felix,
thank you for the stacks. The problem here is that after the user has
decided to do no recovery the filter detection process actually should
be stopped. Unfortunately it seems that the current design does not
allow to do it, and the shown filter selection dialog is just a part
of the filter detection process that goes further.
We could use a workaround, implement a wrapper around interaction
handler, that would prevent showing of the filter selection dialog. We
could probably prevent appearing of any dialog during the further
detection, but I would prefer to avoid possibility of non wished quite
actions. Even if they are not possible now, they could be implemented
in future.
So the wrapper will implement the task::XInteractionHandler interface.
The constructor will get the original interaction handler and in case
XInteractionHandler::handle() call is called the implementation will
call the original handler except the case that the
"document::NoSuchFilterRequest" is provided.
You can find an example of similar wrapper implementation in
sfx2/source/doc/docfile.cxx:SfxMediumHandler_Impl. I think it makes
sense that the class is implemented in "comphelper" since the problem
should be solved not only for writer, but also for other applications.
Best Regards,
Mikhail.
Zhang Xiaofei wrote:
Hi Mikhail,
I'm glad to know the previous issue is solved. :-)
The problem of i63661 is still reproducible here, I recorded the
stacks respectively to all the three boxes are shown, (while the
third one may be not so useful,) the previous two are almost the same
except for the 16th line:
===================================
+swd680mi.dll!SwFilterDetect::detect(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>
& lDescriptor={...}) Line 317 + 0x22 C++ (stack1_promptdialog)
-swd680mi.dll!SwFilterDetect::detect(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>
& lDescriptor={...}) Line 326 + 0x22 C++ (stack2_notifydialog)
-----------------------------------
Some tracing shows that bRepairAllowed has the right value 0, sorry I
didn't got enough time to finish the tracing, maybe the problem lies
around line 426 of G:\OOo\SRC680_m225\sw\source\ui\uno\swdetect.cxx.
I'll have to continue it next Monday. Could you give me some hints on
this, please?
Thanks and Best Regards,
Felix.
Mikhail Voitenko 写道:
Hi Felix,
Thank you for checking the scenario. I have marked the issue as non
reproducible and have sent it to QA.
A new task could the the issue i63661. Please test whether the
problem is still reproducible. If it is, please get the call stack
at the place where the dialog regarding document repair is shown,
just break in the debugger while the dialog is visible. There are
two places, where the recovery might be activated, so we need to
detect which one is affected.
Best Regards,
Mikhail.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
