https://bz.apache.org/ooo/show_bug.cgi?id=126680
--- Comment #44 from Arrigo Marchiori <ard...@yahoo.it> --- Method com::sun::star::i18n::Transliteration_caseignore::loadModule() is used to load "modules" for processing text. There seems to be only one instance of Transliteration_caseignore for the whole program (a "singleton"). Such instance is accessed via a utl::TransliterationWrapper instance. There are several place where a TransliterationWrapper is constructed: 1- ScGlobal::GetpTransliteration() -- specific for OpenOffice Calc. The object is created with module TransliterationModules_IGNORE_CASE 2- vcl::I18nHelper::ImplGetTransliterationWrapper(). The object is created with modules TransliterationModules_IGNORE_CASE and TransliterationModules_IGNORE_WIDTH. 3- OnDemandTransliterationWrapper::get(). The object is created with the modules passed to the OnDemandTransliterationWrapper constructor. In fact, it also has a zero-parameter constructor, and the modules are passed to the OnDemandTransliterationWrapper::init() method. This happens in SvNumberFormatter::ImpConstruct. The IGNORE_CASE is the only module requested. In fact, construction no. 2- instructs the singleton instance of Transliteration_caseignore to load the IGNORE_WIDTH module alongside the IGNORE_CASE. This construction, in one case I could observe, is requested by method ComboBox::ImplUpdateFloatSelection(). This looks like something that could happen at any time. Construction no. 1- and 3- are equivalent, because they request the same single module IGNORE_CASE. Construction no. 2- is frequently happening after the test document is loaded, and before it is saved, therefore invalidating the in-memory list of database ranges. I believe that fixing this problem will consist of having both IGNORE_CASE and IGNORE_WIDTH indicated in all attempts to construct a TransliterationWrapper. I will try to follow this path and report here my results. -- You are receiving this mail because: You are the assignee for the issue.
