Project: help  0928f7ad945adabae18d618d9c63c12a6472ff8a

Change-Id: Ifaad85d637167bd85be2e15809e847efcdecd584

Change-Id: Ie3e5e3b8a68fdfa7b5a0c985b49f69fc87449ee0

Change-Id: Ic236a52311a5bd868daa50851a2a88c92c377f51

Change-Id: I84b79c6cc11a5cd506e22caf294423a3c0b953f0

...it looks like it used to be the order the constants appeared in the .idl
file, while now it happens to be the lexicographical order of the constant's
names.  For all the constant groups in com.sun.star.report the order expected by
the code appears to be the order of the constant's numeric values (which happens
to coincide with the order of appearance in the .idl files), so explicitly sort
them that way.

Change-Id: I550401b2742fffb7c96a7787498967a7cd78fff8

Project: help  50fb4825f0debbcff34a6110e66caaae2674fba5

blast, they *are* unused, bad grep

This reverts commit 0ec56aee.

Change-Id: I06b618f88240dab084dfa89fd21119f07d5ee5d5

Change-Id: I780f4a117ce0a461031d8b66747d7d52493ef6d2

Project: help  339d9e2a57394896e9a199d2c2676d4e97d31ba1

Change-Id: I292db7ad4c614568fe9a5f011e545e9a068e8a5c

Conflicts:
	cui/UIConfig_cui.mk

Change-Id: Ia628babd27ca29769a6a287f70367d8208c5cc59
Reviewed-on: https://gerrit.libreoffice.org/5510Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Project: help  79e86ab4719ffe4d9178a5a97c0f69835cf2e9e3

Change-Id: Ide59f0fa382c148abeac2b3dde17cc913183391d

Change-Id: Ia0a11f636b864e5dd7c8ef6f4e8d1c3bb6f0a26f
Reviewed-on: https://gerrit.libreoffice.org/5507Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Project: help  c3a761cddfe4b21a1409096097df3cd8712b0445

Conflicts:
	cui/source/inc/helpid.hrc
	cui/uiconfig/ui/slantcornertabpage.ui

Change-Id: Ifd2a18ad1a84728237de61bed3d96f83313afd62
Reviewed-on: https://gerrit.libreoffice.org/5506Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: I1316fc4ae1d4dab91684bdc059f5c69c5e0c401a

Change-Id: Iab00310e2e6fcf8a43617363cf095a1bccfd9751

Change-Id: Ida916e3019d72c9e9d1b5b117de2060f0227c310

Change-Id: I94051d2f2c1bd4cce6945798f85e90d6b5316450

Project: help  d2c983410d61bd286667b89f5d8d44244bb463c0

Conflicts:
	cui/source/inc/helpid.hrc

Change-Id: Id0a51421e7d6cb7e0d0265f88de31ff3d9c574ec
Reviewed-on: https://gerrit.libreoffice.org/5505Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: I3c660679852afee5fc6684f4ea94445ce1ec8423

Project: help  f8a660c3c6850535ab48c0a9536229ac374255c2

Change-Id: Ic2ea51faf0fcec0a7d6fdc4a52e2e930e8461e20

Change-Id: I539fb2599743ed2eda3b33895f73230cc2342055

Conflicts:
	cui/source/inc/helpid.hrc

Change-Id: I5265e74e88654136b4eeeabf7cfcae24dec08e38
Reviewed-on: https://gerrit.libreoffice.org/5504Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Project: help  8fad124be31b9f372454c7bb68cbd293f06d4e1c

Change-Id: Ied4353f4997e330f65b8dffb58bbdc791196427e

Change-Id: I7a541a8ba6b561736e93c45ac9c20caddafcbe52

Change-Id: I2c6f2553cd0a1657981de720b2398754253ec4d4

Change-Id: I13a819829f1aa6ac3cdf2e3aa1237af170610f80

Tons of these warnings were printed during the build, and nobody
cared, so they can't be that serious, can they?

Change-Id: Iecad7d8f6c562d04c5360161387212efef59b889

Change-Id: Id192bd7d62d0ce9d5abc04390670cb277c6ec755

Change-Id: I520832508a8d419e394817a0e25949071928f612
Reviewed-on: https://gerrit.libreoffice.org/5478Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>

createStandardColumnPart returns a string that is usable in table creation,
the type descriptor (e.g. CHAR(N)) is also useful in column-type altering
statements, hence this is split into a separate function.

This is needed primarily in the firebird driver where column-type alter
statements are in a different form to most dbs.

Change-Id: If44554f979f6dd14bf679455978f3f0b44784bf5
Reviewed-on: https://gerrit.libreoffice.org/5432Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>

It is not completely clear to me whether we really still might be
leaving such files around. After all, we now in *two* places (at least
in current master) tell our NSWindows to not be
restorable... Norbert's code in AquaSalFrame::initWindowAndView()
*and* Herbert Dürr's code in -[SalFrameWindow initWithSalFrame:].

On the other hand, Cocoa does seem to create the file and keep it
around for a short while before removing it (in responce to our
setRestorable:NO calls?), so there is a slight time window where if LO
crashes, the file will be left around.

Such a file might also be around from an older LO version, or manually
planted there by somebody wanting to reproduce the bug...

Of course, the *real* fix for this problem would be to make LO a
*proper* Cocoa document centric application, that would use
NSDocument, NSApplication etc like native applications are supposed
to, and that *would* handle window restoration the Cocoa way. I.e.,
work with the system instead of against it.

Change-Id: I9ed058130ddddf49cf0221d899bef3e2654589c7

Change-Id: Ib451bdb3c1c2ca42347abfde44651d5cf5eef4f3

Change-Id: I7332b0ead075e09b60549203bc32eb99a2bb0430