I think your crossposting in order to get your answer. I understand you are trying to get an answer, but crossposting is considered a *no no* on lists in general. Just so you know for the next time.
Well I have been thinking about this a bit. You run into a number of troubles. If you execute the lnk on the computer the lnk is on, there will not be trouble. If you are executing the remote .lnk exists on the machine running ShellExecute() the path will not be standard as drive mapping is not always an absolute process on every system. Or do you use the fully qualified network path machine name, domain etc....?
Now I think that if you parse the .lnk with COM and execute the process with CreateProcess or ShellExecute, life maybe better.
I think you should post your code to help everybody understand. Please only upload source files (.cpp and .h files and a makefile).
I think what the starter of the thread means running the lnk files that has no path inside, something like microsoft office shortcut. The CreateProcess failed, and the IShellLink::GetPath gave empty string. "cmd start" or explorer could execute the lnk file well. anyone knows what are the API the "cmd start" using to launch the microsoft office shortcut ?
Last edited by binyo66; May 17th, 2009 at 08:36 AM.
Yes, it is an old thread and no, I still don't have an answer to my original question. (So if you find it please post it here.)
Here's what I was able to find so far:
(1) In case you're opening a short-cut to a file or anything that is represented by a non-virtual object, it works if you specify an empty string as the lpOperation parameter for ShellExecute() or lpVerb for ShellExecuteEx(). If it is a file, then use "open".
(2) In some rare cases the verb "properties" may open the properties window for a virtual short-cut.
(3) What is very annoying is that sometimes ShellExecute() and ShellExecuteEx() may return success (under Windows XP SP3) even though nothing gets opened.
(4) CreateProcess() obviously does not work on short-cuts, as well as an older alternative WinExec().
(5) I was able to open pretty much most of the shortcuts with the above approach, except the one stated below (see picture attached). Somehow none of the above approaches worked on a short-cut to a Local Area network connection (the default behavior is to show the status window of the connection), or a Dial-up Connection icon. And there's absolutely no documentation from MS to support this.
Somehow none of the above approaches worked on a short-cut to a Local Area network connection (the default behavior is to show the status window of the connection), or a Dial-up Connection icon. And there's absolutely no documentation from MS to support this.
???
Just use the CLSID. It has always worked since Windows 95 !
FYI You can parse a shortcut with COM and get all the important stuff. You can check for the existance of the lnk, the program, the working directory, whether the information in the theoretical lnk is correct...the path etc.
__________________
You can read the contents of the shortcut with COM, and then execute the program passing the parameters using CreateProcess(), all from information gleaned via COM. As I have said.
Yes, it is an old thread and no, I still don't have an answer to my original question. (So if you find it please post it here.)
Here's what I was able to find so far:
(1) In case you're opening a short-cut to a file or anything that is represented by a non-virtual object, it works if you specify an empty string as the lpOperation parameter for ShellExecute() or lpVerb for ShellExecuteEx(). If it is a file, then use "open".
(2) In some rare cases the verb "properties" may open the properties window for a virtual short-cut.
(3) What is very annoying is that sometimes ShellExecute() and ShellExecuteEx() may return success (under Windows XP SP3) even though nothing gets opened.
(4) CreateProcess() obviously does not work on short-cuts, as well as an older alternative WinExec().
(5) I was able to open pretty much most of the shortcuts with the above approach, except the one stated below (see picture attached). Somehow none of the above approaches worked on a short-cut to a Local Area network connection (the default behavior is to show the status window of the connection), or a Dial-up Connection icon. And there's absolutely no documentation from MS to support this.
ahoodin, do you think I didn't try Googling for the past year? Also, before giving that lead in your previous post did you try it yourself?
Well, if you did, you'd learn that it works only with links that have a physical file attached to them. In any other case (any shortcut to a virtual Windows object -- anything from a control panel, network connection, or, as in my case, a Local Area Network connection) will not succeed with a simple IShellLink/IPersistFile approach. If, for some reason, bradman, is able to have his link return a meaningful path with that method, then he is probably not using ShellExecute correctly. Again, all he has to do in case of a simple file link is to call it like this:
Code:
//For a file link only
if(int(ShellExecute(NULL, _T(""), lpLnkFilePath, NULL, NULL, SW_SHOW)) > 32)
{
//Success
//But NOT guaranteed that something will actually open!
}
For anyone else who doesn't have a simple file link and doesn't want to waste time trying the above-mentioned "Create and resolve a shortcut" approach, let me tell you what happens:
1. IPersistFile::Load() succeeds
2. IShellLink::Resolve() succeeds
3. IShellLink::GetPath() fails with return code of 1 and empty path
4. IShellLink::GetDescription() succeeds but returns an empty string.
Last edited by dc_2000; July 9th, 2009 at 12:00 AM.
Reason: Typos
Well the fact remains the the methods you can use to do this are part of COM. You should probably try to find some reference material on COM. Why is it that 1000 vb programmers can write a malicious script to do this easily but C++ programmers can't. We must be getting lazy, and not finding reference materials or something.
* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.