2018-04-17 00:19:54 +03: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 .
|
|
|
|
*/
|
2018-06-07 14:23:58 +03:00
|
|
|
|
|
|
|
#include <com/sun/star/task/XStatusIndicatorSupplier.hpp>
|
|
|
|
#include <com/sun/star/task/XStatusIndicator.hpp>
|
|
|
|
|
2009-09-18 15:35:47 +00:00
|
|
|
#include "vbaapplication.hxx"
|
|
|
|
#include "vbadocument.hxx"
|
2018-07-31 19:58:50 +02:00
|
|
|
#include <sal/log.hxx>
|
2009-09-18 15:35:47 +00:00
|
|
|
#include <osl/file.hxx>
|
|
|
|
#include <vbahelper/vbahelper.hxx>
|
|
|
|
#include "vbawindow.hxx"
|
|
|
|
#include "vbasystem.hxx"
|
|
|
|
#include "vbaoptions.hxx"
|
|
|
|
#include "vbaselection.hxx"
|
|
|
|
#include "vbadocuments.hxx"
|
|
|
|
#include "vbaaddins.hxx"
|
2018-06-12 20:01:41 +03:00
|
|
|
#include "vbamailmerge.hxx"
|
2009-09-18 15:35:47 +00:00
|
|
|
#include "vbadialogs.hxx"
|
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 <ooo/vba/XConnectionPoint.hpp>
|
2009-09-18 15:35:47 +00:00
|
|
|
#include <ooo/vba/word/WdEnableCancelKey.hpp>
|
2018-04-16 21:09:01 +03:00
|
|
|
#include <ooo/vba/word/WdWindowState.hpp>
|
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 <ooo/vba/word/XApplicationOutgoing.hpp>
|
2018-06-12 17:58:44 +03:00
|
|
|
#include <ooo/vba/word/XBookmarks.hpp>
|
2012-12-04 19:36:15 +01:00
|
|
|
#include <basic/sbuno.hxx>
|
2010-01-08 18:32:51 +01:00
|
|
|
#include <editeng/acorrcfg.hxx>
|
2009-09-18 15:35:47 +00:00
|
|
|
#include "wordvbahelper.hxx"
|
|
|
|
#include <docsh.hxx>
|
2018-03-22 12:46:56 +02:00
|
|
|
#include <swdll.hxx>
|
|
|
|
#include <swmodule.hxx>
|
2010-10-06 10:16:50 +01:00
|
|
|
#include "vbalistgalleries.hxx"
|
2009-09-18 15:35:47 +00:00
|
|
|
|
|
|
|
using namespace ::ooo;
|
|
|
|
using namespace ::ooo::vba;
|
|
|
|
using namespace ::com::sun::star;
|
|
|
|
|
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
|
|
|
class SwVbaApplicationOutgoingConnectionPoint : public cppu::WeakImplHelper<XConnectionPoint>
|
|
|
|
{
|
|
|
|
private:
|
|
|
|
SwVbaApplication* mpApp;
|
|
|
|
|
|
|
|
public:
|
|
|
|
SwVbaApplicationOutgoingConnectionPoint( SwVbaApplication* pApp );
|
|
|
|
|
|
|
|
// XConnectionPoint
|
|
|
|
sal_uInt32 SAL_CALL Advise(const uno::Reference< XSink >& Sink ) override;
|
|
|
|
void SAL_CALL Unadvise( sal_uInt32 Cookie ) override;
|
|
|
|
};
|
|
|
|
|
2018-05-15 14:33:17 +03:00
|
|
|
class SwWordBasic : public cppu::WeakImplHelper<word::XWordBasic>
|
|
|
|
{
|
|
|
|
private:
|
|
|
|
SwVbaApplication* mpApp;
|
|
|
|
|
|
|
|
public:
|
|
|
|
SwWordBasic( SwVbaApplication* pApp );
|
|
|
|
|
|
|
|
// XWordBasic
|
2018-06-12 20:01:41 +03:00
|
|
|
virtual sal_Int32 SAL_CALL getMailMergeMainDocumentType() override;
|
|
|
|
virtual void SAL_CALL setMailMergeMainDocumentType( sal_Int32 _mailmergemaindocumenttype ) override;
|
|
|
|
|
2018-05-15 14:33:17 +03:00
|
|
|
virtual void SAL_CALL FileOpen( const OUString& Name, const uno::Any& ConfirmConversions, const uno::Any& ReadOnly, const uno::Any& AddToMru, const uno::Any& PasswordDoc, const uno::Any& PasswordDot, const uno::Any& Revert, const uno::Any& WritePasswordDoc, const uno::Any& WritePasswordDot ) override;
|
2019-01-18 18:39:31 +02:00
|
|
|
virtual void SAL_CALL FileSave() override;
|
2019-01-23 18:33:50 +02:00
|
|
|
virtual void SAL_CALL FileClose( const css::uno::Any& Save ) override;
|
2019-01-22 13:59:18 +02:00
|
|
|
virtual void SAL_CALL ToolsOptionsView( const css::uno::Any& DraftFont,
|
|
|
|
const css::uno::Any& WrapToWindow,
|
|
|
|
const css::uno::Any& PicturePlaceHolders,
|
|
|
|
const css::uno::Any& FieldCodes,
|
|
|
|
const css::uno::Any& BookMarks,
|
|
|
|
const css::uno::Any& FieldShading,
|
|
|
|
const css::uno::Any& StatusBar,
|
|
|
|
const css::uno::Any& HScroll,
|
|
|
|
const css::uno::Any& VScroll,
|
|
|
|
const css::uno::Any& StyleAreaWidth,
|
|
|
|
const css::uno::Any& Tabs,
|
|
|
|
const css::uno::Any& Spaces,
|
|
|
|
const css::uno::Any& Paras,
|
|
|
|
const css::uno::Any& Hyphens,
|
|
|
|
const css::uno::Any& Hidden,
|
2019-01-21 18:08:12 +02:00
|
|
|
const css::uno::Any& ShowAll,
|
2019-01-22 13:59:18 +02:00
|
|
|
const css::uno::Any& Drawings,
|
|
|
|
const css::uno::Any& Anchors,
|
|
|
|
const css::uno::Any& TextBoundaries,
|
|
|
|
const css::uno::Any& VRuler,
|
|
|
|
const css::uno::Any& Highlight ) override;
|
2018-06-12 16:20:57 +03:00
|
|
|
virtual OUString SAL_CALL WindowName() override;
|
2018-06-12 17:58:44 +03:00
|
|
|
virtual sal_Bool SAL_CALL ExistingBookmark( const OUString& Name ) override;
|
2018-06-12 20:01:41 +03:00
|
|
|
virtual void SAL_CALL MailMergeOpenDataSource(const OUString& Name, const css::uno::Any& Format,
|
|
|
|
const css::uno::Any& ConfirmConversions, const css::uno::Any& ReadOnly,
|
|
|
|
const css::uno::Any& LinkToSource, const css::uno::Any& AddToRecentFiles,
|
|
|
|
const css::uno::Any& PasswordDocument, const css::uno::Any& PasswordTemplate,
|
|
|
|
const css::uno::Any& Revert, const css::uno::Any& WritePasswordDocument,
|
|
|
|
const css::uno::Any& WritePasswordTemplate, const css::uno::Any& Connection,
|
|
|
|
const css::uno::Any& SQLStatement, const css::uno::Any& SQLStatement1,
|
|
|
|
const css::uno::Any& OpenExclusive, const css::uno::Any& SubType) override;
|
2019-02-07 12:04:49 +02:00
|
|
|
virtual sal_Int32 SAL_CALL AppMaximize( const css::uno::Any& WindowName, const css::uno::Any& State ) override;
|
2019-02-06 12:08:59 +02:00
|
|
|
virtual sal_Int32 SAL_CALL DocMaximize( const css::uno::Any& State ) override;
|
2019-02-07 11:55:51 +02:00
|
|
|
virtual void SAL_CALL AppShow( const css::uno::Any& WindowName ) override;
|
2019-02-06 12:22:39 +02:00
|
|
|
virtual sal_Int32 SAL_CALL AppCount() override;
|
2018-05-15 14:33:17 +03: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
|
|
|
SwVbaApplication::SwVbaApplication( uno::Reference<uno::XComponentContext >& xContext ):
|
|
|
|
SwVbaApplication_BASE( xContext )
|
2009-09-18 15:35:47 +00:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
SwVbaApplication::~SwVbaApplication()
|
|
|
|
{
|
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
|
2018-03-22 12:46:56 +02:00
|
|
|
SwVbaApplication::AddSink( const uno::Reference< XSink >& xSink )
|
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
|
|
|
{
|
2018-03-22 12:46:56 +02:00
|
|
|
{
|
|
|
|
SolarMutexGuard aGuard;
|
|
|
|
SwGlobals::ensure();
|
|
|
|
}
|
|
|
|
// No harm in potentially calling this several times
|
|
|
|
SW_MOD()->RegisterAutomationApplicationEventsCaller( uno::Reference< XSinkCaller >(this) );
|
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
|
|
|
mvSinks.push_back(xSink);
|
2018-11-11 08:39:26 +01:00
|
|
|
return mvSinks.size();
|
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
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
SwVbaApplication::RemoveSink( sal_uInt32 nNumber )
|
|
|
|
{
|
|
|
|
if (nNumber < 1 || nNumber > mvSinks.size())
|
|
|
|
return;
|
|
|
|
|
|
|
|
mvSinks[nNumber-1] = uno::Reference< XSink >();
|
2009-09-18 15:35:47 +00:00
|
|
|
}
|
|
|
|
|
2013-04-07 12:06:47 +02:00
|
|
|
OUString SAL_CALL
|
2017-01-26 12:28:58 +01:00
|
|
|
SwVbaApplication::getName()
|
2009-09-18 15:35:47 +00:00
|
|
|
{
|
2014-11-03 14:03:54 +02:00
|
|
|
return OUString("Microsoft Word" );
|
2009-09-18 15:35:47 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
uno::Reference< word::XDocument > SAL_CALL
|
2017-01-26 12:28:58 +01:00
|
|
|
SwVbaApplication::getActiveDocument()
|
2009-09-18 15:35:47 +00:00
|
|
|
{
|
|
|
|
return new SwVbaDocument( this, mxContext, getCurrentDocument() );
|
|
|
|
}
|
|
|
|
|
2018-04-16 21:50:55 +03:00
|
|
|
SwVbaWindow *
|
|
|
|
SwVbaApplication::getActiveSwVbaWindow()
|
2009-09-18 15:35:47 +00:00
|
|
|
{
|
2015-07-02 18:25:58 +02:00
|
|
|
// #FIXME so far can't determine Parent
|
2011-03-25 10:40:25 +01:00
|
|
|
uno::Reference< frame::XModel > xModel( getCurrentDocument(), uno::UNO_SET_THROW );
|
|
|
|
uno::Reference< frame::XController > xController( xModel->getCurrentController(), uno::UNO_SET_THROW );
|
|
|
|
return new SwVbaWindow( uno::Reference< XHelperInterface >(), mxContext, xModel, xController );
|
2009-09-18 15:35:47 +00:00
|
|
|
}
|
|
|
|
|
2018-07-06 19:00:38 +02:00
|
|
|
uno::Reference< css::uno::XComponentContext > const &
|
2018-06-12 20:01:41 +03:00
|
|
|
SwVbaApplication::getContext()
|
|
|
|
{
|
|
|
|
return mxContext;
|
|
|
|
}
|
|
|
|
|
2018-04-16 21:50:55 +03:00
|
|
|
uno::Reference< word::XWindow > SAL_CALL
|
|
|
|
SwVbaApplication::getActiveWindow()
|
|
|
|
{
|
|
|
|
return getActiveSwVbaWindow();
|
|
|
|
}
|
|
|
|
|
2009-09-18 15:35:47 +00:00
|
|
|
uno::Reference<word::XSystem > SAL_CALL
|
2017-01-26 12:28:58 +01:00
|
|
|
SwVbaApplication::getSystem()
|
2009-09-18 15:35:47 +00:00
|
|
|
{
|
|
|
|
return uno::Reference< word::XSystem >( new SwVbaSystem( mxContext ) );
|
|
|
|
}
|
|
|
|
|
|
|
|
uno::Reference<word::XOptions > SAL_CALL
|
2017-01-26 12:28:58 +01:00
|
|
|
SwVbaApplication::getOptions()
|
2009-09-18 15:35:47 +00:00
|
|
|
{
|
|
|
|
return uno::Reference< word::XOptions >( new SwVbaOptions( mxContext ) );
|
|
|
|
}
|
|
|
|
|
|
|
|
uno::Any SAL_CALL
|
2017-01-26 12:28:58 +01:00
|
|
|
SwVbaApplication::CommandBars( const uno::Any& aIndex )
|
2009-09-18 15:35:47 +00:00
|
|
|
{
|
2019-01-18 14:49:24 +02:00
|
|
|
try
|
|
|
|
{
|
|
|
|
return VbaApplicationBase::CommandBars( aIndex );
|
|
|
|
}
|
|
|
|
catch (const uno::RuntimeException&)
|
|
|
|
{
|
|
|
|
return uno::Any();
|
|
|
|
}
|
2009-09-18 15:35:47 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
uno::Reference< word::XSelection > SAL_CALL
|
2017-01-26 12:28:58 +01:00
|
|
|
SwVbaApplication::getSelection()
|
2009-09-18 15:35:47 +00:00
|
|
|
{
|
|
|
|
return new SwVbaSelection( this, mxContext, getCurrentDocument() );
|
|
|
|
}
|
|
|
|
|
2018-05-15 14:33:17 +03:00
|
|
|
uno::Reference< word::XWordBasic > SAL_CALL
|
|
|
|
SwVbaApplication::getWordBasic()
|
|
|
|
{
|
|
|
|
uno::Reference< word::XWordBasic > xWB( new SwWordBasic( this ) );
|
|
|
|
return xWB;
|
|
|
|
}
|
|
|
|
|
2009-09-18 15:35:47 +00:00
|
|
|
uno::Any SAL_CALL
|
2017-01-26 12:28:58 +01:00
|
|
|
SwVbaApplication::Documents( const uno::Any& index )
|
2009-09-18 15:35:47 +00:00
|
|
|
{
|
|
|
|
uno::Reference< XCollection > xCol( new SwVbaDocuments( this, mxContext ) );
|
|
|
|
if ( index.hasValue() )
|
|
|
|
return xCol->Item( index, uno::Any() );
|
|
|
|
return uno::makeAny( xCol );
|
|
|
|
}
|
|
|
|
|
|
|
|
uno::Any SAL_CALL
|
2017-01-26 12:28:58 +01:00
|
|
|
SwVbaApplication::Addins( const uno::Any& index )
|
2009-09-18 15:35:47 +00:00
|
|
|
{
|
|
|
|
static uno::Reference< XCollection > xCol( new SwVbaAddins( this, mxContext ) );
|
|
|
|
if ( index.hasValue() )
|
|
|
|
return xCol->Item( index, uno::Any() );
|
|
|
|
return uno::makeAny( xCol );
|
|
|
|
}
|
|
|
|
|
|
|
|
uno::Any SAL_CALL
|
2017-01-26 12:28:58 +01:00
|
|
|
SwVbaApplication::Dialogs( const uno::Any& index )
|
2009-09-18 15:35:47 +00:00
|
|
|
{
|
|
|
|
uno::Reference< word::XDialogs > xCol( new SwVbaDialogs( this, mxContext, getCurrentDocument() ));
|
|
|
|
if ( index.hasValue() )
|
|
|
|
return xCol->Item( index );
|
|
|
|
return uno::makeAny( xCol );
|
|
|
|
}
|
|
|
|
|
2010-10-06 10:16:50 +01:00
|
|
|
uno::Any SAL_CALL
|
2017-01-26 12:28:58 +01:00
|
|
|
SwVbaApplication::ListGalleries( const uno::Any& index )
|
2010-10-06 10:16:50 +01:00
|
|
|
{
|
|
|
|
uno::Reference< text::XTextDocument > xTextDoc( getCurrentDocument(), uno::UNO_QUERY_THROW );
|
|
|
|
uno::Reference< XCollection > xCol( new SwVbaListGalleries( this, mxContext, xTextDoc ) );
|
|
|
|
if ( index.hasValue() )
|
|
|
|
return xCol->Item( index, uno::Any() );
|
|
|
|
return uno::makeAny( xCol );
|
|
|
|
}
|
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
sal_Bool SAL_CALL SwVbaApplication::getDisplayAutoCompleteTips()
|
2009-09-18 15:35:47 +00:00
|
|
|
{
|
2011-05-20 09:06:56 +01:00
|
|
|
return SvxAutoCorrCfg::Get().IsAutoTextTip();
|
2009-09-18 15:35:47 +00:00
|
|
|
}
|
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
void SAL_CALL SwVbaApplication::setDisplayAutoCompleteTips( sal_Bool _displayAutoCompleteTips )
|
2009-09-18 15:35:47 +00:00
|
|
|
{
|
2011-05-20 09:06:56 +01:00
|
|
|
SvxAutoCorrCfg::Get().SetAutoTextTip( _displayAutoCompleteTips );
|
2009-09-18 15:35:47 +00:00
|
|
|
}
|
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
sal_Int32 SAL_CALL SwVbaApplication::getEnableCancelKey()
|
2009-09-18 15:35:47 +00:00
|
|
|
{
|
|
|
|
// the default value is wdCancelInterrupt in Word
|
|
|
|
return word::WdEnableCancelKey::wdCancelInterrupt;
|
|
|
|
}
|
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
void SAL_CALL SwVbaApplication::setEnableCancelKey( sal_Int32/* _enableCancelKey */)
|
2009-09-18 15:35:47 +00:00
|
|
|
{
|
|
|
|
// seems not supported in Writer
|
|
|
|
}
|
|
|
|
|
2018-04-16 21:09:01 +03:00
|
|
|
sal_Int32 SAL_CALL SwVbaApplication::getWindowState()
|
|
|
|
{
|
|
|
|
auto xWindow = getActiveWindow();
|
|
|
|
if (xWindow.is())
|
|
|
|
{
|
|
|
|
uno::Any aState = xWindow->getWindowState();
|
|
|
|
sal_Int32 nState;
|
|
|
|
if (aState >>= nState)
|
|
|
|
return nState;
|
|
|
|
}
|
|
|
|
|
|
|
|
return word::WdWindowState::wdWindowStateNormal; // ?
|
|
|
|
}
|
|
|
|
|
|
|
|
void SAL_CALL SwVbaApplication::setWindowState( sal_Int32 _windowstate )
|
|
|
|
{
|
2019-02-06 12:32:35 +02:00
|
|
|
try
|
|
|
|
{
|
|
|
|
auto xWindow = getActiveWindow();
|
|
|
|
if (xWindow.is())
|
|
|
|
{
|
|
|
|
uno::Any aState;
|
|
|
|
aState <<= _windowstate;
|
|
|
|
xWindow->setWindowState( aState );
|
|
|
|
}
|
|
|
|
}
|
|
|
|
catch (const uno::RuntimeException&)
|
2018-04-16 21:09:01 +03:00
|
|
|
{
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-04-17 00:35:56 +03:00
|
|
|
sal_Int32 SAL_CALL SwVbaApplication::getWidth()
|
|
|
|
{
|
|
|
|
auto pWindow = getActiveSwVbaWindow();
|
|
|
|
return pWindow->getWidth();
|
|
|
|
}
|
|
|
|
|
|
|
|
void SAL_CALL SwVbaApplication::setWidth( sal_Int32 _width )
|
|
|
|
{
|
|
|
|
auto pWindow = getActiveSwVbaWindow();
|
|
|
|
pWindow->setWidth( _width );
|
|
|
|
}
|
|
|
|
|
|
|
|
sal_Int32 SAL_CALL SwVbaApplication::getHeight()
|
|
|
|
{
|
|
|
|
auto pWindow = getActiveSwVbaWindow();
|
|
|
|
return pWindow->getHeight();
|
|
|
|
}
|
|
|
|
|
|
|
|
void SAL_CALL SwVbaApplication::setHeight( sal_Int32 _height )
|
|
|
|
{
|
|
|
|
auto pWindow = getActiveSwVbaWindow();
|
|
|
|
pWindow->setHeight( _height );
|
|
|
|
}
|
|
|
|
|
|
|
|
sal_Int32 SAL_CALL SwVbaApplication::getLeft()
|
|
|
|
{
|
|
|
|
auto pWindow = getActiveSwVbaWindow();
|
|
|
|
return pWindow->getLeft();
|
|
|
|
}
|
|
|
|
|
|
|
|
void SAL_CALL SwVbaApplication::setLeft( sal_Int32 _left )
|
|
|
|
{
|
|
|
|
auto pWindow = getActiveSwVbaWindow();
|
|
|
|
pWindow->setLeft( _left );
|
|
|
|
}
|
|
|
|
|
|
|
|
sal_Int32 SAL_CALL SwVbaApplication::getTop()
|
|
|
|
{
|
|
|
|
auto pWindow = getActiveSwVbaWindow();
|
|
|
|
return pWindow->getTop();
|
|
|
|
}
|
|
|
|
|
|
|
|
void SAL_CALL SwVbaApplication::setTop( sal_Int32 _top )
|
|
|
|
{
|
|
|
|
auto pWindow = getActiveSwVbaWindow();
|
|
|
|
pWindow->setTop( _top );
|
|
|
|
}
|
|
|
|
|
Add ooo.vba.word.Application.StatusBar property for debug output from client
In many cases you don't want to use a bunch of MessageBox() calls in a
VB6 client you are developing against LibreOffice, as that disrupts
the working of the client. The developer might not mind, but other
people trying it will be bothered by having to click through a stream
of message boxes. Also, it is hard to correctly interpret the
chronological sequence of LibreOffice's own debug output lines and
such MessageBox() windows.
WScript.Echo calls from a VBScript client are a bit better as they
don't require any click-through, but still there is the problem of
correlating with LibreOffice's own debug output.
Setting this StatusBar property causes LibreOffice to output a
SAL_INFO line with the tag "extensions.olebridge". Thus they are
automatically merged with LibreOffice's own output and displayed in
correct order.
Sure, the intent of some existing 3rd-party client that sets this
property would be to actually display a message in the status bar
(whatever that corresponds to in LibreOffice), but until some such
need is actually encountered, it's enough to just use it for this
debug output functionality. After all, this property was not
implemented at all earlier, so adding it now with somewhat special
semantics is not a regression.
(Note that on the Calc side, ooo.vba.excel.XApplication did have a
StatusBar property already, and setting that does seem to attempt to
display the text in some way. Possibly it should be enhanced to also
do the SAL_INFO thing, for consistency? And possibly we should also
have the message being displayed in the same fashion on the Writer
side?)
Change-Id: I5bf1e776d6401adfc43a558a2d919bd675298e1a
Reviewed-on: https://gerrit.libreoffice.org/55413
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
2018-06-07 12:02:23 +03:00
|
|
|
OUString SAL_CALL SwVbaApplication::getStatusBar()
|
|
|
|
{
|
|
|
|
return OUString("");
|
|
|
|
}
|
|
|
|
|
2019-01-18 14:14:37 +02:00
|
|
|
uno::Any SAL_CALL SwVbaApplication::getCustomizationContext()
|
|
|
|
{
|
|
|
|
return uno::Any(); // ???
|
|
|
|
}
|
|
|
|
|
2019-01-21 10:42:37 +00:00
|
|
|
void SAL_CALL SwVbaApplication::setCustomizationContext(const uno::Any& /*_customizationcontext*/)
|
2019-01-18 14:14:37 +02:00
|
|
|
{
|
|
|
|
// ???
|
|
|
|
}
|
|
|
|
|
Add ooo.vba.word.Application.StatusBar property for debug output from client
In many cases you don't want to use a bunch of MessageBox() calls in a
VB6 client you are developing against LibreOffice, as that disrupts
the working of the client. The developer might not mind, but other
people trying it will be bothered by having to click through a stream
of message boxes. Also, it is hard to correctly interpret the
chronological sequence of LibreOffice's own debug output lines and
such MessageBox() windows.
WScript.Echo calls from a VBScript client are a bit better as they
don't require any click-through, but still there is the problem of
correlating with LibreOffice's own debug output.
Setting this StatusBar property causes LibreOffice to output a
SAL_INFO line with the tag "extensions.olebridge". Thus they are
automatically merged with LibreOffice's own output and displayed in
correct order.
Sure, the intent of some existing 3rd-party client that sets this
property would be to actually display a message in the status bar
(whatever that corresponds to in LibreOffice), but until some such
need is actually encountered, it's enough to just use it for this
debug output functionality. After all, this property was not
implemented at all earlier, so adding it now with somewhat special
semantics is not a regression.
(Note that on the Calc side, ooo.vba.excel.XApplication did have a
StatusBar property already, and setting that does seem to attempt to
display the text in some way. Possibly it should be enhanced to also
do the SAL_INFO thing, for consistency? And possibly we should also
have the message being displayed in the same fashion on the Writer
side?)
Change-Id: I5bf1e776d6401adfc43a558a2d919bd675298e1a
Reviewed-on: https://gerrit.libreoffice.org/55413
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
2018-06-07 12:02:23 +03:00
|
|
|
void SAL_CALL SwVbaApplication::setStatusBar( const OUString& _statusbar )
|
|
|
|
{
|
2018-06-07 14:23:58 +03:00
|
|
|
// ScVbaAppSettings::setStatusBar() also uses the XStatusIndicator to show this, so maybe that is OK?
|
|
|
|
uno::Reference< frame::XModel > xModel( getCurrentDocument(), uno::UNO_QUERY );
|
|
|
|
if (xModel.is())
|
|
|
|
{
|
|
|
|
uno::Reference< task::XStatusIndicatorSupplier > xStatusIndicatorSupplier( xModel->getCurrentController(), uno::UNO_QUERY );
|
|
|
|
if (xStatusIndicatorSupplier.is())
|
|
|
|
{
|
|
|
|
uno::Reference< task::XStatusIndicator > xStatusIndicator( xStatusIndicatorSupplier->getStatusIndicator(), uno::UNO_QUERY );
|
|
|
|
if (xStatusIndicator.is())
|
|
|
|
xStatusIndicator->start( _statusbar, 100 );
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Add ooo.vba.word.Application.StatusBar property for debug output from client
In many cases you don't want to use a bunch of MessageBox() calls in a
VB6 client you are developing against LibreOffice, as that disrupts
the working of the client. The developer might not mind, but other
people trying it will be bothered by having to click through a stream
of message boxes. Also, it is hard to correctly interpret the
chronological sequence of LibreOffice's own debug output lines and
such MessageBox() windows.
WScript.Echo calls from a VBScript client are a bit better as they
don't require any click-through, but still there is the problem of
correlating with LibreOffice's own debug output.
Setting this StatusBar property causes LibreOffice to output a
SAL_INFO line with the tag "extensions.olebridge". Thus they are
automatically merged with LibreOffice's own output and displayed in
correct order.
Sure, the intent of some existing 3rd-party client that sets this
property would be to actually display a message in the status bar
(whatever that corresponds to in LibreOffice), but until some such
need is actually encountered, it's enough to just use it for this
debug output functionality. After all, this property was not
implemented at all earlier, so adding it now with somewhat special
semantics is not a regression.
(Note that on the Calc side, ooo.vba.excel.XApplication did have a
StatusBar property already, and setting that does seem to attempt to
display the text in some way. Possibly it should be enhanced to also
do the SAL_INFO thing, for consistency? And possibly we should also
have the message being displayed in the same fashion on the Writer
side?)
Change-Id: I5bf1e776d6401adfc43a558a2d919bd675298e1a
Reviewed-on: https://gerrit.libreoffice.org/55413
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
2018-06-07 12:02:23 +03:00
|
|
|
// Yes, we intentionally use the "extensions.olebridge" tag here even if this is sw. We
|
|
|
|
// interpret setting the StatusBar property as a request from an Automation client to display
|
|
|
|
// the string in LibreOffice's debug output, and all other generic Automation support debug
|
|
|
|
// output (in extensions/source/ole) uses that tag. If the check for "cross-module" or mixed log
|
|
|
|
// areas in compilerplugins/clang/sallogareas.cxx is re-activated, this will have to be added as
|
|
|
|
// a special case.
|
|
|
|
|
|
|
|
SAL_INFO("extensions.olebridge", "Client debug output: " << _statusbar);
|
|
|
|
}
|
|
|
|
|
2017-01-26 12:28:58 +01:00
|
|
|
float SAL_CALL SwVbaApplication::CentimetersToPoints( float Centimeters )
|
2009-09-18 15:35:47 +00:00
|
|
|
{
|
2016-04-22 10:08:07 +02:00
|
|
|
return VbaApplicationBase::CentimetersToPoints( Centimeters );
|
2009-09-18 15:35:47 +00:00
|
|
|
}
|
|
|
|
|
2018-03-07 14:34:54 +02:00
|
|
|
void SAL_CALL SwVbaApplication::ShowMe()
|
|
|
|
{
|
|
|
|
// No idea what we should or could do
|
|
|
|
}
|
|
|
|
|
2018-04-16 21:50:55 +03:00
|
|
|
void SAL_CALL SwVbaApplication::Resize( sal_Int32 Width, sal_Int32 Height )
|
|
|
|
{
|
2018-04-17 00:19:54 +03:00
|
|
|
// Have to do it like this as the Width and Height are hidden away in the ooo::vba::XWindowBase
|
|
|
|
// which ooo::vba::word::XApplication does not inherit from. SwVbaWindow, however, does inherit
|
|
|
|
// from XWindowBase. Ugh.
|
2018-04-16 21:50:55 +03:00
|
|
|
auto pWindow = getActiveSwVbaWindow();
|
|
|
|
pWindow->setWidth( Width );
|
|
|
|
pWindow->setHeight( Height );
|
|
|
|
}
|
|
|
|
|
2018-04-17 00:19:54 +03:00
|
|
|
void SAL_CALL SwVbaApplication::Move( sal_Int32 Left, sal_Int32 Top )
|
|
|
|
{
|
|
|
|
// See comment in Resize().
|
|
|
|
auto pWindow = getActiveSwVbaWindow();
|
|
|
|
pWindow->setLeft( Left );
|
|
|
|
pWindow->setTop( Top );
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
|
|
|
|
OUString SAL_CALL
|
|
|
|
SwVbaApplication::getIID()
|
|
|
|
{
|
|
|
|
return OUString("{82154421-0FBF-11d4-8313-005004526AB4}");
|
|
|
|
}
|
|
|
|
|
|
|
|
// XConnectable
|
|
|
|
|
|
|
|
OUString SAL_CALL
|
|
|
|
SwVbaApplication::GetIIDForClassItselfNotCoclass()
|
|
|
|
{
|
|
|
|
return OUString("{82154423-0FBF-11D4-8313-005004526AB4}");
|
|
|
|
}
|
|
|
|
|
|
|
|
TypeAndIID SAL_CALL
|
|
|
|
SwVbaApplication::GetConnectionPoint()
|
|
|
|
{
|
|
|
|
TypeAndIID aResult =
|
|
|
|
{ word::XApplicationOutgoing::static_type(),
|
|
|
|
"{82154422-0FBF-11D4-8313-005004526AB4}"
|
|
|
|
};
|
|
|
|
|
|
|
|
return aResult;
|
|
|
|
}
|
|
|
|
|
|
|
|
uno::Reference<XConnectionPoint> SAL_CALL
|
|
|
|
SwVbaApplication::FindConnectionPoint()
|
|
|
|
{
|
|
|
|
uno::Reference<XConnectionPoint> xCP(new SwVbaApplicationOutgoingConnectionPoint(this));
|
|
|
|
return xCP;
|
|
|
|
}
|
|
|
|
|
2013-04-07 12:06:47 +02:00
|
|
|
OUString
|
2009-09-18 15:35:47 +00:00
|
|
|
SwVbaApplication::getServiceImplName()
|
|
|
|
{
|
2013-04-07 12:06:47 +02:00
|
|
|
return OUString("SwVbaApplication");
|
2009-09-18 15:35:47 +00:00
|
|
|
}
|
|
|
|
|
2013-04-07 12:06:47 +02:00
|
|
|
uno::Sequence< OUString >
|
2009-09-18 15:35:47 +00:00
|
|
|
SwVbaApplication::getServiceNames()
|
|
|
|
{
|
2018-11-22 13:11:47 +02:00
|
|
|
static uno::Sequence< OUString > const aServiceNames
|
2009-09-18 15:35:47 +00:00
|
|
|
{
|
2018-11-22 13:11:47 +02:00
|
|
|
"ooo.vba.word.Application"
|
|
|
|
};
|
2009-09-18 15:35:47 +00:00
|
|
|
return aServiceNames;
|
|
|
|
}
|
2010-10-14 08:30:41 +02:00
|
|
|
|
2018-04-21 01:50:16 +03:00
|
|
|
uno::Reference< frame::XModel >
|
|
|
|
SwVbaApplication::getCurrentDocument()
|
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
|
|
|
{
|
2018-04-21 01:50:16 +03:00
|
|
|
return getCurrentWordDoc( mxContext );
|
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
|
|
|
}
|
|
|
|
|
2018-03-22 12:46:56 +02:00
|
|
|
// XSinkCaller
|
|
|
|
|
|
|
|
void SAL_CALL
|
2018-04-09 15:10:40 +03:00
|
|
|
SwVbaApplication::CallSinks( const OUString& Method, uno::Sequence< uno::Any >& Arguments )
|
2018-03-22 12:46:56 +02:00
|
|
|
{
|
|
|
|
for (auto& i : mvSinks)
|
|
|
|
{
|
|
|
|
if (i.is())
|
|
|
|
i->Call(Method, Arguments);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
// SwVbaApplicationOutgoingConnectionPoint
|
|
|
|
|
2018-04-21 01:50:16 +03:00
|
|
|
SwVbaApplicationOutgoingConnectionPoint::SwVbaApplicationOutgoingConnectionPoint( SwVbaApplication* pApp ) :
|
|
|
|
mpApp(pApp)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
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
|
|
|
// XConnectionPoint
|
|
|
|
sal_uInt32 SAL_CALL
|
|
|
|
SwVbaApplicationOutgoingConnectionPoint::Advise( const uno::Reference< XSink >& Sink )
|
|
|
|
{
|
|
|
|
return mpApp->AddSink(Sink);
|
|
|
|
}
|
|
|
|
|
|
|
|
void SAL_CALL
|
|
|
|
SwVbaApplicationOutgoingConnectionPoint::Unadvise( sal_uInt32 Cookie )
|
|
|
|
{
|
|
|
|
mpApp->RemoveSink( Cookie );
|
|
|
|
}
|
|
|
|
|
2018-05-15 14:33:17 +03:00
|
|
|
// SwWordBasic
|
|
|
|
|
|
|
|
SwWordBasic::SwWordBasic( SwVbaApplication* pApp ) :
|
|
|
|
mpApp(pApp)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2018-06-12 20:01:41 +03:00
|
|
|
// XWordBasic
|
|
|
|
sal_Int32 SAL_CALL
|
|
|
|
SwWordBasic::getMailMergeMainDocumentType()
|
|
|
|
{
|
|
|
|
return SwVbaMailMerge::get( mpApp->getParent(), mpApp->getContext() )->getMainDocumentType();
|
|
|
|
}
|
|
|
|
|
2018-05-15 14:33:17 +03:00
|
|
|
// XWordBasic
|
2018-06-12 20:01:41 +03:00
|
|
|
void SAL_CALL
|
|
|
|
SwWordBasic::setMailMergeMainDocumentType( sal_Int32 _mailmergemaindocumenttype )
|
|
|
|
{
|
|
|
|
SwVbaMailMerge::get( mpApp->getParent(), mpApp->getContext() )->setMainDocumentType( _mailmergemaindocumenttype );
|
|
|
|
}
|
|
|
|
|
2018-05-15 14:33:17 +03:00
|
|
|
void SAL_CALL
|
|
|
|
SwWordBasic::FileOpen( const OUString& Name, const uno::Any& ConfirmConversions, const uno::Any& ReadOnly, const uno::Any& AddToMru, const uno::Any& PasswordDoc, const uno::Any& PasswordDot, const uno::Any& Revert, const uno::Any& WritePasswordDoc, const uno::Any& WritePasswordDot )
|
|
|
|
{
|
|
|
|
uno::Any aDocuments = mpApp->Documents( uno::Any() );
|
|
|
|
|
|
|
|
uno::Reference<word::XDocuments> rDocuments;
|
|
|
|
|
|
|
|
if (aDocuments >>= rDocuments)
|
|
|
|
rDocuments->Open( Name, ConfirmConversions, ReadOnly, AddToMru, PasswordDoc, PasswordDot, Revert, WritePasswordDoc, WritePasswordDot, uno::Any(), uno::Any(), uno::Any(), uno::Any(), uno::Any(), uno::Any(), uno::Any() );
|
|
|
|
}
|
|
|
|
|
2019-01-18 18:39:31 +02:00
|
|
|
void SAL_CALL
|
|
|
|
SwWordBasic::FileSave()
|
|
|
|
{
|
2019-01-21 17:33:01 +02:00
|
|
|
uno::Reference< frame::XModel > xModel( mpApp->getCurrentDocument(), uno::UNO_SET_THROW );
|
|
|
|
dispatchRequests(xModel,".uno:Save");
|
2019-01-18 18:39:31 +02:00
|
|
|
}
|
|
|
|
|
2019-01-23 18:33:50 +02:00
|
|
|
void SAL_CALL
|
|
|
|
SwWordBasic::FileClose( const css::uno::Any& Save )
|
|
|
|
{
|
|
|
|
uno::Reference< frame::XModel > xModel( mpApp->getCurrentDocument(), uno::UNO_SET_THROW );
|
|
|
|
|
2019-02-15 12:37:11 +02:00
|
|
|
sal_Int16 nSave = 0;
|
2019-02-13 14:41:46 +02:00
|
|
|
if (Save.hasValue() && (Save >>= nSave) && (nSave == 0 || nSave == 1))
|
2019-01-23 18:33:50 +02:00
|
|
|
FileSave();
|
|
|
|
|
|
|
|
// FIXME: Here I would much prefer to call VbaDocumentBase::Close() but not sure how to get at
|
|
|
|
// the VbaDocumentBase of the current document. (Probably it is easy and I haven't looked hard
|
|
|
|
// enough.)
|
|
|
|
//
|
|
|
|
// FIXME: Error handling. If there is no current document, return some kind of error? But for
|
|
|
|
// now, just ignore errors. This code is written to work for a very specific customer use case
|
|
|
|
// ayway, not for an arbitrary sequence of COM calls to the "VBA" API.
|
|
|
|
dispatchRequests(xModel,".uno:CloseDoc");
|
|
|
|
}
|
|
|
|
|
2019-01-18 16:59:51 +02:00
|
|
|
void SAL_CALL
|
2019-01-22 13:59:18 +02:00
|
|
|
SwWordBasic::ToolsOptionsView( const css::uno::Any& DraftFont,
|
|
|
|
const css::uno::Any& WrapToWindow,
|
|
|
|
const css::uno::Any& PicturePlaceHolders,
|
|
|
|
const css::uno::Any& FieldCodes,
|
|
|
|
const css::uno::Any& BookMarks,
|
|
|
|
const css::uno::Any& FieldShading,
|
|
|
|
const css::uno::Any& StatusBar,
|
|
|
|
const css::uno::Any& HScroll,
|
|
|
|
const css::uno::Any& VScroll,
|
|
|
|
const css::uno::Any& StyleAreaWidth,
|
|
|
|
const css::uno::Any& Tabs,
|
|
|
|
const css::uno::Any& Spaces,
|
|
|
|
const css::uno::Any& Paras,
|
|
|
|
const css::uno::Any& Hyphens,
|
|
|
|
const css::uno::Any& Hidden,
|
|
|
|
const css::uno::Any& ShowAll,
|
|
|
|
const css::uno::Any& Drawings,
|
|
|
|
const css::uno::Any& Anchors,
|
|
|
|
const css::uno::Any& TextBoundaries,
|
|
|
|
const css::uno::Any& VRuler,
|
|
|
|
const css::uno::Any& Highlight )
|
|
|
|
{
|
|
|
|
SAL_INFO("sw.vba", "WordBasic.ToolsOptionsView("
|
2019-01-22 15:22:13 +00:00
|
|
|
"DraftFont:=" << DraftFont
|
2019-01-22 13:59:18 +02:00
|
|
|
<< ", WrapToWindow:=" << WrapToWindow
|
|
|
|
<< ", PicturePlaceHolders:=" << PicturePlaceHolders
|
|
|
|
<< ", FieldCodes:=" << FieldCodes
|
|
|
|
<< ", BookMarks:=" << BookMarks
|
|
|
|
<< ", FieldShading:=" << FieldShading
|
|
|
|
<< ", StatusBar:=" << StatusBar
|
|
|
|
<< ", HScroll:=" << HScroll
|
|
|
|
<< ", VScroll:=" << VScroll
|
|
|
|
<< ", StyleAreaWidth:=" << StyleAreaWidth
|
|
|
|
<< ", Tabs:=" << Tabs
|
|
|
|
<< ", Spaces:=" << Spaces
|
|
|
|
<< ", Paras:=" << Paras
|
|
|
|
<< ", Hyphens:=" << Hyphens
|
|
|
|
<< ", Hidden:=" << Hidden
|
|
|
|
<< ", ShowAll:=" << ShowAll
|
|
|
|
<< ", Drawings:=" << Drawings
|
|
|
|
<< ", Anchors:=" << Anchors
|
|
|
|
<< ", TextBoundaries:=" << TextBoundaries
|
|
|
|
<< ", VRuler:=" << VRuler
|
|
|
|
<< ", Highlight:=" << Highlight
|
|
|
|
<< ")");
|
2019-01-18 16:59:51 +02:00
|
|
|
}
|
|
|
|
|
2018-06-12 16:20:57 +03:00
|
|
|
OUString SAL_CALL
|
|
|
|
SwWordBasic::WindowName()
|
|
|
|
{
|
|
|
|
return mpApp->getActiveSwVbaWindow()->getCaption();
|
|
|
|
}
|
|
|
|
|
2018-06-12 17:58:44 +03:00
|
|
|
sal_Bool SAL_CALL
|
|
|
|
SwWordBasic::ExistingBookmark( const OUString& Name )
|
|
|
|
{
|
|
|
|
uno::Reference< word::XBookmarks > xBookmarks( mpApp->getActiveDocument()->Bookmarks( uno::Any() ), uno::UNO_QUERY );
|
|
|
|
return xBookmarks.is() && xBookmarks->Exists( Name );
|
|
|
|
}
|
|
|
|
|
2018-06-12 20:01:41 +03:00
|
|
|
void SAL_CALL
|
|
|
|
SwWordBasic::MailMergeOpenDataSource( const OUString& Name, const css::uno::Any& Format,
|
|
|
|
const css::uno::Any& ConfirmConversions, const css::uno::Any& ReadOnly,
|
|
|
|
const css::uno::Any& LinkToSource, const css::uno::Any& AddToRecentFiles,
|
|
|
|
const css::uno::Any& PasswordDocument, const css::uno::Any& PasswordTemplate,
|
|
|
|
const css::uno::Any& Revert, const css::uno::Any& WritePasswordDocument,
|
|
|
|
const css::uno::Any& WritePasswordTemplate, const css::uno::Any& Connection,
|
|
|
|
const css::uno::Any& SQLStatement, const css::uno::Any& SQLStatement1,
|
|
|
|
const css::uno::Any& OpenExclusive, const css::uno::Any& SubType )
|
|
|
|
{
|
|
|
|
mpApp->getActiveDocument()->getMailMerge()->OpenDataSource( Name, Format, ConfirmConversions, ReadOnly,
|
|
|
|
LinkToSource, AddToRecentFiles,
|
|
|
|
PasswordDocument, PasswordTemplate,
|
|
|
|
Revert, WritePasswordDocument,
|
|
|
|
WritePasswordTemplate, Connection,
|
|
|
|
SQLStatement, SQLStatement1,
|
|
|
|
OpenExclusive, SubType );
|
|
|
|
}
|
|
|
|
|
2019-02-06 11:58:56 +02:00
|
|
|
sal_Int32 SAL_CALL
|
2019-02-07 12:04:49 +02:00
|
|
|
SwWordBasic::AppMaximize( const css::uno::Any& WindowName, const css::uno::Any& State )
|
2019-02-06 11:58:56 +02:00
|
|
|
{
|
|
|
|
SAL_INFO("sw.vba", "WordBasic.AppMaximize( WindowName:=" << WindowName << ", State:=" << State);
|
|
|
|
|
|
|
|
// FIXME: Implement if necessary
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-02-06 12:08:59 +02:00
|
|
|
sal_Int32 SAL_CALL
|
|
|
|
SwWordBasic::DocMaximize( const css::uno::Any& State )
|
|
|
|
{
|
|
|
|
SAL_INFO("sw.vba", "WordBasic.DocMaximize(State:=" << State << ")");
|
|
|
|
|
|
|
|
// FIXME: Implement if necessary
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-02-06 12:20:45 +02:00
|
|
|
void SAL_CALL
|
2019-02-07 11:55:51 +02:00
|
|
|
SwWordBasic::AppShow( const css::uno::Any& WindowName )
|
2019-02-06 12:20:45 +02:00
|
|
|
{
|
|
|
|
SAL_INFO("sw.vba", "WordBasic.AppShow(WindowName:=" << WindowName << ")");
|
|
|
|
|
|
|
|
// FIXME: Implement if necessary
|
|
|
|
}
|
|
|
|
|
2019-02-06 12:22:39 +02:00
|
|
|
sal_Int32 SAL_CALL
|
|
|
|
SwWordBasic::AppCount()
|
|
|
|
{
|
|
|
|
SAL_INFO("sw.vba", "WordBasic.AppCount()");
|
|
|
|
|
|
|
|
// FIXME: Implement if necessary. Return a random number for now.
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
|
2010-10-14 08:30:41 +02:00
|
|
|
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
|