Hello Yan Wu,
Hello Andreas,
After some analysis of the interactionhandler, we have some concepts
about that. An instance can be passed to
XInteractionHandler::hanle(...). Each interaction request contains a
number of interaction continuations. For the passworddlg,the user
interaction like:
hand()->handle_impl()->handlePasswordRequest()->handlePasswordRequest()->executePasswordDialog
Is above right or misunderstanding?
Now we are not clear what the needed environment informations of the
interaction handler are.
An implementation of the interface XInteractionHandler of course will be
an InteractionHandler by itself.
Such InteractionHandler can be passed to some other APIs of OOo ... e.g.
dispatches or the well known function loadComponentFromURL().
A handler is used in cases where some "internal problems" must be solved
... e.g. password must be retrieved;warnings/erros must be shown
or filters must be selected by the user.
An interaction must not be an UI action always. E.g. you can pass a
special implemented interaction handler which make it's work without any UI
(e.g. by answering password requests hard coded).
The method XInteractionHandler.handle() is called with an interaction
object. Those object is analyzed within it's type first. Every
interaction must be defined
as real UNO type based on css::uno::Exception. The reason for that: if
an interaction is not handled the same object must be thrown as an
exception.
Such intercation can transport two groups of parameters: a)
In-Parameters specifying the interaction more in detail (e.g. two
filters where the suer should decide which of them
must be used) and b) a list of continuations. Such continuations are
used to show the calli of XInteractionHandler::handle() if the
interaction was handled and
how they was handled. There are some standard continuations as XAbort,
XContinue. Of course you can define new continuations which fits to your
special
designed interaction.
What do we need to fix issue #73968# ?
We need some context informations during an interaction.
The implementation in our "uui" module is an UI based implementations.
Mostly message boxes and windows are shown. Especialy to fix this issue here
we need a parent window for all new generated windows/dialogs etcpp.
So I would say ...
a) we should provide an initialization method on the uui-interaction
handler implementation.
css.lang.XInitialization would be a good candidate.
b) Within the method XInitialization::initialize() the given sequence of
arguments will be
analyzed and context informations are retrieved and saved as members.
E.g. a css.frame.XFrame. Thos frame provides: the frame with it's parent
child relations,
the window, the document and some other usefully informations.
c) All internal generated windows/dialogs etcpp. must use the container
window of the frame as
parent window. Please note: thos context information is an optional
parameter. If no such parent
window was given ... all message boxes must be shown as today without a
parent.
d) The framework code must be changed so the new inialization interface
is used and the
frame is set on the used interaction handler.
Looking forward your help!
Regards,
Yan Wu
Regards
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
