Age | Commit message (Collapse) | Author |
|
Change-Id: Iefeaf81d4f7463440a6c5a8abb4d68aa85190698
|
|
to prevent problems with accidentally deleting an object by doing this:
Button *pButton = new Button(NULL);
...
pButton->callAMethodThatTakesARef(pButton);
Since we take a ref as we construct a temporary VclReference<> - but
this will dispose & delete the pButton as we return to the frame doing
the callAMethod
Change-Id: I60fc211b27fe7ff463aa58f1da106f430fc65529
|
|
i.e. the ones that declare any VclPtr fields
Change-Id: I7adfc3b3b190a2ede60bfccd08f85a269fae33ca
|
|
Change-Id: I7121c1727d1374a955fbccb6554aede468d4977f
|
|
to avoid unnecessary increment/decrement traffic
Change-Id: Ice4e08df002b815105aa0b1c9430511c0cec3d28
Conflicts:
compilerplugins/clang/passstuffbyref.cxx
|
|
Change-Id: I773fb5ed066db2c22b3d50198dff350b755ab24a
|
|
to make it obvious in the code when we are translating between the
reference-counted type and raw pointers, since that is the danger-point
Change-Id: I32822432325fa34969e78cccf937e2ccbe1bfb70
|
|
teach the vclwidget plugin to look for places where we need to use
VclPtr<T> instead of raw pointers
Change-Id: I444836bf8e3d05fca0f30380c91a8ce24d1e9d1c
|
|
and remove the typedefs. The code is more obvious this way.
Change-Id: I4c8f5b5ab050dd96216302a03e760ed0e3ab3464
|
|
First stage of new VCL widget reference checker
Change-Id: I63a2108a26b3c0e0a896d13672b1daa6f8e60b3a
|
|
so we don't have to call .get() everywhere
Change-Id: If6ccd7dcf1a492b1e7703956ecbe8e5ac2dd0fb7
|
|
to make code less verbose
Change-Id: I0e28bfc412d50e798e6c215434cffc2183b104a6
|
|
Change-Id: I74371118b679b06b9631e00d34c3f88e58bce24c
|
|
Change-Id: Icbfe237a55cfbd83739b055350d5a6a54a2fa36d
Conflicts:
vcl/source/control/edit.cxx
|
|
Change-Id: I24035c67c99ce431e94b39bd6d0d3b274fa55fa8
|
|
Widgets must be able to tolerate multiple 'dispose' calls.
Change-Id: I76069a10b83b8384ad84dd146766054cab5bd222
|
|
Change-Id: Idef6b4259d784120a06d2a6c51b77029566da59f
|
|
Change-Id: Ie95790cbaa5d459c8e849d7333098d857d31ed0a
|
|
Ensure that only desired tokens are obtained and the resulting new token
is actually the current one upon return.
Change-Id: I624c324b861d8658accf3285cad2cfc5a598b450
|
|
Change-Id: I1263f190d769254949701b3a257b2af5d6ea61a2
|
|
Change-Id: I73109e5a862b2f4bc456dff512bddf5d23586a6d
|
|
Change-Id: Ia4a52a5e605474738983d48a925b6b3ba90877d4
|
|
but the PanelLayout didn't
Change-Id: I38a8975f1488fa2a2ffe91b66745e1a1c6c48a28
|
|
Nothing obvious that would speak against converting from the original
SvStringsDtor to plain std::vector<...> instead of slavishly sticking to
boost::ptr_vector<boost::nullable<...>>. Also, prevents a false -fsanitize=null
warning about "reference binding to null pointer of type 'rtl::OUString'" in
boost::void_ptr_iterator<...>::operator*() during ~SvxClipboardFmtItem_Impl().
Change-Id: I08d8fc573ff99a5bddd67c0d2be4e7ea38025958
|
|
Regression from commit bb00a0097900ae054401f7758a915047cfde4065 (do not
bother with nice unique names during mailmerge, 2014-11-08),
SwAttrSet::CopyToModify() expects that in case SwDoc::FindNumRulePtr()
returns 0 for a name, then the call to SwDoc::MakeNumRule() will use the
not found name (as SwDoc::GetUniqueNumRuleName() will return the just
checked name).
As a result, simply always returning a random unique name during mail
merge is a problem. Only return a cheap random unique name if no hint is
given.
Change-Id: I49d65009ced97d00aa2e8db35a529f2f30ac9ae5
|
|
Change-Id: I92c171b5900d770195bcad71a7df2a282649d479
|
|
resize *after* setting visibility of controls and not before
Change-Id: I9318b8a5bc1f4afc6f4ceb4503af3425d0f6364b
|
|
this reverts
commit f0ee8ed43528b17e9ea6d83388fbaab0a645b677
Author: Caolán McNamara <caolanm@redhat.com>
see if we can merge floating window and dialog child size/pos setting
seeing as we apparently can't merge them the way that tried to do
Change-Id: I25fb741c9ae73375124b469f98bf1eecd76ff3c1
|
|
Change-Id: Id9ba3dbd1df46638eb4ca2ef84ba1b40ca424108
|
|
Conflicts:
sw/source/ui/chrdlg/numpara.cxx
Change-Id: I3e2c493d412c8e7974e7cb314eb0ba8f13edb6b6
Reviewed-on: https://gerrit.libreoffice.org/14518
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Conflicts:
sfx2/source/dialog/mgetempl.cxx
Change-Id: Ieac16f9cd6063e38c6d8dee0a1f0dba29e1adc6f
Reviewed-on: https://gerrit.libreoffice.org/14516
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ibb80d88865048e178a8d3e93cb9737881dd9f102
Reviewed-on: https://gerrit.libreoffice.org/13785
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I7356eb2074520884ff24d89c68bf1214664f4af3
Reviewed-on: https://gerrit.libreoffice.org/13740
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I715374b531da2850434b2436633b6042ecb9ebe0
|
|
Change-Id: I37f16184d8671f6f0eba7679e712e458abee314c
Reviewed-on: https://gerrit.libreoffice.org/15195
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I9e2b9388c5df1b3a5fc0b2deb570b6f63e59b8eb
Reviewed-on: https://gerrit.libreoffice.org/14637
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I13cbde947d6252c1157ec79a5f2190df24cca978
|
|
When tiled rendering, we always want to create some kind of selection
when long pushing on a table cell. If there is at least one word in the
cell, then we want to select the nearest cell, and when it's empty, then
we want to select the cell itself.
In case there is a table with 1 rows and 2 columns, and A1 is empty, but
A2 has multiple lines, then in A1 there is an area that's outside the
text frame of the empty paragraph, but inside the A1 cell frame. When
clicking on that area, the cursor position gets corrected. With this
change, we get a proper selection on long push even when pushing on that
"outside text, inside cell" area, too.
Change-Id: Ic61743014708f127087243cb7b129f8abd72edaa
|
|
Change-Id: Id4194f4d5bb6fcf064985fddc6f7344a4d34ca04
|
|
Change-Id: I240859bafa953c75ee639ccb77305161274217d1
Reviewed-on: https://gerrit.libreoffice.org/15210
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ie348778ea666c24e95e048386547f301083a0017
|
|
this has niggled me for decades
http://german.stackexchange.com/questions/7528/meaning-of-behind-when-translated-from-german
summarizes it well
"'Behind' is typically used when the context has meanings of depth, and as such
becomes ambiguous when used in a flat list ... 'After'/'before' contain
meanings of ordering which are unambiguous"
Change-Id: Ib2e7244f1dc0a66a9ca30df3a20e31de7a9b9d09
|
|
more 'extern C' fallout from my conversion of enum to scoped enum
Change-Id: I4c9aabbfbd255775a8f3edc2b7c8c62647f539eb
|
|
Change-Id: I77914d1b6fe538f3f38beb449e68f50ae36b0798
|
|
since after my converting stuff in include/registry/types.h to use 'enum
class', it can obviously no longer be "extern C", so drop the "extern C"
and rename the file to reflect that.
Change-Id: Ia30f5731316525e48531c4785ab7471a428bcf6f
|
|
Change-Id: I033cc6fce66203ad2967064211f9144b0edf8d1e
|
|
Change-Id: I2177e424d54dc2b5e26b7bbfe073b524e9cc5bab
Reviewed-on: https://gerrit.libreoffice.org/15187
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: If1649e8f3b9d200b0b176bef7deea41445bd3f2f
|
|
Change-Id: If0a2eeeabbb0bea48d2f2f86dc04266812c0ecd2
|
|
Change-Id: I8320f6f42d5579fbd09450ddca61c4c066de98e4
|