Hi Mikhail,
Thank you but sorry I'm a little confused on the results, I have
modified the patch according to my comprehension on your descriptions.
However the problematic behavior remains on my machine even after the
recompiled DLL files are delivered. Could please check this patch and
give me some more suggestions? Sorry my minds seem a little slow here
and may have misunderstood your suggestions.
Best Regards,
Felix.
Mikhail Voitenko 写道:
Hi Felix,
The problem is that the new writer patch does not exchange the
InteractionHandler any more. Instead it shows the broken package
notifications using the new wrapper, that is unnecessary. As I have
written in the last IRC meeting, the wrapper should be insert into the
InteractionHandler after the repairing has failed or user has canceled
the repairing, in other words it should be done just after the
NotifyBrokenPackage interaction is shown.
Best Regards,
Mikhail.
Zhang Xiaofei wrote:
Hi Mikhail,
Thanks to your advice in our last IRC meeting, I have remade the
patches so that the wrapper handles the interaction instead.
Unfortunately the modifications still do not prevent the filter
selection box from appearing. Could you help to review the patches
and give me some suggestions please?
With Thanks and Best Regards,
Felix.
zhangxiaofei 写道:
Hi Mikhail,
I'm sorry I encountered some problem. The implementation of the
wrapper was OK in the compilation phase, but when I tried to
initialize an instance of it, I got the link error as in the log.
I'm not sure if the problem lies in the implementation, or it is
because I did not initialize it in the right way. Could you help me
with this please?
Thanks and Best Regards,
Felix.
Mikhail Voitenko 写道:
Hi Felix,
In this case a wrapper is just an implementation that implements
the same set of interfaces as the original object, and redirects
most of the calls to the original object. It just slightly changes
the behavior by aborting the filter selection interception.
There is no necessity to register the wrapper as a service in this
case. The object will be just created with C++ "new" operator and
after that it's lifetime will be controlled by refcounting as it
happens for all the UNO-objects. In other words the factory for the
object is the source code itself in this case, because of this the
XInitialization interface is also not necessary here (
XInitialization is used only on object initialization and should
not be used further ). Theoretically XServiceInfo should be
implemented, since it is a wrapper for the service.
And since in this case the source code has access to the C++
interface, it can use C++ API in addition to the UNO API ( in this
case we will use the constructor to provide the original
interaction handler ). But only while the object is accessible as
C++ object. Since the InteractionHandler wrapper is inserted into
the MediaDescriptor ( in other words it is transported using UNO
API ), the source code that will retrieve it from there will be
able to use UNO API only.
Best Regards,
Mikhail.
Zhang Xiaofei wrote:
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]
diff -urNpw @sw/source/ui/uno/swdetect.cxx sw/source/ui/uno/swdetect.cxx
--- @sw/source/ui/uno/swdetect.cxx 2007-11-26 17:21:04.000000000 +0800
+++ sw/source/ui/uno/swdetect.cxx 2007-11-30 17:19:52.000000000 +0800
@@ -101,6 +101,7 @@
#include <sfx2/brokenpackageint.hxx>
#include <svx/impgrf.hxx>
#include <svtools/FilterConfigItem.hxx>
+#include <comphelper/InteractionHandlerWrapper.hxx>
#ifndef INCLUDED_SVTOOLS_MODULEOPTIONS_HXX
#include <svtools/moduleoptions.hxx>
@@ -323,7 +324,8 @@ SwFilterDetect::~SwFilterDetect()
//
repair either not allowed or not successful
NotifyBrokenPackage* pNotifyRequest = new NotifyBrokenPackage( aDocumentTitle );
uno::Reference<
task::XInteractionRequest > xRequest ( pNotifyRequest );
-
xInteraction->handle( xRequest );
+ ::comphelper::OInteractionHandlerWrapper*
pHandler = new ::comphelper::OInteractionHandlerWrapper( xInteraction );
+
pHandler->handle( xRequest );
aMedium.SetError( ERRCODE_ABORT );
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
