Issue 31888

Summary: Quickstarter doesn't follow .lnk files
Product: ui Reporter: adamkennedy <ooo>
Component: uiAssignee: thorsten.martens
Status: CLOSED WONT_FIX QA Contact: issues@ui <issues>
Severity: Trivial    
Priority: P3 CC: issues
Version: OOo 1.1.2   
Target Milestone: ---   
Hardware: All   
OS: Windows 2000   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---

Description adamkennedy 2004-07-22 07:43:03 UTC
This bug refers to the issue that bug #6984 probably originally refered to
before it was changed in meaning, and then marked as a duplicate of bug #4306 (
problems with .lnk in standard Win32 file open dialog).

When using the QuickStarter, which appears to be an OOo dialog, not a platform
one, under Win32 ( Win2K in my case ), .lnk files do not act as symlinks.

Steps to duplicate (directory version)

1. Create a directory somewhere (say, at C:\Directory)
2. Create a symlink/shortcut from $user\My Documents\link -> C:\Directory using
the "New -> Shortcut" right-mouse context menu in the My Documents directory for
your user.
3. Ensure the OOo Quickstart is running and visible in the system tray
4. Double-click on Quickstarter icon to open the Quickstarter dialog
5. In the left panel, select the "My Documents" directory.
6. In the second panel with the file listing, link.lnk appears as an ordinary file
7. Selecting this file will attempt to open it, probably prompting the user for
an ASCII filter

Correct Behaviour

Ideal Behaviour:
After step 5. an (apparent) normal directory "link" should appear in the files
list. Selecting this "link" directory would take the dialog to the directory
referenced by the .lnk file.

Acceptable Behaviour:
After step 5. a 'link.lnk' file appears, but is listed with the icon and style
of a directory. Selecting this 'link.lnk' directory would take the dialog to the
directory referenced by the .lnk file.

Alternative Behaviour:
After step 5. a 'link' item appears as a "symlink", with a normal folder icon
covered with a "link" mini-icon, similar to the way it is done in Windows
itself. Again selecting should take the dialog to the target location.


Equivalent Bug for files

This should of course, have a similar behaviour for files as it does for
folders, using a similar or derivative solution similar to the solution chosen
for the directory issue. I'm not sure if this is worth a seperate issue at the
moment.


Please note that this is NOT a duplicate of bug #4306, which deals specifically
with normal platform file open dialogs. This issue refers specifically to the
custom file open dialog used by the QuickStarter systray utility on Win2K ( and
possibly other Win32 OSs ).

In a related note... is UI the correct place to file this? QuickStarter does not
have it's own component to file against.
Comment 1 stefan.baltzer 2004-07-26 11:20:57 UTC
SBA: Component changed to Framework. Reassigned to TM.
Comment 2 thorsten.martens 2004-07-27 10:09:52 UTC
This is a duplicate of #4306. 

*** This issue has been marked as a duplicate of 4306 ***
Comment 3 adamkennedy 2004-07-27 10:31:21 UTC
This is _not_ a duplicate of bug #4306.

The normal FileOpen and FileClose functions work correctly and as expected. This
bug specifically refers _only_ to the QuickStart mutli-function dialog, and thus
I have to assume that it's caused by a different underlying problem.
Comment 4 thorsten.martens 2004-07-27 13:01:08 UTC
Quickstarter has lost most of it´s context-entries in more recent internal
versions. Problem will therefore not occur anymore. 
Comment 5 thorsten.martens 2004-07-27 13:02:06 UTC
closed !