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>
2018-03-16 16:39:37 +02:00
|
|
|
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4; fill-column: 100 -*- */
|
2011-03-31 10:05:04 +02:00
|
|
|
/*
|
|
|
|
|
* 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/.
|
|
|
|
|
*
|
|
|
|
|
* This file incorporates work covered by the following license notice:
|
|
|
|
|
*
|
|
|
|
|
* Licensed to the Apache Software Foundation (ASF) under one or more
|
|
|
|
|
* contributor license agreements. See the NOTICE file distributed
|
|
|
|
|
* with this work for additional information regarding copyright
|
|
|
|
|
* ownership. The ASF licenses this file to you under the Apache
|
|
|
|
|
* License, Version 2.0 (the "License"); you may not use this file
|
|
|
|
|
* except in compliance with the License. You may obtain a copy of
|
|
|
|
|
* the License at http://www.apache.org/licenses/LICENSE-2.0 .
|
|
|
|
|
*/
|
2013-11-05 02:17:53 +01:00
|
|
|
#ifndef INCLUDED_SW_SOURCE_UI_VBA_VBAAPPLICATION_HXX
|
|
|
|
|
#define INCLUDED_SW_SOURCE_UI_VBA_VBAAPPLICATION_HXX
|
2009-09-18 15:35:47 +00:00
|
|
|
|
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>
2018-03-16 16:39:37 +02:00
|
|
|
#include <vector>
|
|
|
|
|
|
|
|
|
|
#include <ooo/vba/XSink.hpp>
|
2018-03-22 12:46:56 +02:00
|
|
|
#include <ooo/vba/XSinkCaller.hpp>
|
2009-09-18 15:35:47 +00:00
|
|
|
#include <ooo/vba/word/XApplication.hpp>
|
|
|
|
|
#include <ooo/vba/word/XDocument.hpp>
|
|
|
|
|
#include <ooo/vba/word/XWindow.hpp>
|
|
|
|
|
#include <ooo/vba/word/XSystem.hpp>
|
|
|
|
|
#include <ooo/vba/word/XOptions.hpp>
|
|
|
|
|
#include <ooo/vba/word/XSelection.hpp>
|
|
|
|
|
#include <ooo/vba/word/XAddins.hpp>
|
|
|
|
|
#include <vbahelper/vbahelperinterface.hxx>
|
|
|
|
|
#include <vbahelper/vbaapplicationbase.hxx>
|
2015-09-08 08:51:30 +09:00
|
|
|
#include <cppuhelper/implbase.hxx>
|
2009-09-18 15:35:47 +00:00
|
|
|
|
2018-04-16 21:50:55 +03:00
|
|
|
#include "vbawindow.hxx"
|
|
|
|
|
|
2018-03-22 12:46:56 +02:00
|
|
|
typedef cppu::ImplInheritanceHelper< VbaApplicationBase, ooo::vba::word::XApplication, ooo::vba::XSinkCaller > SwVbaApplication_BASE;
|
|
|
|
|
|
|
|
|
|
// This class is currently not a singleton. One instance is created per document with (potential?)
|
|
|
|
|
// StarBasic code in it, I think, and a shared one for all Automation clients connected to the
|
|
|
|
|
// ooo::vba::word::Application (Writer.Application) service. (Of course it probably is not common to
|
|
|
|
|
// have several Automation clients at once.)
|
|
|
|
|
|
|
|
|
|
// Should it be a true singleton? Hard to say. Anyway, it is actually the SwVbaGlobals class that
|
|
|
|
|
// should be a singleton in that case, I think.
|
2009-09-18 15:35:47 +00:00
|
|
|
|
|
|
|
|
class SwVbaApplication : public SwVbaApplication_BASE
|
|
|
|
|
{
|
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>
2018-03-16 16:39:37 +02:00
|
|
|
std::vector<css::uno::Reference< ooo::vba::XSink >> mvSinks;
|
2018-04-16 21:50:55 +03:00
|
|
|
SwVbaWindow* getActiveSwVbaWindow();
|
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>
2018-03-16 16:39:37 +02:00
|
|
|
|
2009-09-18 15:35:47 +00:00
|
|
|
public:
|
2015-05-26 13:56:20 +01:00
|
|
|
explicit SwVbaApplication( css::uno::Reference< css::uno::XComponentContext >& m_xContext );
|
2016-09-13 13:09:01 +02:00
|
|
|
virtual ~SwVbaApplication() override;
|
2009-09-18 15:35:47 +00:00
|
|
|
|
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>
2018-03-16 16:39:37 +02:00
|
|
|
sal_uInt32 AddSink( const css::uno::Reference< ooo::vba::XSink >& xSink );
|
|
|
|
|
void RemoveSink( sal_uInt32 nNumber );
|
|
|
|
|
|
2009-09-18 15:35:47 +00:00
|
|
|
// XApplication
|
2017-01-26 12:28:58 +01:00
|
|
|
virtual OUString SAL_CALL getName() override;
|
|
|
|
|
virtual css::uno::Reference< ooo::vba::word::XSystem > SAL_CALL getSystem() override;
|
|
|
|
|
virtual css::uno::Reference< ov::word::XDocument > SAL_CALL getActiveDocument() override;
|
|
|
|
|
virtual css::uno::Reference< ov::word::XWindow > SAL_CALL getActiveWindow() override;
|
|
|
|
|
virtual css::uno::Reference< ooo::vba::word::XOptions > SAL_CALL getOptions() override;
|
|
|
|
|
virtual css::uno::Reference< ooo::vba::word::XSelection > SAL_CALL getSelection() override;
|
|
|
|
|
virtual css::uno::Any SAL_CALL CommandBars( const css::uno::Any& aIndex ) override;
|
|
|
|
|
virtual css::uno::Any SAL_CALL Documents( const css::uno::Any& aIndex ) override;
|
|
|
|
|
virtual css::uno::Any SAL_CALL Addins( const css::uno::Any& aIndex ) override;
|
|
|
|
|
virtual css::uno::Any SAL_CALL Dialogs( const css::uno::Any& aIndex ) override;
|
|
|
|
|
virtual css::uno::Any SAL_CALL ListGalleries( const css::uno::Any& aIndex ) override;
|
|
|
|
|
virtual sal_Bool SAL_CALL getDisplayAutoCompleteTips() override;
|
|
|
|
|
virtual void SAL_CALL setDisplayAutoCompleteTips( sal_Bool _displayAutoCompleteTips ) override;
|
|
|
|
|
virtual sal_Int32 SAL_CALL getEnableCancelKey() override;
|
|
|
|
|
virtual void SAL_CALL setEnableCancelKey( sal_Int32 _enableCancelKey ) override;
|
2018-04-16 21:09:01 +03:00
|
|
|
virtual sal_Int32 SAL_CALL getWindowState() override;
|
|
|
|
|
virtual void SAL_CALL setWindowState( sal_Int32 _windowstate ) override;
|
2017-01-26 12:28:58 +01:00
|
|
|
virtual float SAL_CALL CentimetersToPoints( float Centimeters ) override;
|
2018-03-07 14:34:54 +02:00
|
|
|
virtual void SAL_CALL ShowMe() override;
|
2018-04-16 21:50:55 +03:00
|
|
|
virtual void SAL_CALL Resize( sal_Int32 Width, sal_Int32 Height ) override;
|
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>
2018-03-16 16:39:37 +02:00
|
|
|
|
|
|
|
|
// XInterfaceWithIID
|
|
|
|
|
virtual OUString SAL_CALL getIID() override;
|
|
|
|
|
|
|
|
|
|
// XConnectable
|
|
|
|
|
virtual OUString SAL_CALL GetIIDForClassItselfNotCoclass() override;
|
|
|
|
|
virtual ov::TypeAndIID SAL_CALL GetConnectionPoint() override;
|
|
|
|
|
virtual css::uno::Reference<ov::XConnectionPoint> SAL_CALL FindConnectionPoint() override;
|
|
|
|
|
|
2009-09-18 15:35:47 +00:00
|
|
|
// XHelperInterface
|
2015-10-12 16:04:04 +02:00
|
|
|
virtual OUString getServiceImplName() override;
|
|
|
|
|
virtual css::uno::Sequence<OUString> getServiceNames() override;
|
2018-03-22 12:46:56 +02:00
|
|
|
|
|
|
|
|
// XSinkCaller
|
2018-04-09 15:10:40 +03:00
|
|
|
virtual void SAL_CALL CallSinks( const OUString& Method, css::uno::Sequence< css::uno::Any >& Arguments ) override;
|
2018-03-22 12:46:56 +02:00
|
|
|
|
2009-09-18 15:35:47 +00:00
|
|
|
protected:
|
2017-01-26 12:28:58 +01:00
|
|
|
virtual css::uno::Reference< css::frame::XModel > getCurrentDocument() override;
|
2009-09-18 15:35:47 +00:00
|
|
|
};
|
2013-11-05 02:17:53 +01:00
|
|
|
#endif // INCLUDED_SW_SOURCE_UI_VBA_VBAAPPLICATION_HXX
|
2010-10-14 08:30:41 +02:00
|
|
|
|
|
|
|
|
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
|