diff options
author | Tor Lillqvist <tml@collabora.com> | 2018-03-16 16:39:37 +0200 |
---|---|---|
committer | Tor Lillqvist <tml@collabora.com> | 2018-05-30 23:55:11 +0200 |
commit | f7e0297b01f739e17f2f9517bf3d89baaee654ab (patch) | |
tree | 50f736835ec776150465600dc152c55f89d68f50 /oovbaapi/ooo/vba/XSinkCaller.idl | |
parent | 63e65d1743264dfa26d2aba615d71978e65784e8 (diff) |
Work in progress related to invoking events in Automation clients
XConnectable interfaces need a second IID, for the interface "itself",
not the coclass. (I am sure there is some catchy short term for that,
I just can't find it right now.)
Allow several simultaneous sinks for a SwVbaApplication. Not sure in
what case such would be needed, but you never know about 3rd-party
client code, and it's trivial to handle anyway, so why not.
Lots of FIXMEs still. There is likely also a lot of leaks. But at
least an event handler in a simple VBScript script does get invoked.
Note that the changed and added code in extensions/source/ole is
totally unaware of what outgoing ("event") interfaces Writer or Calc
implements, it is all handled generically through the UNO interfaces I
added recently.
One particular thing that needs doing is to actually make Writer (and
Calc) raise this kind of events when necessary. The current code to
invoke events handlers in StarBasic (including StarBasic code running
in "VBA" compaibility) is very much tied to having StarBasic running
(not surprisingly), which of course is not at all the case when it is
an Automation client that is manipulating a Writer or Calc instance
and wants events.
There is demonstration-only code in SwVbaApplication::Documents() to
raise the "Quit" event. (I would have put that in the SwVbaApplication
destructor but that doesn't seem to get called.) That should of course
go away once we invoke other relevant events in appropriate places.
And the "Quit" event needs to be invoked when the application is
quitting.
The whole callback mechanism with IConnectionPoint etc is still partly
a mystery to me. It is entirely possible that even if this now works
for a simple VBScript client, it won't work for (for instance) a VB6
client that might exercise the APIs of the COM interfaces we provide
in a different way.
Add XSinkCaller, for something that perhaps calls one or several
XSinks.
Change-Id: Ica03344010e374542f4aceff5ec032c78579f937
Reviewed-on: https://gerrit.libreoffice.org/55093
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Diffstat (limited to 'oovbaapi/ooo/vba/XSinkCaller.idl')
-rw-r--r-- | oovbaapi/ooo/vba/XSinkCaller.idl | 29 |
1 files changed, 29 insertions, 0 deletions
diff --git a/oovbaapi/ooo/vba/XSinkCaller.idl b/oovbaapi/ooo/vba/XSinkCaller.idl new file mode 100644 index 000000000000..33be504fbe62 --- /dev/null +++ b/oovbaapi/ooo/vba/XSinkCaller.idl @@ -0,0 +1,29 @@ +/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4; fill-column: 100 -*- */ +/* + * This file is part of the LibreOffice project. + * + * This Source Code Form is subject to the terms of the Mozilla Public + * License, v. 2.0. If a copy of the MPL was not distributed with this + * file, You can obtain one at http://mozilla.org/MPL/2.0/. + */ + +#ifndef __ooo_vba_XSinkCaller_idl__ +#define __ooo_vba_XSinkCaller_idl__ + +module ooo { module vba { + +// Despite being here in ooo::vba, this has nothing to do with "VBA" (Visual Basic for +// Applications), or the VBA compatibility in StarBasic. This is related to using LibreOffice from +// (OLE) Automation clients. It is here anyway because much of the API available to such clients +// is identical to that offered to StarBasic code written in a VBA-like fashion. + +interface XSinkCaller +{ + void CallSinks([in] string Method, [in] sequence<any> Arguments); +}; + +}; }; + +#endif + +/* vim:set shiftwidth=4 softtabstop=4 expandtab: */ |