Change-Id: Ic6488ac278cac2d1d7e240abff545f9ea0b8eafe

Change-Id: Ib4eba9f6386214d010c880ad15bcacce7665a3af

Change-Id: I89c35503d22797c5d5117e298f04e953de03044a

Change-Id: I1918f91ec070761a8fe9d04058820af1c7880678

Change-Id: Ib9810cbc96fab5218a497985aac80cbd7c0c188d

Change-Id: Ia940d5a064f60c147e743e9e28ac2252cebff840

Change-Id: Iba5bf2d2207f80098cb43ff8ce290eef741d21c9

Change-Id: I4733554d3329525516511bbd60b9ad3fabc12be0

Change-Id: Ia55702e1ce7ca153de6e82abfce731bb8fc21977

Change-Id: I1ae85e416440768ab40c817506d5b106289c4d72

Change-Id: Ie957ab2b63facc15a990f22347ce2393f6bb6a44

Change-Id: Idc397c918980ba4bb47fb73fbd0e6dd11fb6d0b7

Change-Id: Ic6283b7a71a5d1c539ae99155f448e34e877080a

Change-Id: I4d1c0b6f0586e2ff7adc5aae524a14c9eaa2dc3b

Change-Id: I1469910e3c20248133e56145c9ea543cbfdf3c4a

Change-Id: If4c548c1ed9275f525fe311853545af3f6313f41

Change-Id: I3ee5d05142ebd9738e34ea3276932a4f9e3fc43d

Change-Id: I6236c255708f13131117246743d86cd3448bce24

Change-Id: I06dde63093eab4e5e1c692f6363aca70b89de96a

The problematic path was "m,l21600,r,21600l,21600xem@1@0l@3@2nfe", here
"m,l" means an implicit "m0,0l", but only the first zero is in the
coords list. If the second is missing, assume 0 as well.

Change-Id: I03065e34c959103c9caf64271aa3ebbb7ad52726

Change-Id: I782942e25107ce996f3f31c3f53123c118d81838

Change-Id: Ibe8e80169b222e425df7016a0012591793546adf

Change-Id: Ia30628e093a885165b2d8a7b1a999c0dc7ee65cd

Change-Id: Ic9ea40c430e0b0ab0d46bac3ba150ddac96c6acc

Change-Id: I3dcbc1b643a29ee080e5b034dccd4882a43590a4

Passing an, as such useful, verbose error message to the
CannotActivateFactoryException constructor is fairly pointless if that
exception ends up being unexpected and causes program
termination. Which of course is exactly the case when one would be
very interested in seeing any message associated with the exception.

Change-Id: I1cd987669e39e47d5f072690dc5013e4a42fd50a

aStr may be 1 larger than pKernArray.
Trivial fix by checking the largest index; not sure if it would be a
good idea to allocate pKernArray with the larger size in the first
place, but that would be a bigger change...
(regression from 02ce7344)

Change-Id: Ia33feab001c34e85066b7596d8873f41588984e9

MarkDataChanged() is quite expensive & in theory unnecessary when no
selection is present.

Change-Id: I6967b914735462403a77568010532b37a1d8f333

Change-Id: I38b91f9e02c1addd8a0ef427b7b09cdf1a04ee95

This is a leftover from the 1 million row conversion we did years ago.

Change-Id: Ib50819ed51c7017bcc559bfc8b6062ff46615d09

Add more unit tests, reduce the number of rows that we know are empty
that we iterate over while saving by shrinking the column set that
we scan as we go along.

Change-Id: Iebd817d9a8a01fa6abeaa24c4aace92233313e0f

boost::optional appears to show up rather heavily on many profiles.
We already use mnElementToken == DONTKNOW to flag / use these guys.

Change-Id: Ibf2b0167f259cc601da2fb9703e880b78e60886e

Change-Id: I4cec5ba61762ac87d5bfb07b15ab661955e207ac

...there was a handful of Hide(true) calls, which would happen to actually mean

  Show(false, SHOW_NOPARENTUPDATE)

but I assume those were typos rather than genuine requests for
SHOW_NOPARENTUPDATE.

Change-Id: I20310d58437bb556f95965885f82784f855b517d

Change-Id: Ib74830671694f2c78adc7a11296971a7edd2f781

so we can safely change the return of 0xFFFF to 0 without
changing any callers. Which makes this safe seeing as before
now every caller would have done something stupid with the
results

Change-Id: I10d9f12525de10661ed82f3405e6c728d38be106

Change-Id: I93309674ef50e8ca7438874378fb01484bb7f9f3

Change-Id: Icc9def55a814fc1309ce143a84effc140a90a92b

It's the isCustom field that should be checked to see whether the
customAttribute field has been assigned or not.

Change-Id: I5d2af26b675ab0cbc0e1844eb98ebaf5145eb73d

Change-Id: Id816d1da328e83197e0b1b4641ed894b62f1c78b