Information from *.lnk

Just starting out? Need help? Post your questions and find answers here.
highend
Enthusiast
Enthusiast
Posts: 169
Joined: Tue Jun 17, 2014 4:49 pm

Re: Information from *.lnk

Post by highend »

Does anyone have a version that works with unicode file / folder name shortcuts (I've tried RASHAD's version)?

It must be able to get the target file / folder even if it doesn't exist anymore...
E.g. this one: https://www.purebasic.fr/english/viewto ... 09#p518509
Would return an empty string if that's the case

Code: Select all

Real file:
D:\!tests\shortcuts\@Arabic-ﻲسﺠ-characters [UTF-8 with BOM].mkv

Shortcut:
D:\!tests\@Arabic-ﻲسﺠ-characters [UTF-8 with BOM].mkv - Shortcut.lnk

Returns:
D:\!tests\shortcuts\@Arabic-???-characters [UTF-8 with BOM].mkv
AZJIO
Addict
Addict
Posts: 2192
Joined: Sun May 14, 2017 1:48 am

Re: Information from *.lnk

Post by AZJIO »

I just repeated the well-known example GetShellLinkTargetPath()
highend
Enthusiast
Enthusiast
Posts: 169
Joined: Tue Jun 17, 2014 4:49 pm

Re: Information from *.lnk

Post by highend »

Thanks but it is NOT able to get the destination of the shortcut if it (the target) doesn't exist anymore
The output of the procedure is just empty in those cases...

E.g. from my previous example:

Code: Select all

Real file:
D:\!tests\shortcuts\@Arabic-ﻲسﺠ-characters [UTF-8 with BOM].mkv

Shortcut:
D:\!tests\@Arabic-ﻲسﺠ-characters [UTF-8 with BOM].mkv - Shortcut.lnk

Now the real file is deleted but the shortcut still exists (still pointing to this now non-existent file).
The output of the function is empty for the shortcut.
I need to fix shortcuts on a few target systems where the original file still exists (but NOT in the same folder as before) and the shortcuts point to the old non-existing file...
AZJIO
Addict
Addict
Posts: 2192
Joined: Sun May 14, 2017 1:48 am

Re: Information from *.lnk

Post by AZJIO »

BarryG wrote: Wed Jun 05, 2019 8:14 am Hi, the code just above by Bisonte (who got it from Sicro) doesn't work for a shortcut on my desktop that I made to "This PC":

Code: Select all

Debug GetShellLinkTargetPath("C:\Users\{my-user-name}\Desktop\This PC.lnk") ; Returns null
From what I can see when I open the LNK file in a hex editor, it should return this:

Code: Select all

{20D04FE0-3AEA-1069-A2D8-08002B30309D}
Because when I put this into the Windows "Run" dialog, it opens "This PC":

Code: Select all

Shell:::{20D04FE0-3AEA-1069-A2D8-08002B30309D}
Any suggestions on how to get this string from GetShellLinkTargetPath() instead of null?
I think the paths are in the registry
HKEY_CLASSES_ROOT\CLSID\{20D04FE0-3AEA-1069-A2D8-08002B30309D}

Code: Select all

RunProgram("explorer", "::{20D04FE0-3AEA-1069-A2D8-08002B30309D}", "")
PathRequester("Open", "::{20D04FE0-3AEA-1069-A2D8-08002B30309D}")
CLSID List
highend
Enthusiast
Enthusiast
Posts: 169
Joined: Tue Jun 17, 2014 4:49 pm

Re: Information from *.lnk

Post by highend »

I'm sorry but what has this to do with normal file / folder shortcuts (which afaik don't use any special shell ids)?
Opening such a .lnk file in a hex editor just reveal normal paths, no shell ids...
AZJIO
Addict
Addict
Posts: 2192
Joined: Sun May 14, 2017 1:48 am

Re: Information from *.lnk

Post by AZJIO »

highend wrote: Tue Jun 04, 2024 10:08 am Thanks but it is NOT able to get the destination of the shortcut if it (the target) doesn't exist anymore
and the shortcuts point to the old non-existing file...
Here the author of the topic is trying binary access to the label fields. I haven't figured it out, but maybe you can do it. Previously, I used AutoIt3 and the function there returns paths even to non-existent files. Look at the example of my old program, just throw the shortcut into the program window and it will show the paths
AZJIO
Addict
Addict
Posts: 2192
Joined: Sun May 14, 2017 1:48 am

Re: Information from *.lnk

Post by AZJIO »

Example from RASHAD works with non-existent executables
https://www.purebasic.fr/english/viewto ... 81#p537581
Last edited by AZJIO on Tue Jun 04, 2024 11:04 am, edited 1 time in total.
highend
Enthusiast
Enthusiast
Posts: 169
Joined: Tue Jun 17, 2014 4:49 pm

Re: Information from *.lnk

Post by highend »

RASHAD's version worked so far (even with "broken" shortcuts) but it isn't unicode compatible.
Your version does output them as well but also only works for ascii path names...

Code: Select all

Instead of outputting this for the destination:
D:\!tests\shortcuts\@Arabic-ﻲسﺠ-characters [UTF-8 with BOM].mkv

It's doing this:
D:\!tests\shortcuts\@Arabic-???-characters [UTF-8 with BOM].mkv
AZJIO
Addict
Addict
Posts: 2192
Joined: Sun May 14, 2017 1:48 am

Re: Information from *.lnk

Post by AZJIO »

Change #PB_Ascii to #PB_UTF8

?

Code: Select all

Target$ = PeekS(*Buffer + *LinkInfo\LocalBasePathOffsetUnicode,-1,#PB_UTF8)
Target$ + PeekS(*Buffer + *LinkInfo\CommonPathSuffixOffsetUnicode,-1,#PB_UTF8)
It initially works for me, so I can’t look for the reason why it doesn’t work for you.
You have 3 characters and 3 questions are replaced. This means you are using a code page, otherwise wide characters would produce a larger number of characters, since wide is 2 bytes or more.
Try sending the result to the clipboard and pasting it into the address bar of Explorer
I created a file with the same name as you and made a shortcut and am getting questions. Now I will experiment.
highend
Enthusiast
Enthusiast
Posts: 169
Joined: Tue Jun 17, 2014 4:49 pm

Re: Information from *.lnk

Post by highend »

Thanks for the hint!

If I do it like this, both (ascii and unicode) paths are working:

Code: Select all

            *LinkInfo.LinkInfoStr = *Buffer
            unicodePath = PeekS(*Buffer + *LinkInfo\LocalBasePathOffsetUnicode, -1, #PB_Unicode)
            If Len(unicodePath) > 1
              Target$ = unicodePath
              Target$ + PeekS(*Buffer + *LinkInfo\CommonPathSuffixOffsetUnicode, -1, #PB_Unicode)
            Else
              Target$ = PeekS(*Buffer + *LinkInfo\LocalBasePathOffset, -1, #PB_Ascii)
              Target$ + PeekS(*Buffer + *LinkInfo\CommonPathSuffixOffset, -1, #PB_Ascii)
            EndIf
Don't know if this is the best way to separate unicode from non-unicode paths but at least it's currently working :)

If I'd only do the suggested replacement, paths free of any unicode chars would output only some scrambled chars...
Post Reply