summaryrefslogtreecommitdiff
path: root/oovbaapi
AgeCommit message (Collapse)Author
2021-04-09[API-CHANGE] tdf#141543 VBA Range.Formula Range.FormulaR1C1 non-localizedEike Rathke
The VBA compatibility Range.Formula and Range.FormulaR1C1 properties wrongly used localized formula expressions as if they were Range.FormulaLocal and Range.FormulaR1C1Local. That worked in English UI and locales, but not in translated UI or with locale dependent different separators, imported Excel documents using these properties failed there. Instead, use English formula expressions and separators, and additionally implement Range.FormulaLocal and Range.FormulaR1C1Local for localized formula expressions. See https://docs.microsoft.com/en-us/office/vba/api/excel.range.formula https://docs.microsoft.com/en-us/office/vba/api/excel.range.formular1c1 https://docs.microsoft.com/en-us/office/vba/api/excel.range.formulalocal https://docs.microsoft.com/en-us/office/vba/api/excel.range.formular1c1local Unfortunately this change means for macros created in LibreOffice that relied on the erroneous beaviour in a localized environment those macros will cease to work, the remedy in these cases is to replace setting Formula and FormulaR1C1 attributes with FormulaLocal and FormulaR1C1Local instead. Obtaining formulas never worked reliably unless the document's native grammar was very similar to the API grammar (English UI function names, English locale and separators, address convention). For this to work a prerequisite is commit d0b4719ca3d4608bcb7431dbeb097146dd5a5127 CommitDate: Wed Apr 7 02:22:54 2021 +0200 Related: tdf#128334 Make VBA Range getFormula(R1C1) work not only by accident Change-Id: Ifce9ac7557b6a3703d47ee81b57dd8246f3fc3ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113846 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2021-04-07Updated README.md files to represent current code / use Markdown formatHossein
Previously, all of the README files have been renamed to README.md and now, the contents of these files were changed to use Markdown format. Other than format inconsistency, some README.md files lacked information about modules, or were out of date. By using LibreOffice / OpenOffice wiki and other documentation websites, these files were updated. Now every README.md file has a title, and some description. The top-level README.md file is changed to add links to the modules. The result of processing the Markdown format README.md files can be seen at: https://docs.libreoffice.org/ Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2021-03-24Using .md extension/Markdown syntax for modules READMEHossein
Renaming all README files for all top level modules to README.md, applying no content change at this stage to be able to track history of the files. These files should be edited to use correct Markdown syntax later. Change-Id: I542fa3f3d32072156f16eaad2211a397cc212665 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112977 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2020-09-01Fix typo in codeAndrea Gelmini
It passed "make check" on Linux Change-Id: Ibaaa3bbce3f2d502073803035aaacdad07bb170c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101810 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-11-26Fix typoAndrea Gelmini
Change-Id: Iee87dbb1a2e02891728a0aad2361fce60a479433 Reviewed-on: https://gerrit.libreoffice.org/83821 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-11-26Add ooo.vba.word.XDocument.Close() method and implementTor Lillqvist
Will be needed in COLEAT. And seems like a fairly obviously missing API otherwise, too. Change-Id: I990c605a7e3f9cff3b72f20a626477d010da9852 Reviewed-on: https://gerrit.libreoffice.org/81369 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit b0b0788ba040be2bf42aa19313759ba9f4811d38) Reviewed-on: https://gerrit.libreoffice.org/83660 (cherry picked from commit 1562900446a99623a30fa9e719322a8c24132f9d)
2019-11-26Add note that SwVbaDocuments::Close() does nothingTor Lillqvist
Change-Id: Ibf4d175b4b4a0b9f168401e52af6b0459aacd046 Reviewed-on: https://gerrit.libreoffice.org/81368 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com> (cherry picked from commit 61a656cb9c7db1863e56d1183cb82c7e8be63cc5) (cherry picked from commit 5c5034a6d5d411fedf1fb00e736c55b7bdd6f840)
2019-05-23Add ooo.vba.word.XDocument.SavePreviewPngAs() and implementTor Lillqvist
This is for COLEAT's internal use. Change-Id: If1ac2a5b251129e4431d3c0bde82529d6bdc7ccc Reviewed-on: https://gerrit.libreoffice.org/72809 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2019-04-19Add XWordBasic.FileSaveAs() and implementTor Lillqvist
Factor out the setFilterPropsFromFormat() also used by SwVbaDocument::SaveAs2000() to a header file of its own. Change-Id: I4bc9e1e420719a115036beb7e82a4ac3feac05f0 Reviewed-on: https://gerrit.libreoffice.org/70980 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2019-04-19Change XWordBasic methods to return anyTor Lillqvist
Possibly this is more in line with what callers expect. Change-Id: Ie84b05a0bdb5ef1cb3e1f9fb7df6772831ff4980 Reviewed-on: https://gerrit.libreoffice.org/70975 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2019-04-01Add Rows() method to ooo.vba.excel.XApplicationTor Lillqvist
Change-Id: I7e1d83539153eede300b2b24f2fa6796859d299c
2019-03-26Add SaveAs2000() and SaveAs() to ooo.vba.word.XDocument and implementTor Lillqvist
Change-Id: If7e45e2f791a7806e6cf8e7fc9693e19e87d2dbb
2019-02-07The WindowName param to WordBasic.AppMaximize() is optional and must be an AnyTor Lillqvist
Change-Id: I52d75427fe30945293f347e3f49d21bc2016edae
2019-02-07The parameter to WordBasic.AppShow() is optional and thus has to be an AnyTor Lillqvist
Change-Id: I134101d1be5922051e34352331a49f5706030ff2
2019-02-06Add a dummy implementation of WordBasic.AppCount()Tor Lillqvist
Change-Id: Ia9e78c331d2cb711653ee3e64597ebf2824e0eeb
2019-02-06Add a dummy implementation of WordBasic.AppShow()Tor Lillqvist
Change-Id: I14379c5732c1921b8f52293045d01acf99e0b840
2019-02-06Add a dummy implementation of WordBasic.DocMaximize()Tor Lillqvist
Change-Id: I972f9446560cc8ac51031dbc36fc05d438d150e7
2019-02-06Add a dummy implementation of WordBasic.AppMaximize()Tor Lillqvist
Change-Id: I4606e5a3717c3717d105dd2e63c9fd7d2e1abf83
2019-01-24Add WordBasic.FileClose()Tor Lillqvist
Change-Id: Ifc48e5fbcc212f0e80cf6877e2781910e38e5e54
2019-01-22Found documentation for WordBasic.ToolsOptionsView()Tor Lillqvist
Change-Id: Ic049f78fddcaabafbe6be18b92a87b56352c1a4c
2019-01-21Add a couple of known parameters to WordBasic.ToolsOptionsViewTor Lillqvist
Change-Id: Ifd472f4ca79ab97a1d6d5c5007537375121f6f58
2019-01-21Add a (dummy) WordBasic.FileSave()Tor Lillqvist
Change-Id: I021d63c9d57f1e0435bcc5f97abc57bc39fece01
2019-01-21Add a dummy WordBasic.ToolsOptionsViewTor Lillqvist
Does nothing. Needed for customer application to proceed. Once we are further along in getting it to work, we can investigate what the parameters passed to this ToolsOptionsView method actually are. (This WordBasic thing is something that has been deprecated since last century, I suspect, so no wonder it is hard to find authoritative documentation on it.) Change-Id: I62a6d6d9abb9364afca110570fa341a2375a77a6
2019-01-21Add Documents.OpenOld() method and Application.CustomizationContext propertyTor Lillqvist
OpenOld() just forwards to the regular Open(), passing empty extra parameters. CustomizationContext is fully dummy for now. Change-Id: I167494700853768d971fe16afea35e90a647a00e
2018-09-17oovbaapi: hack Excel / OptionButton compatibility into Button for now.Michael Meeks
Change-Id: I22d2d545a6201cbb89d430c65f66e0fea8794d83 Reviewed-on: https://gerrit.libreoffice.org/60541 Reviewed-by: Michael Meeks <michael.meeks@collabora.com> Tested-by: Michael Meeks <michael.meeks@collabora.com>
2018-06-13Add a MailMerge class and object to the Writer VBA APITor Lillqvist
Just a dummy implementation so far. Needed because customer Automation client software seems to access it (through the very obsolete WordBasic API, even). It remains to be seen whether any actual mail merge functionality is needed. Change-Id: I40419da544f61173e4bcf759b887997c7f233b02 Reviewed-on: https://gerrit.libreoffice.org/55727 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2018-06-12Add ExistingBookmark() to WordBasicTor Lillqvist
Change-Id: I8f433b1ae5cc23aaa08935e87fca7674064ce881 Reviewed-on: https://gerrit.libreoffice.org/55706 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2018-06-12Add ooo.vba.word.XWordBasic.WindowName() methodTor Lillqvist
Change-Id: I0ff24c3bc331d55212855d79060eaa6f8f3dc013 Reviewed-on: https://gerrit.libreoffice.org/55705 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2018-06-12Add ooo.vba.word.XWindow.Caption propertyTor Lillqvist
Change-Id: Ifa94b95d935975a87322afebfe604a4016f5a53f Reviewed-on: https://gerrit.libreoffice.org/55692 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com>
2018-06-07Add ooo.vba.word.Application.StatusBar property for debug output from clientTor Lillqvist
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-05-31Add WordBasic property and its FileOpen "command"Tor Lillqvist
Change-Id: I74aca823bb871040b15f35b92f961dfe48807843 Reviewed-on: https://gerrit.libreoffice.org/55136 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2018-05-31Implement NewWorkbook and WorkbookOpen Automation callbacks in CalcTor Lillqvist
Change-Id: I1ff31d692100695a706bf128c18c4e3ae8b55ce3
2018-05-31Add Author property to ooo::vba::excel::XWorkbook and implement itTor Lillqvist
Corresponds to the Author attribute of css::document::XDocumentProperties. I.e. the initial creator of the document. Change-Id: I07d3ce9dfb87900948d2bb7af14109b17546fb4c
2018-05-31Can simplify, our IDL compiler is more clever nowadaysTor Lillqvist
Change-Id: Ie62c47a0b60df5b7a7237cce981e850cbbe5aee9
2018-05-31Initial steps to make also Calc usable from Automation clientsTor Lillqvist
Largely parallel to what we do for Writer. Yes, there is a fair amount of duplicated code now for the outgoing ("sink") stuff in sw and sc, that should be factored out (to vbahelper, probably). Change-Id: I8df4a81c3b9043e8d6b0b206e3c04660205987c7
2018-05-31Add ooo.vba.excel.XApplicationOutgoingTor Lillqvist
Change-Id: I50ba5482742296609187e8b41bd3a2910c44ca4e
2018-05-31Can simplify, our IDL compiler is more clever nowadaysTor Lillqvist
Change-Id: Ia5f8c0fcc8d1eb9f6ec3db82b947a16ed3762d01
2018-05-31Add window geometry attributes, too, to ooo.vba.word.XApplicationTor Lillqvist
Like the other similar attributes and methods added lately, they just forward to the corresponding attributes of the "active window". Whether setting and retrieving such then actually does something useful or not I don't know. My main concern is that Automation and COM clients at least won't complain and abort because of unimplemented APIs. Change-Id: Ia8d22e3137d314268ac6771bb355e9f0686f52dc
2018-05-31Add Move() to ooo.vba.word.XApplicationTor Lillqvist
Change-Id: Ib230e730f68a30b82915ed6d7898bf1c02690b70
2018-05-31Add Resize() method to ooo.vba.word.XApplicationTor Lillqvist
Seems to be commonly called by 3rd-party Automation (and VB6) client code. Change-Id: I29ee5e7d95f3da2ffae0fac44151148be6e272ee
2018-05-31Add a WindowState attribute to ooo.vba.word.XApplication, tooTor Lillqvist
It seems to be something 3rd-party VB6 clients expect to be able to get and put. Change-Id: If5079da8ba99fde74b12b9590737d575f6636210
2018-05-31Can simplify, our IDL compiler is more clever nowadaysTor Lillqvist
Change-Id: I785c115ab7bcb7cfddc8e79bd5d31278f0c544dc
2018-05-31Add DocumentOpen and NewDocument to XApplicationOutgoing and emit suchTor Lillqvist
Change-Id: Ia2a0ade0af45f1ba99b0cfa860bd1986edcf272e
2018-05-31Add ooo::vba::word::XDocuments::OpenNoRepairDialog()Tor Lillqvist
Just call Open() with the same parameters. (Most of which are cheerfully ignored.) Change-Id: Ia9b980bf870bac04fab7e23843d29f66d5859037
2018-05-31Add ooo::vba::word::XApplicationOutgoing::DocumentBeforeClose() callbackTor Lillqvist
Change-Id: Iccdb7bc262b8f85caf7efb4407a1f00ff0cfb4a8
2018-05-31Prepare to handle out (and inout) parameters to event callbacksTor Lillqvist
Change-Id: I47054c1df40d1058618b0fbd3fdb82fa93ca8836
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>
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>
2018-05-30Work 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>
2018-05-30Add 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>
generated by cgit (git 2.34.1) at 2025-01-01 19:12:44 +0000