Hi Mikhail,
The patches have been attached to the issue. Thank you very much for
helping me on this task, and I'm eagerly looking forward to the next one.
Thanks and Best Regards, :-)
Felix.
Mikhail Voitenko
Hi Felix,
Thank you for the new patches. I would say you could attach them
already to the issue. But since you will need the new version for
further development anyway, you could try the patches on the new
version to check whether the strange crash is still reproducible in
your environment.
I think there is no need to wait for m239 in this case, m238 is
relative stable and I currently can not see any benefit from using
m239 instead.
I will looks for the next task :)
Best Regards,
Mikhail.
Zhang Xiaofei wrote:
Zhang Xiaofei
Hi Mikhail,
Thanks for testing the patches, however I am afraid the result is
still uncertain. I rebuilt the full build and the crash still exist,
since my build is based on SRC680_m225, I guess it is better I
integrate the patches to a newer one and retest it? I have got the
source of SRC680_m238 but I hear SRC680_m239, which will be used as
the foundation of OOo 3.0 is being released soon, should I wait for
the latter one? I'm looking forward to your suggestions.
Thanks,
Felix.
P.S. I feel very sorry for the typos exist in the last patches, I
corrected them and made the new patches.
Mikhail Voitenko
Hi Felix,
Sorry for the delay. I have just tried your patch and it works
pretty well by me. So there seems to be something wrong with your
build.
Best regards,
Mikhail.
Zhang Xiaofei wrote:
Hi Mikhail,
Thanks very much for your replay, I have modified the patch to sw,
however my modification caused the build to collapse. I feel
awfully sorry to bother you again and again, but apparently there
is something I misunderstood in your instructions, could you check
the patch and point it out for me, or direct me to an example that
inserts a wrapper into the MediaDescriptor service, please?
Thanks and 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]
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
