At least since:
commit ee79a2dd7e
Author: Caolán McNamara <caolanm@redhat.com>
Date: Fri Jul 29 14:33:22 2016 +0100
Resolves: tdf#101169 crash using column menu in base
Change-Id: Ib1bc70e8e66f2be123d8a3e5d5e213775e9a5762
...which isn't true at least ever since b525a3115f
"initial import", but got copy/pasted all over the place
Change-Id: I47d3d8a594aef3ac3736d7176ae964a118821014
The signature date can be placed as the value of the "M" key, and also
inside the signed PKCS#7 binary. When the later is missing show what's
described in the previous.
Change-Id: Idb40d91adb70486bc1f19d4755a3f8e17d35e9e9
while for us it doesn't, make it invisible to give it zero width
in both implementations to head off interoperability misery
Change-Id: I0944006817944b20ef35502c8588357e7ee54810
Each pdf signature is mentioned in the Annots key of a page object.
Usually the key contains an array value. But it's valid for the key to
contain a reference to an object, where the object contains the actual
array, so support this case as well.
Also:
- stop parsing name tokens on the first seen '(' character (usually
there is a whitespace between the two, but that's not required)
- handle \0 characters in the last 1024 bytes of the document by using
std::search() instead of strstr().
Change-Id: I3a167b23340230f99f1ae4112473ed10e1c96b09
Wherever non-formula-expression ranges with external document reference might
be used in OOXML, format ScAddress/ScRange as '[1]Sheet Name' instead of
[1]'Sheet Name' as Excel expects them.
Change-Id: Ia7be13f4d631405e4bcb4617fbded27586fa5dcd
... instead of twice the same name. Even if not handled yet in Calc, external
3D references may get imported and have to be written again.
Copy&Paste error since 2f373570c5
Change-Id: I6cb982793e1072d619053c02860a8046e78bc99e
Excel expects '[1]Sheet Name' instead of [1]'Sheet Name' and complains if it
encounters the latter.
Fortunately Calc handles both.
Change-Id: If1129e58725b522ca4755c05e313c03fca065f28
That started as
OSL_ENSURE( (nTabId == 0) || (getFilterType() == FILTER_OOXML) || (getBiff() == BIFF8),
then with c4cb83504f became
OSL_ENSURE( (nTabId == 0) || (getBiff() == BIFF8),
then with e73c4d5013 became
OSL_ENSURE( nTabId == 0,
which makes no sense anymore and gets hit in ~every call.
Change-Id: I5dfe3dd53310ab2f977ad574acb1ec9874775020
It fails when Excel is installed, for some reason:
Basic error:
Type: com.sun.star.uno.RuntimeException
Message: [automation bridge] unexpected exception in IUnknownWrapper_Impl::invoke ! Message :
[automation bridge]: [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
macro result for ole_ObjAssignNoDflt.vb
macro returned:
C:/cygwin64/home/Tor/lo/64bit-debug/basic/qa/cppunit/test_vba.cxx:155:`anonymous namespace'::VBATest::testMiscOLEStuff
assertion failed
- Expression: pReturn->GetOUString() == "OK"
- Result not as expected
Note that this test returns early if Excel is not installed, so it is
not run effectively performed anyway even in 32-bit builds on most
(any?) Jenkins and tinderbox machines.
Change-Id: I0a0b6f27219dec116369fae1bb7c95b3e9597e77
Menus, context menus, toolbars, toolbar items...
could be created with empty names, and could be
renamed to have empty names before this patch.
Change-Id: Ic383f16955746002aa3ad69406bac855cdd58d2d
Reviewed-on: https://gerrit.libreoffice.org/30286
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
Tested-by: Jenkins <ci@libreoffice.org>
This also removes the only occurrence of the
"com.sun.star.frame.ToolboxController" service. However it shouldn't
be considered as API CHANGE, as no 3rd-party code should rely on
undocumented services, and fortunately a toolbox controller like this
has no use for 3rd-party anyway.
BTW there are other cases of using non-existent (unique) service
names for toolbox controllers in non-sfx2 modules, rather than using
the standard "com.sun.star.frame.ToolbarController". There is
OToolboxController in reportdesign (which I hope to remove soon too,
as it's just a wrapper around SvxColorToolBoxControl). And there was
also ShapeToolbarController in chart2 which I removed in
2aea9e37d6 ("Introduce generic sub toolbar
controller").
Change-Id: Iea8858be2406f32bb5a022920b4b1cee70603c09
Try to set another command from the dropdown, if there is any
enabled. Otherwise give up and disable the button altogether.
Change-Id: I7fa46a946826056d04851faee9c7ad85f00c3678
If a second arg is passed in the "Value" property, it will be
treated as boolean. If true - the button will be
ToolBoxItemBits::DROPDOWN, and will keep replacing the main
command with the last selected one from the dropdown. It will
also respond to status updates of that command, currently for
enabled/disabled and boolean (true treated as pressed) states.
Change-Id: I09a5c20e6d2a010867037754f036096246749ec4
... to popup menu controllers it creates, similar to what
is does for child MenuBarManager instances. That way a
child ResourceMenuController placed inside a popup menu
won't mistakenly think it's inside the main menu.
Change-Id: I75eea28eeb38f16bfaaa5526752a957859ef0d32
We should also just use the string literals as such in the code (some
newer parts of this module already does that), and not hide them
behind preprocessor macros. An Easy Hack?
Change-Id: I3ab5793ff265a4aceff2fed1562a54bfb0ce3ccb
Because some stuff wants to multiple-inherit from VclAbstractDialog and
OutputDevice-subclasses, and we'd prefer to keep all the lifetime
management through a single smart pointer class (VclPtr)
The change in msgbox.cxx and window.cxx is to workaround a bug in
VS2013 to do with virtual inheritance and delegating constructors.
Change-Id: I178e8983b7d20a7d2790aa283be838dca5d14773
Reviewed-on: https://gerrit.libreoffice.org/29140
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
- do concat for json in C++, everything else seems fragile on Windows
- have APPEND vars separately
- check that gbuildtoide work on modules without a full build (modulo
some blacklisted "creative" ones)
Change-Id: I6fe267fee7d1b77d758072303729387dfeb8e6c8
Reviewed-on: https://gerrit.libreoffice.org/30293
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
