forked from amazingfate/loongoffice
9556677d1a
The problem appeared, because the existing CharSet property was storing the index of the selection in the encoding list box; and that meant, that any change in the list box content (different sorting; added elements) could suddenly make the selection wrong the next time. With introduction of the autodetection entry into the top of the list box in tdf#152336 (in commit 565b619d57a3b98b0826c4b49dee6606f9ae70e0), many people who had UTF-8 selected in the dialog previously, got UTF-7 instead; and many had not noticed the difference, thus seeing unexpected results after import. The said commit intended to force-select autodetection for the users who had not used the updated dialog yet; but the detection of that scenario was flawed, and didn't work (that was discussed, and respective code was dropped in commit ...). This change implements that idea. I decided to ignore the stored CharSet value; after the change, autodetection entry will be pre-selected at the first start of the dialog. This will be a minor annoyance for users who have already re-selected wanted encoding after previous upgrade; but it allows to resolve the bug for people upgrading from versions prior to 25.2. Also, since new versions will not write to CharSet, it's possible to use a shared profile between old and new versions without breaking the encoding selection in either. Change-Id: I59640b16f703077b6fda44a34eadf2edbe8e6bf5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186240 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit d16535788721238a423408ba59805f4bcacc4e12) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186246 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>