About Links

[Walt Decker]

The below zip file is a continuation of the links code I supplied earlier. The zip contains launch_000.bas and penowith.exe.

The .bas code is quite a hash since I do not know what I am doing, but I think it works fairly well. It is a combination of the first code showing the desktop links from both the desktop folder and the current user folder, a directory list, and a list of exe files chosen from the selection made from the directory list.

To use it, click on a treeview button to open a layer of sub-directories. Click on a treeview lable to display a list of files contained in that directory. Select a file from the list. When all files are found that "might" pertain to the file type, i. e. file extension, the view will automatically switch to the association tab where a list of exe files that might be used to open the selected file is presented. Files CAN NOT be opened from this list.

If a selected file does not have an association the list in the association tab is one that pertains to a variety of file types.

While the app is running you will get some error messages. Ignore them; they are for reference only.

There are three windows files I have not found a way to access. These are the windows "snip and sketch", "photo view", and "3d paint." But I will keep looking.

There are three items I am interested in:

1. Does it proper list the associations on your computer?
2. Does it crash on your computer?
3. If the association list is presented as an OPENWITH window, would you prefer:
a. Just the executable name.
b. Executable name and icon.
c. Executable name, icon, and perceived data type.

Thank you.

LINKS_000.ZIP

[Walt Decker]

Mr. McLachlan:

File association and subsequently the Shell "Open" are derived from two registry keys, based on the file extension.

Not always.
Some extensions, e.g. png are not found in HKCR.
Some do not have "\SHELL\OPEN\command," but "shell\edit\command." instead.
Sometimes the sequence you describe points to the wrong app, e.g. mspaint rather than photo viewer, wordpad rather than openoffice.

One has to look at other keys also.

Mr. Roca, thank you. I am looking into the Iqueryassociations interface.

Mr. Konrad, thank you for the link. I will look into it.

[Knuth Konrad]

And if you want to dive down yourself in all the settings for file extensions, Nirsoft's FileTypeMan is a useful tool.

[José Roca]

See also: AssocQueryString

https://docs.microsoft.com/en-us/windows/win32/api/shlwapi/nf-shlwapi-assocquerystringa

[Stuart McLachlan]

I remember something like that also, Mr. Beene.

The purpose of the app in the zip is my attempt to discover from where the windows "open with" derives its information. The next step is to find with which app a particular file is associated.

File association and subsequently the Shell "Open" are derived from two registry keys, based on the file extension.
'

FUNCTION GetOpener (myfile AS WSTRING) AS WSTRING
   LOCAL retval ,hkey AS DWORD
   LOCAL wszFileType,wszOpenerCmd AS WSTRINGZ * 256
'Get file type for extension
   retval = RegOpenKeyEx(%HKEY_CLASSES_ROOT,PATHNAME$(EXTN,myfile),0,%key_query_value,hkey)
   retval = regqueryvalueex(hkey,"",0,%reg_sz,wszFileType,256)
   retval = regclosekey(hkey)
'Get default open command
   retval = RegOpenKeyEx(%HKEY_CLASSES_ROOT,wszFileType & "\SHELL\OPEN\command" ,0,%key_query_value,hkey)
   retval = regqueryvalueex(hkey,"",0,%reg_sz,wszOpenerCmd,256)
   retval = regclosekey(hkey)
   REPLACE "%1" WITH myfile IN wszOpenerCmd
'Debugging display
? "File Type:  " & wszFileType & $CRLF & $CRLF & "Open command:" & $CRLF & wszOpenerCmd,,"Opener for " & myfile

FUNCTION = wszOpenerCmd
END FUNCTION

'

[Walt Decker]

I remember something like that also, Mr. Beene.

The purpose of the app in the zip is my attempt to discover from where the windows "open with" derives its information. The next step is to find with which app a particular file is associated.

[Gary Beene]

Howdy, Walt!

I seem to recall using a custom "Send To" with some success. I'll look for an example. What I remember seems to be less complicated than what you've described.

[Walt Decker]

I am not fond of the WIN10 implimentation of the "OPEN WITH" window; so I decided to "roll my own." In an attempt to discover where windows gets its information I first tried the routine presented in the "Programming" topic "PBCC vs. PBWIN"; however, I could never get the routine to function properly in my PBWIN10 although it functioned properly in PBCC6.

Although I am not familiar with "COM" and am not fond of OOP(Object Oriented Programming) I decided to try it in an attempt to get PBWIN10 to properly process the link files in C:\users\public\desktop. As a consequence the attached zip file is my first attempt at using "COM."

On my system it works fairly well; however, the IShellLink.GetArguments method (supposed to return the command line argument of the target app) appears to fail. This may be because (not particularly in this order):

1. I have mis-interpreted what the input should be
2. I have mis-interpreted what the output shold be
3. My registry is somewhat corrupted
4. The method is poorly designed

Another item I have found is that this:

IF Ok <> %S_OK THEN
  ShlLnk.Release
  PersFl.Release
  'ShlLnk = NOTHING
  'PersFl = NOTHING
  EXIT FUNCTION
END IF

producess a GPF (tried to read an ivalid address) in my PBWIN10 compiler but does not do so in my PBCC6 compiler. According to MS IShellLink is inherited from the base class IUNKNOWN. Therefore the Release method should be callable without a formal Iunknown prototype.

Perhaps one or more of you more knowledgeable persons can point out where I have gone wrong in function FN_GetCmdLine.

PS: Parts of the FN_ code is translated from an example from gethub.

BROWSE_LINKS.ZIP

Thank you.