Apache OpenOffice (AOO) Bugzilla – Issue 4306
AOO File dialog opens *.lnk itself as document instead of opening linked document
Last modified: 2014-02-02 08:17:05 UTC
When you do File-->Open, start at Desktop (or anywhere else) and doubleclick a shortcut to a folder, you go to the folder BUT the shortcut.lnk filename also fills into the Open File dialogue. This shouldn't happen.
Tony, thanks for posting this issue. Thank you for using and supporting OOo. Duplicated on Win NT 4.0 SP6a, OOo 1.0.1.
*** Issue 8086 has been marked as a duplicate of this issue. ***
JA->TM: reassigned to you
Our own file-open dialog doesn´t support lnk. files by now. So this problem occurs in the windows system file-open dialog in every application this dialog is used (eg. windows media player) and not in OpenOffice/StarOffice only. This one is a windows "problem" and won`t therefore be fixed.
I can tell you that this behavior does NOT occur in Windows 2000 in WMP or any other application that uses the Win2K system-wide File--> open browse box, including Office 2000. If you test OpenOffice on Win2K (note the OS field in the bug) you'll find that OpenOffice does indeed exhibit the behavior detailed in the beginning of the bug, but that no other apps using the Windows common File-Open box have this problem. MS noticed it on NT and fixed it for Win2K, but it's still broken in OO. It's been nearly a year since I reported this problem, so I can understand your desire to just close it, but "Blame MS" is the wrong approach in this case. They do it right, you don't. Sorry.
TM->TRA: As far as I know, MS Office 2000 uses an own implemented file-open dialog which looks very similar to the systems one. Due to the fact, that there are apps. which act the same way, we do (eg. MS Windows Media Player) and some who don`t (like MS Notepad), please have a look and consider if this is a bug (not only in StarOffice) or an RFE ! Thanks !
I'm afraid it is yet another bug of the Windows FileOpen dialog. The Windows File dialog behaves correctly when called as "File Save..." dialog. A simple test progam shows that it even behaves correctly when launched as FileOpen dialog, but StarOffice uses a rather complicated scheme to setup the Windows File dialog to work around other bugs of the Windows File dialog, so I suspect this is the source of the problem.
Yes I admit it looks ugly. I already invested some effort to find the cause of this behavior but until now without luck. So everybody is welcome to help finding the reason for the behavior of the Windows FileOpen dialog. I cannot see the reason in our FilePicker code (project: gsl/fpicker). I will try further to find the cause. Kind Regards, Tino
Found a hint. If someone creates a Windows system FileOpen dialog that allows multi-selection then the dialog behaves strange on links to directories. Even the Windows Media Player under Windows XP has this problem (try it). Notepad on the other hand uses the Windows File dialog in single selection mode and there is no problem as there is no problem in OO with "Insert graphic from file..." which is even only a single selection mode dialog. So we were not so wrong with blaming M$. I will look if there is a workaround. Kind Regards, Tino
TRA->TRA: see even #108001#. TRA->*: A simple test program using the Windows File dialog shows the following (we consider the behavior when clicking on a link to a directory either with a double click or a single click followed be a click to the ok button): Filter Single/Multiselection mode File dialog action ---------------------------------------------------------------------- No filters specified Single sel. mode returns the link (filter box is empty) No filter specified Multi sel. mode a single click on the link shows it in the file name box, clicking ok returns the link At least one filter Single sel. mode double clicking on specified the links changes into the refered folder (ok) At least one filter Multi sel. mode Single click on the specified link shows it in the file name box, clicking ok changes into the refered directory Kind Regards, Tino
Hi Andre, we could at least prevent iBis issue #108001# if you would add at least one filter like e.g. "Alle (*.*)" to the FilePicker (please ask FS how to do it). Kind Regards, Tino
Set to OOo later flag. Because it is not so important for OOo to workaround bugs in Windows system file manager.
*** Issue 6984 has been marked as a duplicate of this issue. ***
*** Issue 12472 has been marked as a duplicate of this issue. ***
*** Issue 18523 has been marked as a duplicate of this issue. ***
*** Issue 31888 has been marked as a duplicate of this issue. ***
*** Issue 42978 has been marked as a duplicate of this issue. ***
Removed myself from the CC list.
Reassigned for change of responsibilities sake.
.
cd: Please take over.
Still Reproducible with server installation of "AOO 4.1.0-Dev – English UI / German locale - [AOO410m1(Build:9750) - Rev. 1562493 - 2014-01-30]" on German WIN7 Home Premium (64bit)", own separate user profile: 0. Download / Unzip attached test kit 1. From AOO Start center menu #Tools -> Options -> OO -> General -> Use OO File dialogs' 2. From AOO Start Center menu #File -> Open -> Browse for TestKit-folder > You will see "samplepresentation.otp.lnk", what is a link / shortcut to document "samplepresentation.otp" in subfolder "Sample" 3. Click "samplepresentation.otp.lnk" -> [Open] Expected: Presentation will be opened Actual: ASCII Filter Options dialog appears :-( Additional Info: ----------------- (a) I wonder whether "Bug 3322 - OO tries to open Windows shortcuts as documents" means that also other OS than WIN are affected. (b) I do not agree with Rating P5 - Trivial.
(c) Already reproducible with Pre-3.4.0 (never worked), but because of crippled Version selector (Bug 123063) no useful info can be contributed
Created attachment 82468 [details] Test Kit See Comment 23 how to use
*** Issue 62196 has been marked as a duplicate of this issue. ***
(d) Raise severity because of DUP "Bug 62196 - 'File > New > Templates and Documents' tries to open *.lnk itself as document instead of linked Template"
*** Issue 100318 has been marked as a duplicate of this issue. ***