[RESOLVED] Type library: SHELLLNK.TLB#VB5 - IShellLinkA Interface(ANSI), want upgrade to oleexp

Hi fafalone

I this ancient .tlb that I would like to upgrade to yours from ansi to unicode:

Reference=*\G{11269241-F241-11CF-BD9A-00AA00575603}#1.0#0#..\Resources\type libraries\SHELLLNK.TLB#VB 5 - IShellLinkA Interface(ANSI)

Any ideas? Here is the code, I was hoping to change a couple of letters and have it ended up pointing to your functions instead:

Private Function ResolveLink(ByVal sLnkFile As String) As String
'this is called if a file is dropped from explorer is actually a shortcut

Dim sExeFile As String
Dim lBuffLen As Long
Dim cShellLink As ShellLinkA
Dim cPersistFile As IPersistFile
Dim fd As IShellLinkA.WIN32_FIND_DATA

'Bomb out early if no valid info was passed.

If LenB(sLnkFile) Then
If LenB(Dir(sLnkFile, vbNormal Or vbArchive)) Then
'Do the magical mumbo jumbo to resolve the link.
Set cShellLink = New ShellLinkA
Set cPersistFile = cShellLink
cPersistFile.Load StrConv(sLnkFile, vbUnicode), 0&
sExeFile = Space$(255)
lBuffLen = Len(sExeFile)
cShellLink.GetPath sExeFile, lBuffLen, fd, SLGP_UNCPRIORITY
ResolveLink = Trim(sExeFile)
If InStr(1, ResolveLink, Chr$(0)) = Len(ResolveLink) Then
ResolveLink = Left$(ResolveLink, Len(ResolveLink) - 1)
End If
End If
End If

End Function

To use oleexp instead all you'd have to do is remove the reference to shelllnk.tlb and add a reference to oleexp... oleexp has ShellLinkA defined the same way.

But to upgrade to Unicode, you have to change the way strings are handled (which is true everywhere, for APIs, TLBs, everything)

So first you would remove the reference to shelllnk.tlb, and switch to ShellLinkW instead (oleexp has both A and W, and everything else in shelllnk.tlb including flags and the WIN32_FIND_DATA structures).

Then after that, yeah it's only a couple small differences... here's the function I use to get a link's path:

Code:

---

Public Function GetLinkTarget(sLNK As String) As String
Dim sTar As String
Dim pSL As ShellLinkW
Dim ipf As IPersistFile
Dim wfd As WIN32_FIND_DATAW

On Error GoTo e0

Set pSL = New ShellLinkW
Set ipf = pSL

ipf.Load sLNK, STGM_READ

sTar = String$(MAX_PATH, 0)
pSL.GetPath sTar, MAX_PATH, wfd, SLGP_UNCPRIORITY

If InStr(sTar, vbNullChar) > 2 Then
    sTar = Left$(sTar, InStr(sTar, vbNullChar) - 1)
End If
If Left$(sTar, 1) = vbNullChar Then
    GetLinkTarget = ""
Else
    GetLinkTarget = sTar
End If
 
pSL.Release
Exit Function
e0:
    Debug.Print "GetLinkTarget.Error->" & Err.Description & "(" & Err.Number & ")"
End Function

---

(Note to also use WIN32_FIND_DATAW)

I believe using spaces and Trim should be fine too, but the code above I know works.

Would need to be tested but I'm pretty sure just changing yours like this will be fine (with the shelllnk.tlb reference removed and oleexp added):

Code:

---

Private Function ResolveLink(ByVal sLnkFile As String) As String
'this is called if a file is dropped from explorer is actually a shortcut

Dim sExeFile As String
Dim lBuffLen As Long
Dim cShellLink As ShellLinkW
Dim cPersistFile As IPersistFile
Dim fd As oleexp.WIN32_FIND_DATAW

'Bomb out early if no valid info was passed.

If LenB(sLnkFile) Then
If LenB(Dir(sLnkFile, vbNormal Or vbArchive)) Then
'Do the magical mumbo jumbo to resolve the link.
Set cShellLink = New ShellLinkW
Set cPersistFile = cShellLink
cPersistFile.Load sLnkFile, 0&
sExeFile = Space$(255)
lBuffLen = Len(sExeFile)
cShellLink.GetPath sExeFile, lBuffLen, fd, SLGP_UNCPRIORITY
ResolveLink = Trim$(sExeFile)
If InStr(1, ResolveLink, Chr$(0)) = Len(ResolveLink) Then
ResolveLink = Left$(ResolveLink, Len(ResolveLink) - 1)
End If
End If
End If

End Function

---

(PS- Code is easier to read wrapped in [code] ... [/code] tags)

Thanks fafalone! I love the oleexp project. At some point I would like to the have shell folders working so the user can have an explorer-like treeview on the left preview pane and a simple listview on the right for a music playlist. If you have something like that please link. I really appreciate all the work you’ve done on this type library, it’s incredible… must’ve taken months to compile all of these APIs.

Indeed I have a shell treeview and shell browser that implement just about all the features of Explorer (they both work independently but can also be combined). For the right side I also have a much more basic project that just loads a thumbnail view of all the files in a directory into a ListView, but it doesn't support navigation or much else.

For an alternative (that unfortunately won't save you the bugs or stability issues because why would MS want people using alternatives), you can also host an actual shell managed namespace tree and browser.

Indeed took quite a while... the first version (which just added a few interfaces on top of the base project it's forked from, olelib) was in 2015... and I'm still adding things to it now with the latest release on January of this year.

Excellent. You’ve given me a lot to study. Thanks again for all your contributions to the people who won’t give up on VB6! If I am forced to use a CLR, I will C++ instead.

For what it was designed to do, nothing beats VB6 to this day. Simple GUI creation and syntax, easily combined with far more advanced and low level techniques... everything else is still nearly universally failing at the first, and many languages seem to make a game of how unnatural they can make the syntax... I guess to not have a repeat of all the people trying it out when there's a low barrier to entry, like they weren't helpless newbies themselves at one point.

That it's still so popular is an enduring testament to how badly Microsoft screwed up by not maintaining the language. They could have still done .NET, and indeed that was the original plan. My only guess is they realized nobody would use .NET if VB continued to compete with it. I still won't use it on principle.

PS- in case you missed it, the main oleexp post has a list of every sample project I've made using it, there's 51 of them right now.