https://bz.apache.org/ooo/show_bug.cgi?id=123544
--- Comment #26 from Regina Henschel <[email protected]> --- The corresponding bug in LO is https://bugs.documentfoundation.org/show_bug.cgi?id=43021 I have looked at the problem too. The method setDisplayDirectory is used internally too. I have tried to force the implementation to take the string sDirectory from the [in] parameter. RequestRef rRequest(new Request()); rRequest->setRequest (VistaFilePickerImpl::E_SET_DIRECTORY); rRequest->setArgument(PROP_FORCE, true); rRequest->setArgument(PROP_DIRECTORY, sDirectory); // rRequest->setArgument(PROP_FORCE, bChanged); That works for calls in a macro, but then on other places no longer the previous directory is used in the file dialog -as it should be-, but the default directory. Another question is, what is the purpose of the user setting item WorkPathChanged? Until now I have not found a place where this setting is evaluated. Inside the method it is not needed, because independent of its value, PROP_FORCE is always set to "false", only that in addition the user setting in registrymodifications.xcu is set to "false" in addition and remains so. The file open/save dialogs for graphics have their own implementations in FileDialogHelper in sfx2/source/dialog/filedlghelper.cxx. It might be, that it is needed to divide the usage via API from internal usage in other cases too. To me it looks as if there are so many question around this method, that there is no quick, well thought out solution for 4.1.2. -- You are receiving this mail because: You are the assignee for the issue. You are on the CC list for the issue.
