1. 13 Haz, 2018 1 kayıt (commit)
  2. 12 Haz, 2018 3 kayıt (commit)
  3. 07 Haz, 2018 1 kayıt (commit)
    • Tor Lillqvist's avatar
      Add ooo.vba.word.Application.StatusBar property for debug output from client · d9fc8b49
      Tor Lillqvist yazdı
      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
      Change-Id: I5bf1e776d6401adfc43a558a2d919bd675298e1a
      Reviewed-on: https://gerrit.libreoffice.org/55413Tested-by: 's avatarJenkins <ci@libreoffice.org>
      Reviewed-by: 's avatarTor Lillqvist <tml@collabora.com>
  4. 31 May, 2018 18 kayıt (commit)
  5. 30 May, 2018 4 kayıt (commit)
    • Tor Lillqvist's avatar
      Work in progress related to invoking events in Automation clients · f7e0297b
      Tor Lillqvist yazdı
      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
      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
      Change-Id: Ica03344010e374542f4aceff5ec032c78579f937
      Reviewed-on: https://gerrit.libreoffice.org/55093Tested-by: 's avatarJenkins <ci@libreoffice.org>
      Reviewed-by: 's avatarTor Lillqvist <tml@collabora.com>
    • Tor Lillqvist's avatar
      Add a (dummy) ooo::vba::word::XApplication::ShowMe() implementation · 4eb73959
      Tor Lillqvist yazdı
      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/55069Tested-by: 's avatarJenkins <ci@libreoffice.org>
      Reviewed-by: 's avatarTor Lillqvist <tml@collabora.com>
    • Tor Lillqvist's avatar
      Add Caption property to ooo::vba::XApplicationBase · 857a3340
      Tor Lillqvist yazdı
      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
      Change-Id: I74ded5114ecce06e72862f69d0c06d963e55fd75
      Reviewed-on: https://gerrit.libreoffice.org/55064Tested-by: 's avatarJenkins <ci@libreoffice.org>
      Reviewed-by: 's avatarTor Lillqvist <tml@collabora.com>
    • Tor Lillqvist's avatar
      Whitespace fix · 925fe660
      Tor Lillqvist yazdı
      Change-Id: Ife4040b181f0688d67de4a2a36e2d2f810e4fce5
  6. 12 Nis, 2018 1 kayıt (commit)
  7. 12 Şub, 2018 1 kayıt (commit)
  8. 13 Kas, 2017 1 kayıt (commit)
  9. 08 Eyl, 2017 1 kayıt (commit)
  10. 17 Agu, 2017 1 kayıt (commit)
  11. 25 Tem, 2017 1 kayıt (commit)
  12. 14 Tem, 2017 1 kayıt (commit)
  13. 30 Haz, 2017 1 kayıt (commit)
  14. 24 Haz, 2017 1 kayıt (commit)
  15. 08 Haz, 2017 3 kayıt (commit)
  16. 03 May, 2017 1 kayıt (commit)