...to improve diagnosing misuses of boolean expressions in client code (cf.
compilerplugins/clang/implicitboolconversion.cxx). This change should be
transparent to client code.
Missing overloads of insert() for bool have been added to OStringBuffer and
OUStringBuffer (which required dropping one !VALID_CONVERSION check that would
now pick that overload, but would be flagged by
compilerplugins/clang/pointertobool.cxx).
Change-Id: I2d64cd923b8f47bfaa31e753def6515c29a3f8c9
A final pass through the code, converting code to use the new
OUString and OString methods that can detect string literals.
Change-Id: Ifa6382335e5650a1c67e52006b26354e0692c710
Convert code like
aStr.compareToAscii("XXX") == 0
to
aStr.equalsAscii("XXX")
which is both easier to read and faster.
Change-Id: I448abf58f2fa0e7715dba53f8e8825ca0587c83f
This is both an optimisation and a cleanup.
This converts code like
aStr.indexOf("XX") == 0
to
aStr.startsWith("XX")
and converts code like
aStr.lastIndexOf("XXX") == aStr.getLength() - 3
to
aStr.endsWith("XXX")
Note that in general
aStr.lastIndexOf("X") == aStr.getLength() - 1
converts to
aStr.isEmpty() || aStr.endsWith("X")
so I used the surrounding context to determine if aStr could be empty
when modifying the code.
Change-Id: I22cb8ca7c2a4d0288b001f72adb27fd63af87669
Don't mess with encoding in Logger.log, since sys.stdout.write()
accepts str (in python3) and both str/unicode (in python2) anyway.
Change-Id: Ib0339b7fd882a7654cc24c38efdaf67f519663ff
Change all instances of hardcoded "program", "share" etc subfolder names to
use those from <config_folders.h> instead. In normal builds, the end result
will not change.
Change-Id: I91c95cd8e482818be67307e889ae6df887763f53
access to libreoffice objects ( and methods/properties of those objects )
from VB all goes through the ole automation bridge. There has been a long
standing issue where the bridge falls over trying to access methods of the
scripting framework MasterScriptProvider object.
Change-Id: I3b9391286e1030bef2a12d6e546a5c47a4f68edb
i.e. I see the bug in our built-in python3 3.3.0 but not in my system python
3.3.2 and there's a raft of email related bug fixes in the 3.3.2/3.3.1
python Changelog
Change-Id: I257770cd0ec41fc3b2f2a638009b075b9a2f325f
through environment vars
Set the log level with the environment variable "PYSCRIPT_LOG_LEVEL"
"DEBUG" (for debugging)
"ERROR" (show errors only)
"NONE" (or anything else) (for production) is the default
and the log output type with the enviroment variable "PYSCRIPT_LOG_STDOUT"
"0" (log output to user/Scripts/python/log.txt)
"1" (or anything else) (log output to stdout)
Patch by: Tsutomu Uchino <hanya.runo@gmail.com>
Review by: Herbert Durr <hdu@apache.org>
Note: Commit message edited by ASF infra team to work around a known issue with the
ASF svn install (not an issue with svn) and UTF-8 handling. This is a temporary
issue that we hope to resolve soon.
(cherry picked from commit 9dc7f72febe9d294304f70cc7b9cdeab1c67dc8b)
Change-Id: I099c8b3f812559c380078f63b692c83fdc811e33
This reverts commit 6c61b20a8d. As discussed at
<http://lists.freedesktop.org/archives/libreoffice/2013-May/052449.html> "Re:
fdo#46808, Convert awt::UnoControlDialogModel to new style problem" why the odd
change in 2e2a4827ce "scripting: get
CreateUnoDialog() work again" appears to fix things again:
The problem is that the implementation of the css.awt.UnoControlDialogModel
involves UNO aggregation
(IMPL_CREATE_INSTANCE_WITH_GEOMETRY(UnoControlDialogModel) in
toolkit/soruce/helper/registerservices.cxx creating a
OGeometryControlModel<UnoControlDialogModel> instance that aggregates a
UnoControlDialogModel instance). That means that queryInterface can return a
reference to something that is technically a different object, and that's
what's happening here, and explains why calling setPropertyValue in two
different ways on what logically appears to be a single object can end up
calling two different implementations (of two different physical objects).
(UNO aggregation is known to be broken and should not be used. Nevertheless,
there's still code that does---code that is a horrible mess and hard to clean
up.)
That all this worked as intended in the past is just sheer luck, but any
way of substantially touching it is asking for trouble. I'm going to
revert 6c61b20a8d again.
I wasn't able to revert without also reverting
be50ad28f5 "fdo#46808, Convert
awt::XUnoControlDialog to new style," as the two were tightly dependant. Also
reverts all the follow-up fixes cb4b6dde8f
"-Werror,-Wuninitialized" (sans the const-ness fix in
UpdateHandler::insertControlModel), 697a007c61
"Fix exception specifications," 2ce6828bbb "fix
awt::UnoControlModelDialog crash," and 2e2a4827ce
"scripting: get CreateUnoDialog() work again."
Conflicts:
basctl/source/dlged/dlged.cxx
filter/source/t602/t602filter.cxx
xmlscript/test/imexp.cxx
Change-Id: I5d133468062f3ca36300db52fbd699be1ac72998
...in commit 6c61b20a8d,
"Convert awt::UnoControlDialogModel to new style"
I added an attribute "ResourceResolver" because some of the client
code was setting it using the property interface.
It turns out that this was a bad idea because the "ResourceResolver"
property is doing some very interesting stuff, so revert that part
of the change.
Change-Id: I62b890e60164e005867ced49c3e407a49ed09441
Reviewed-on: https://gerrit.libreoffice.org/4013
Reviewed-by: Miklos Vajna <vmiklos@suse.cz>
Tested-by: Miklos Vajna <vmiklos@suse.cz>
Original author: Tsutomu Uchino <hanya.runo at gmail.com>
(cherry picked from commit 5de5fd495d7cdad852d1631941ae03ec213f93b7)
Change-Id: Iaa0aa8b1dd6a326cd738f2e296a1b5ecdc379c65
