summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-05-31A few SAL_INFO tweaksTor Lillqvist
Change-Id: I4a9c6341891bc80d8ab7648ed972d57739aa4f4a (cherry picked from commit b34d42129178731a841c52aac186f5d9f4fa817e)
2018-05-31First attempt at implementing CXTypeInfo::GetFuncDesc() and ReleaseFuncDesc()Tor Lillqvist
The returned information for the methods is fairly bogus, though. Not sure now (a few months after I wrote the code) whether this added functionality was actually needed, or whether I just added it for potential future need, and with the intent that it needs to be improved significantly then later if actually needed. Change-Id: Ifb132f494cdd7172b4b1d05cc26e2370ea595f41 (cherry picked from commit 27a1351122dbab79536870d7080307defbcae433)
2018-05-31Prepare to handle out (and inout) parameters to event callbacksTor Lillqvist
Change-Id: I47054c1df40d1058618b0fbd3fdb82fa93ca8836 (cherry picked from commit 2ee43cff5cf0e4125e7b2bbb7c763069c6aca95c)
2018-05-31Add Document.Close event generationTor Lillqvist
Use a similar idea as for the Application events. Use the SwDocShell to keep the XSinkCaller. Call the Close event from SwXTextDocument::close(). Change-Id: Ie873238c5a966fc859d45b59f424ae0e9f4fbfc7 Reviewed-on: https://gerrit.libreoffice.org/55110 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit 6c8c727ffd97e247f1ea43c1a47a55e6d5f68331)
2018-05-31Add one more #define _SILENCE_CXX17_CODECVT_HEADER_DEPRECATION_WARNING 1Tor Lillqvist
Change-Id: I228ae626532b3ae6f632701e71d3da182c496612 (cherry picked from commit 9673511526660ff23169456b2cce560d968107b3)
2018-05-31SwModule is a convenient (?) place for passing events to Automation clientsTor Lillqvist
Generate Application.DocumentChange and Application.Quit events. SfxHintId::DocChanged seems to correspond nicely enough to Application.DocumentChange. It is generated a bit eagerly, but as its documentation is fairly vague and no specific detailed information is passed in parameters anyway, it probably doesn't hurt if a client gets it a bit more often with LO than with some other product. Can now remove the FIXME-marked Quit event things in SwVbaApplication. Now need oovbaapi in many makefiles for them to compile. Change-Id: I4d0c5b93b584f198bcc854002eec7aaba7909ecc Reviewed-on: https://gerrit.libreoffice.org/55106 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com>
2018-05-31Remove leftover hardcoded check for SwVbaApplicationTor Lillqvist
Instead, be generic, check whether the objects implements ooo::vba::XConnectable. That's what we do in the IID_IConnectionPointContainer case, too. Change-Id: Ib499aa011775f79a2accaef64e19738bdb7ed143 Reviewed-on: https://gerrit.libreoffice.org/55109 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit 98630a6edf91183dbd8f1bdb02616889251927de)
2018-05-31Add ooo.vba.word.XDocumentOutgoingTor Lillqvist
Change-Id: I0243ee3e492d8445ebcc059293dcc4cb3c5c889b Reviewed-on: https://gerrit.libreoffice.org/55105 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit 20e6e0c507119a190adb3454da9eca44d470df1a)
2018-05-31Bin leftover misleading commentTor Lillqvist
Change-Id: I594258303469a1f5b9490b824fdc304a5a780784 (cherry picked from commit 9112d1835b4f974878e24342979bbf54968e4b70)
2018-05-31We want just one SwVbaGlobals and SwVbaApplication for all Automation clientsTor Lillqvist
I think. Anyway, if it turns out we do want one per client, easy to revert this. (And it isn't very common to have several Automation clients connected at the same time anyway, surely.) There will still additionally be one SwVbaGlobals (and SwVbaApplication) per open document with a StarBasic interpreter, though. I think. Change-Id: I5f7dbfd65b5decb152c1192298bc85dcf6027d64 Reviewed-on: https://gerrit.libreoffice.org/55094 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit 3f3b7b38df42695c934d6382659db1b79b236c28)
2018-05-31Work in progress related to invoking events in Automation clientsTor Lillqvist
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> (cherry picked from commit f7e0297b01f739e17f2f9517bf3d89baaee654ab)
2018-05-31Add a (dummy) ooo::vba::word::XApplication::ShowMe() implementationTor Lillqvist
Some customer VB6 code calls it. It doesn't seem to do anything interesting in Word either, so I don't feel that bad for it not doing anything in Writer. Change-Id: I81162fcdd0caa22b19760f8cb40266f7f571d8ce Reviewed-on: https://gerrit.libreoffice.org/55069 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit 4eb739592d0de1cb02a2604c45b60e9453b532b7)
2018-05-31Implement InterfaceOleWrapper::GetTypeInfoCount()Tor Lillqvist
It is just supposed to return 1, after all. And we do try to implement the GetTypeInfo(). (Sure, the testing I am doing that turned out to require GetTypeInfo() to work then immediately after this runs into much harder problems to solve, but that is another issue.) Change-Id: If7e0707d7b404d6a46b24e642c2146b3bfff03f0 Reviewed-on: https://gerrit.libreoffice.org/55070 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit 5afbfd215a108a6bd3b3a8379d789663e1022789)
2018-05-31Add Caption property to ooo::vba::XApplicationBaseTor Lillqvist
Implementation is just a dummy, though. At first I thought that it would work to get the XModel of the "current" document (as returned by getCurrentDocument()), and then get the XFrame of that, and then use the XFrame's getName() and setName(). But, it seems that getCurrentDocument() and what it calls is tightly coupled to StarBasic, and it doesn't do anything sane in the case of Automation clients. Change-Id: I74ded5114ecce06e72862f69d0c06d963e55fd75 Reviewed-on: https://gerrit.libreoffice.org/55064 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit 857a33404626f8df04882478d026969691624cbb)
2018-05-31Remove two unnecessary forward declarationsTor Lillqvist
Change-Id: I5bf56b6216835870b4beefd588f070a127835514 Reviewed-on: https://gerrit.libreoffice.org/55068 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit 64980d88fb75b8a34b1fce4ed1d0d64d0f2d5e09)
2018-05-31Fix typos in SAL_WARNs: The class is called CXTypeInfo, not CxTypeInfoTor Lillqvist
Change-Id: Iab17340f57cf8b116d2f058661dabd3a95fb61d2 (cherry picked from commit 8444ab9287ebb8029afe576f25d8ee9103f0e7c5)
2018-05-31Add CLSID for Writer.Application and LocalServer32 for thatTor Lillqvist
For Automation clients. Provided in extensions/source/ole/servprov.cxx for an instance of ooo.vba.word.Application. Change-Id: I277f461bf6206f3516b14fabe8b27dc4c06018b5 Reviewed-on: https://gerrit.libreoffice.org/55052 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit 4d9159fac836904b8cb4f3672291367b4c258173)
2018-05-31Handle <codecvt> deprecation issue with VS2017Tor Lillqvist
As VS2017 so eloquently puts it, "Warning STL4017: std::wbuffer_convert, std::wstring_convert, and the <codecvt> header (containing std::codecvt_mode, std::codecvt_utf8, std::codecvt_utf16, and std::codecvt_utf8_utf16) are deprecated in C++17. (The std::codecvt class template is NOT deprecated.) The C++ Standard doesn't provide equivalent non-deprecated fu tml_ nctionality; consider using MultiByteToWideChar() and WideCharToMultiByte() from <Windows.h> instead. You can define _SILENCE_CXX17_CODECVT_HEADER_DEPRECATION_WARNING or _SILENCE_ALL_CXX17_DEPRECATION_WARNINGS to acknowledge that you have received this warning." So VS2017 actually recommends using platform-specific API instead of standard C++ API that is or will be deprecated but has no standard replacement. Insane. Note that it is not enough to define that _SILENCE_CXX17_CODECVT_HEADER_DEPRECATION_WARNING just right where you are including <codecvt> because "for all of the warning suppression macros, you must define them before any C++ Standard Library header has been included (both <vector> etc. and <cstdlib> etc.)" as mentioned on https://blogs.msdn.microsoft.com/vcblog/2017/12/08/c17-feature-removals-and-deprecations/ So define it in the single file that includes windowsdebugoutput.hxx for now. Change-Id: Iecd9702502ce3b33013d6799c618d6b98d803c3e (cherry picked from commit 3cce079c9307315f18b6f49f1de58f52e956e0d6)
2018-05-31Add code to VbaApplicationBase::Quit() for the Automation client caseTor Lillqvist
Change-Id: I4354adf5353bdfb0b080b24a5c49e3d22539eb23 Reviewed-on: https://gerrit.libreoffice.org/55051 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit d7f69b1cb4dbdd39970d56d0c340d7abb92fbdc1)
2018-05-31Whitespace fixTor Lillqvist
Change-Id: Ife4040b181f0688d67de4a2a36e2d2f810e4fce5 (cherry picked from commit 925fe6609f39098ee69d94087f11e593a60476a1)
2018-05-31Factor out AsyncQuitHandler to be usable elsewhere, tooTor Lillqvist
Or do we already have the corresponding functionality somewhere, and SbModule::Run() could be changed to use that instead? Change-Id: I6f45d4a023f9f9d9a24ab6934117a712ccbe75e2 Reviewed-on: https://gerrit.libreoffice.org/55048 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit cac718bfe606c363fa4538db8c6d21f28f139f58)
2018-05-31We might need to handle form controls as properties for OLE clients after allTor Lillqvist
Start a bit of work on that. Change-Id: I7775f9598a81d64e9716996027b01f7f8e29745b Reviewed-on: https://gerrit.libreoffice.org/55043 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit 2b6a84c8f699c9da115ce297ad19b8f480ab608f)
2018-05-31Hack to make properties work better from Automation clientsTor Lillqvist
There were a couple of problems apparent at this stage when using the ooovbaapi things from a test Automation client (written in VBScript, to be precise). Accessing for instance the ActiveDocument property of an ooo::vba::word::XGlobals instance worked fine. But properties of other objects, like instances of ooo::vba::word::XDocument, did not work. When attempting to access any property of an ooo::vba::word::XDocument, the code ended up calling the hasProperty() of SwVbaDocuemnt. That function is for checking a totally different kind of "properties", namely named form controls. Why form controls are con-fused with oovbaapi properties I don't know. Maybe it is intentional and as expected when using the oovbaapi from the built-in Basic interpreter in LibreOffice. Or then just an accident in history. Still, surely it can't be changed, that would break Basic scripts embedded in existing ODF documents. Anyway, from an OLE Automation client, for instance when asking for the Content property of an ooo::vba::word::XDocument object, we definitely don't want any form control that happens to have the name "Content". We want an object with two integer properties, Start and End. Make this work by always creating an invocation factory instead of using the object itself. Pass the invocation factory's createInstanceWithArguments() function an extra argument indicating this is the case of use from OLE Automation. In the Invocation_Impl class in the stoc module, when this extra argument is noticed, set a new mbFromOLE flag. Modify the behaviour slightly when that is true. I am not at all sure that this will work in all cases, but let's see, at least for simple tests so far it had the intended effect. Another issue was that looking up these properties was case sensitive. This is wrong at least from languages like VBScript. Use the mbFromOLE flag also to affect the case sensitivity behaviour. Maybe I should simply make sure that _xDirect is null in the Automation case? _Direct (a reference to an XInvocation) being non-null probably means that we are using the document interface's own implementation of XInvocation, which is probably always wrong in the OLE Automation case. (Just see the SwVbaDocument implementations of hasProperty() and invoke(), for instance.) Change-Id: I2fd174f69f430893aef538cc9bf2a99d1c86b567 Reviewed-on: https://gerrit.libreoffice.org/55023 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit 7873bba6c1e5de580ef28d0ecf68d154dd57e726)
2018-05-31Provide also an ooo.vba.word.XApplication objectTor Lillqvist
Create the objects on offer to Automation clients lazily It would be silly to create the ooo.vba.word.XApplication in every LibreOffice instance, even if no Writer functionality was going to be used at all in that process. I did not have to do what the old FIXME said, "make Application a proper service", whatever that means. Change-Id: I02a0ceb6290012b4bb6afacadc03871feaf57406 Reviewed-on: https://gerrit.libreoffice.org/55005 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit 0667df70dc749ae50ce29713308f14d624f2a683)
2018-05-31Handle DISPID_NEWENUMTor Lillqvist
We get that when an Automation client wants to enumerate an object that is a collection. We need to create an IEnumVARIANT object and return it (as an IUnknown). I wasted days on trying to implement this IEnumVARIANT object using the same twisty maze of helpers, wrappers, UNO conversion utilities, etc as used for the other stuff here. The other objects have both UNO and OLE personalities. Could not figure out how to do it. Then I decided to just do it brute force, following some sample code, not bothering with any UNO personality at all for the IEnumVARIANT thing, and it worked right away. Change-Id: I6a175ea80b75d48d2f0b793f143f3a84715522c1 Reviewed-on: https://gerrit.libreoffice.org/54994 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit 52eb78c8d2c9954733d95326922462a820d9f0dd)
2018-05-31Bin some ASCII graphicsTor Lillqvist
Change-Id: I53ef86a997f4ae1c0ad84bb381327cba3143dd4c (cherry picked from commit 3ebaf1a9fb28be42358f5460e5ab7322d4f1dee8)
2018-05-31Add one line of hopefully correctly understood explanationTor Lillqvist
Change-Id: Ib22583a45c03a4b7c3b4ff73e9d28f47ab31bc4f (cherry picked from commit 9bbb71d4a003d00a3361f337b3f96d4a19a35562)
2018-05-31Bin noise part of commentTor Lillqvist
Our convention is to just have the name of the abstract base class in a comment before the declaration of the concrete overrides of its abstract member functions. No need to say "Abstract struct" there. Change-Id: I2b9bdf0555af5280771370a6df56fd4c8623661a (cherry picked from commit 8d6f684067092a32e45a75e9290d7d19a753f726)
2018-05-31IClassFactoryWrapper can go away nowTor Lillqvist
Change-Id: I7633648dc0398d2c1b6f04e6db9b18638a7451f5 Reviewed-on: https://gerrit.libreoffice.org/54781 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com>
2018-05-31Bin dead codeTor Lillqvist
OleServer::provideService() was not called anywhere. That means the ProviderOleWrapper class is unused, too. Which is good, as it seemed to largely be identical to OneInstanceOleWrapper anyway. Change-Id: If8782d56ed1ec1bb173cfc18be585be4c331f335 Reviewed-on: https://gerrit.libreoffice.org/54647 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit 0f2157cb1513371829d7f8c415324cffed28c377)
2018-05-31In fact it's simpler to not have m_guid fields in these two classes at allTor Lillqvist
We can just pass the GUID as parameter to the single member function registerClass() that needs it. This perhaps means the same class can be used in more cases, also for objects/classes that aren't going to be registered and don't need any GUID. Change-Id: I28703190c52b14236c6f613dd4acbe359c075f5c Reviewed-on: https://gerrit.libreoffice.org/54622 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit 17ad73232ff604329e6532817570cb40342857e8)
2018-05-31These fields can be constTor Lillqvist
Change-Id: I379770f93799668e44beab03fb64ceddffabe85a Reviewed-on: https://gerrit.libreoffice.org/49326 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit 72fefd7ab6fd551effcf821e4e257df2756bece1)
2018-05-31There is nothing called o2u_anyToVariantTor Lillqvist
Change-Id: I7118843fde87a2d587f0e4ec99d146c379da618e (cherry picked from commit 79a6290969d5c1feab56158b6cf0dd0a4b52d53e)
2018-05-31These fields can be constTor Lillqvist
Change-Id: I103f06b9c7f14ac7eff9911ab5bebc4c98e7d41f Reviewed-on: https://gerrit.libreoffice.org/54614 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit 7c7b3c70e1def37ee707827e75d0afa00b0b3619)
2018-05-31No need for this #pragma onceTor Lillqvist
Change-Id: I219226060ebf4b8b86c8f0487fc679f22f73812a Reviewed-on: https://gerrit.libreoffice.org/54468 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit 7a2b7693452dec3d30778301ae3a294bfaed344b)
2018-05-31We only support MSVC anyway for our Windows-specific codeTor Lillqvist
Change-Id: I68dfd0832747c7c319e40ee28a4461623e95102f Reviewed-on: https://gerrit.libreoffice.org/54482 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit 69322f8b539cd9f98e0ee5f9afc7c3df0d897493)
2018-05-31Don't ever attempt to initialise a std::locale with a UTF-8 locale on WindowsTor Lillqvist
As I said in 2ff121f298e64ff204621220622472fe697d599d, passing a POSIX-style locale name to the std::locale constructor on Windows is decidedly odd, and apparently boost adds insult to injury by even really attempting to use a UTF-8 one if that is what our code thinks it wants. Or something. This commit avoids the ton of "warn:unotools.i18n:7996:3544:unotools/source/i18n/resmgr.cxx:123: CRT Report Hook: ASSERT: f:\dd\vctools\crt\crtw32\stdcpp\xmbtowc.c(89) : Assertion failed: ploc->_Mbcurmax == 1 || ploc->_Mbcurmax == 2" we otherwise get when built with --enable-dbgutil and a current VS2015 (or 2017?). Change-Id: I3a774dff7b12d9960f553c9f242e0463c6d13d5d Reviewed-on: https://gerrit.libreoffice.org/54444 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2018-05-31Drop _Impl class name suffix where pointlessTor Lillqvist
I.e. where there is no other LibreOffice, or system, or 3rd-party library thing with just the un-suffixed name that they would be a pimpl of, etc. Why bother calling something InterfaceOleWrapper_Impl when there is nothing that would be called InterfaceOleWrapper? It just makes the code seem more complicated and harder to read. An "implementation" of something is what everything that is not fully abstract *is*. We don't suffix the name of every non-abstract class with _Impl elsewhere either. Also drop two unused structs. Change-Id: I2755e6da78d8e4ded5291688dc90510b5f8b498b Reviewed-on: https://gerrit.libreoffice.org/54411 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit a48f22db7dd1bfeff62007a655566ddaad79aebd)
2018-05-31Avoid gengal hanging in an --enable-dbgutil build on WindowsTor Lillqvist
With a newer C++ debug runtime (in an --enable-dbgutil build), passing an invalid locale name causes an attempt to display an error dialog. Which does not even show up, at least for me, but instead the process (gengal, at least) just hangs. Which is far from ideal. Passing a POSIX-style locale name to the std::locale constructor on Windows is a bit odd, but apparently in the normal C++ runtime it "just" causes an exception to be thrown, that boost catches (see the loadable(std::string name) in boost's libs\locale\src\std\std_backend.cpp), and then instead uses the Windows style locale name it knows how to construct. (Why it even tries the POSIX style name on Windows I can't understand.) Actually it isn't just the locale name part "en_US" of a locale like "en_US.UTF-8" that is problematic, but also the encoding part, "UTF-8". The Microsoft C/C++ library does not support UTF-8 locales. The error message that our own report hook catches says: "f:\dd\vctools\crt\crtw32\stdcpp\xmbtowc.c(89) : Assertion failed: ploc->_Mbcurmax == 1 || ploc->_Mbcurmax == 2". Clearly in a UTF-8 locale (perhaps one that boost internally constructs?) the maximum bytes per character will be more than 2. With a debug C++ runtime, we need to avoid the error dialog, and just ignore the error. So we install an own CRT error report hook that ignores the error for the duration of the locale construcion. Change-Id: Ia2ca994f03d1ce94ce7e9d7607f204c320ab8f2d Reviewed-on: https://gerrit.libreoffice.org/54110 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 2ff121f298e64ff204621220622472fe697d599d)
2018-05-31Mask away the extra bits from vt before switchingTor Lillqvist
Change-Id: Ie05fd6c9e6b47c4aae9410833aae9bd5ba23ff40 (cherry picked from commit ea23987d9a1033f4fd4b0d33bc7c7bedea60a91e)
2018-05-31Also for SDK 10.0.17134 the winsdklibsubdir needs to have a .0 tacked onTor Lillqvist
Also remove questionable old "Hack needed at least by tml". Change-Id: I478358ea114cee2f8a181b98cb3433447b3ed560 Reviewed-on: https://gerrit.libreoffice.org/54081 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit fc00041df85fd508d1fc34658d4c9ceeb10084b1)
2018-05-29tdf#38225: update API name when renaming using a base class refMike Kaganski
... but don't update it in case it's a predefined API name Change-Id: I20075a4e085bdeab8374860c16e7eb2a72772c33 Reviewed-on: https://gerrit.libreoffice.org/54879 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/54985 Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-05-29tdf#117817: Update Mail Merge controls after wizard completesMike Kaganski
Otherwise they may stay disabled until cursor position changes. Change-Id: If734bbd4793b3b01c64601d68126d5752f5aba0c Reviewed-on: https://gerrit.libreoffice.org/54841 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit f304ae0ca4738fa3605587146224ee8972a894f3) Reviewed-on: https://gerrit.libreoffice.org/54964
2018-05-28tdf#115386: Show Mail Merge toolbar for new labelsMike Kaganski
Change-Id: I26ec6c7fdfa5b6f6f818927fd9ede00184dc5e8c Reviewed-on: https://gerrit.libreoffice.org/54813 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/54961 Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-05-28tdf#35798: use separate paragraphs for Label elementsMike Kaganski
Since commit db04be037b611e296ef9f2542322c52ed82d7a2b, empty Database fields are hidden. But since Labels wizard generates a single paragraph with line breaks for the label's text, the hiding feature cannot be used efficiently. Let the individual lines be in individual paragraphs. Change-Id: I27430d54baea88461c2ea9de38baa95d6b7e9e62 Reviewed-on: https://gerrit.libreoffice.org/54800 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 2f11ce0670749b9da20dfb29269b176cb09fb01e) Reviewed-on: https://gerrit.libreoffice.org/54959 Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-05-28tdf#115386: Show Mail Merge toolbar for documents with MM fieldsMike Kaganski
Change-Id: I357a30d72c5ac4af8c64b82b4cc61c3bd606940a Reviewed-on: https://gerrit.libreoffice.org/54612 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/54957 Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-05-28tdf#35798: Hide empty Database fields' paragraphs (+ compat option)Mike Kaganski
With this change, Database fields that expand to empty values behave as if they are "Hidden Paragraph" fields. A compatibility option to enable this behaviour is added. The option is enabled by default, and for any non-native documents (for compatibility with other office suites). For existing (F)ODT documents, the option is disabled for those documents that don't have this setting set, to keep the layout of legacy documents. Change-Id: Ic5e8cb15a3a7d1a765a984eef4b0d97666df7dfd Reviewed-on: https://gerrit.libreoffice.org/54552 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/54929 Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-05-23lok: sc: tunneling the ascii import dialog on paste actionMarco Cecchetti
I needed to modify CreateScImportAsciiDlg signature so that we are able to pass a pointer to a dialog parent window to ScImportAsciiDlg. Moreover, I needed to perform the execution of the ScImportAsciiDlg dialog in ScViewFunc::PasteDataFormat asynchronously, both for lok and desktop case. In order to achieve this result it has been needed to modify the lifespan of some objects previously local to PasteDataFormat. Since PasteDataFormat returns a boolean, I took care to check how this return value is used. I found out 2 cases: 1) in ScViewFunc::PasteFromSystem where it is used for popping up an error dialog box, informing the user in the case that the paste operation is failed; 2) in ScGridWindow::ExecuteDrop where it is used for informing the system window manager of the success or fail of the drag and drop action. The first case is now handled by a lamba invoked soon after the dialog execution ended. The second case is more tricky: I handle it as the paste operation is always successful, hoping it doesn't do any real difference since the return value is used not by LO but by the system window manager (e.g. gtk). The asynchronous call and the behaviors described above occur only when the paste operation involves some kind of simple text, in all other cases nothing is changed. Change-Id: Id4f96180a9336f665a22a2441ea490af993431b0 Reviewed-on: https://gerrit.libreoffice.org/53575 Reviewed-by: Jan Holesovsky <kendy@collabora.com> Tested-by: Jan Holesovsky <kendy@collabora.com>
2018-05-23Open template read-onlyTor Lillqvist
Otherwise when creating a new docuent based on a template, the template document file is opened read-write eventually (after first being opened read-only five times, and closed again...). Sure, LibreOffice probably doesn't actually write anything to it, but still, just opening read-write when you are going to only read is silly. Stack trace from the read-write opening: #0 0x00007f063dea0047 in openFilePath(char const*, void**, unsigned int, unsigned int) (cpFilePath=0x7ffeacc7d610 "/ssd1/lo/fedora/instdir/share/template/common/officorr/Modern_business_letter_sans_serif.ott", pHandle=0x342af78, uFlags=3, mode=438) at /ssd1/lo/fedora/sal/osl/unx/file.cxx:1039 #1 0x00007f063dea027b in openFile(_rtl_uString*, void**, unsigned int, unsigned int) (ustrFileURL=0x33ff7e0, pHandle=0x342af78, uFlags=3, mode=4294967295) at /ssd1/lo/fedora/sal/osl/unx/file.cxx:1071 #2 0x00007f063dea01a8 in osl_openFile(rtl_uString*, oslFileHandle*, sal_uInt32) (ustrFileURL=0x33ff7e0, pHandle=0x342af78, uFlags=3) at /ssd1/lo/fedora/sal/osl/unx/file.cxx:1050 #3 0x00007f060aec5f1a in osl::File::open(unsigned int) (this=0x342af78, uFlags=3) at /ssd1/lo/fedora/include/osl/file.hxx:975 #4 0x00007f060aec5a8f in fileaccess::ReconnectingFile::open(unsigned int) (this=0x342af78, uFlags=3) at /ssd1/lo/fedora/ucb/source/ucp/file/filrec.cxx:50 #5 0x00007f060aee0324 in fileaccess::XStream_impl::XStream_impl(rtl::OUString const&, bool) (this=0x342af10, aUncPath="file:///ssd1/lo/fedora/instdir/share/template/common/officorr/Modern_business_letter_sans_serif.ott", bLock=true) at /ssd1/lo/fedora/ucb/source/ucp/file/filstr.cxx:58 #6 0x00007f060aee8bac in fileaccess::TaskManager::open_rw(int, rtl::OUString const&, bool) (this=0x2c5ded0, CommandId=231, aUnqPath="file:///ssd1/lo/fedora/instdir/share/template/common/officorr/Modern_business_letter_sans_serif.ott", bLock=true) at /ssd1/lo/fedora/ucb/source/ucp/file/filtask.cxx:766 #7 0x00007f060ae9ba9b in fileaccess::BaseContent::open(int, com::sun::star::ucb::OpenCommandArgument2 const&) (this=0x3428810, nMyCommandIdentifier=231, aCommandArgument=...) at /ssd1/lo/fedora/ucb/source/ucp/file/bc.cxx:937 #8 0x00007f060ae99dfa in fileaccess::BaseContent::execute(com::sun::star::ucb::Command const&, int, com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment> const&) (this=0x3428810, aCommand=..., CommandId=231, Environment=uno::Reference to (ucbhelper::CommandEnvironment *) 0x341d088) at /ssd1/lo/fedora/ucb/source/ucp/file/bc.cxx:331 #9 0x00007f060ae9d001 in non-virtual thunk to fileaccess::BaseContent::execute(com::sun::star::ucb::Command const&, int, com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment> const&) () at /ssd1/lo/fedora/instdir/program/../program/libucpfile1.so #10 0x00007f06337395da in ucbhelper::Content_Impl::executeCommand(com::sun::star::ucb::Command const&) (this=0x3427f70, rCommand=...) at /ssd1/lo/fedora/ucbhelper/source/client/content.cxx:1258 #11 0x00007f063373be55 in ucbhelper::Content::openWriteableStream() (this=0x7ffeacc7f030) at /ssd1/lo/fedora/ucbhelper/source/client/content.cxx:751 #12 0x00007f06333f56c0 in utl::MediaDescriptor::impl_openStreamWithURL(rtl::OUString const&, bool) (this=0x7ffeacc801d0, sURL="file:///ssd1/lo/fedora/instdir/share/template/common/officorr/Modern_business_letter_sans_serif.ott", bLockFile=true) at /ssd1/lo/fedora/unotools/source/misc/mediadescriptor.cxx:666 #13 0x00007f06333f3e01 in utl::MediaDescriptor::impl_addInputStream(bool) (this=0x7ffeacc801d0, bLockFile=true) at /ssd1/lo/fedora/unotools/source/misc/mediadescriptor.cxx:521 #14 0x00007f06333f4051 in utl::MediaDescriptor::addInputStreamOwnLock() (this=0x7ffeacc801d0) at /ssd1/lo/fedora/unotools/source/misc/mediadescriptor.cxx:490 #15 0x00007f05b132f0bf in filter::config::TypeDetection::impl_openStream(utl::MediaDescriptor&) (this=0x33caa10, rDescriptor=...) at /ssd1/lo/fedora/filter/source/config/cache/typedetection.cxx:1127 #16 0x00007f05b132e9ac in filter::config::TypeDetection::impl_askDetectService(rtl::OUString const&, utl::MediaDescriptor&) (this=0x33caa10, sDetectService="com.sun.star.comp.filters.StorageFilterDetect", rDescriptor=...) at /ssd1/lo/fedora/filter/source/config/cache/typedetection.cxx:981 #17 0x00007f05b132b7a4 in filter::config::TypeDetection::impl_detectTypeFlatAndDeep(utl::MediaDescriptor&, std::__debug::vector<filter::config::FlatDetectionInfo, std::allocator<filter::config::FlatDetectionInfo> > const&, bool, std::__debug::vector<rtl::OUString, std::allocator<rtl::OUString> >&, rtl::OUString&) (this=0x33caa10, rDescriptor=..., lFlatTypes=std::__debug::vector of length 168, capacity 256 = {...}, bAllowDeep=true, rUsedDetectors=std::__debug::vector of length 1, capacity 1 = {...}, rLastChance="") at /ssd1/lo/fedora/filter/source/config/cache/typedetection.cxx:934 #18 0x00007f05b1329b7c in filter::config::TypeDetection::queryTypeByDescriptor(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>&, unsigned char) (this=0x33caa10, lDescriptor=uno::Sequence of length 6 = {...}, bAllowDeep=1 '\001') at /ssd1/lo/fedora/filter/source/config/cache/typedetection.cxx:429 #19 0x00007f05b132d321 in non-virtual thunk to filter::config::TypeDetection::queryTypeByDescriptor(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>&, unsigned char) () at /usr/bin/../lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/bits/stl_pair.h:331 #20 0x00007f060df5acdd in framework::LoadEnv::impl_detectTypeAndFilter() (this=0x7ffeacc80c48) at /ssd1/lo/fedora/framework/source/loadenv/loadenv.cxx:739 #21 0x00007f060df58796 in framework::LoadEnv::startLoading() (this=0x7ffeacc80c48) at /ssd1/lo/fedora/framework/source/loadenv/loadenv.cxx:357 #22 0x00007f060df57280 in framework::LoadEnv::loadComponentFromURL(com::sun::star::uno::Reference<com::sun::star::frame::XComponentLoader> const&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (xLoader=uno::Reference to (framework::Desktop *) 0x282bf98, xContext=uno::Reference to (cppu::ComponentContext *) 0x145b790, sURL="file:///ssd1/lo/fedora/instdir/share/template/common/officorr/Modern_business_letter_sans_serif.ott", sTarget="_default", nFlags=0, lArgs=uno::Sequence of length 4 = {...}) at /ssd1/lo/fedora/framework/source/loadenv/loadenv.cxx:160 #23 0x00007f060dfaef40 in framework::Desktop::loadComponentFromURL(rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (this=0x282bf20, sURL="file:///ssd1/lo/fedora/instdir/share/template/common/officorr/Modern_business_letter_sans_serif.ott", sTargetFrameName="_default", nSearchFlags=0, lArguments=uno::Sequence of length 4 = {...}) at /ssd1/lo/fedora/framework/source/services/desktop.cxx:617 #24 0x00007f060dfaeffb in non-virtual thunk to framework::Desktop::loadComponentFromURL(rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) () at /ssd1/lo/fedora/include/rtl/stringutils.hxx:170 #25 0x00007f06381ee762 in SfxTemplateManagerDlg::OpenTemplateHdl(ThumbnailViewItem*) (this=0x310e160, pItem=0x33925d0) at /ssd1/lo/fedora/sfx2/source/doc/templatedlg.cxx:690 Change-Id: Iaa5cc2bd4c80bc239b8f1bf7ed8aa62d89151d62 (cherry picked from commit e439816281f9fe24c7332b5f1e16df845f5213f2) Reviewed-on: https://gerrit.libreoffice.org/54686 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> (cherry picked from commit 30bdedc49f7007ce0305d013ac89c910c6cb1ae4)
2018-05-23tdf#104893 vcl opengl: fix assert failure when starting chart editingMiklos Vajna
OpenGLContext::prepareForYield() assumed that in case we have a current context, then it's the last one, but that's not the case for chart windows since commit 78b100ec9cb0db2f7b33ece5ad3287a67a37246f (only init the OpenGL context if we need it, 2016-06-07), which creates an OpenGLContext instance (which is then the last one in the context list) but explicitly doesn't initialize it (so that it would become the current one). Fix the problem by resetting not the last but the last current context. (cherry picked from commit 2a6171ed6fb85b3419dcf5cf1346cf1eec447987) Change-Id: Ie0e96927473290590cd6333e5cdcb7daa009431b Reviewed-on: https://gerrit.libreoffice.org/54516 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl> (cherry picked from commit 014a573a05bc69e0883a9e5fccdc7bed72b0a62e)
generated by cgit (git 2.34.1) at 2024-07-13 14:26:50 +0000