Recently I updated from Windows 7 32-bit Home Premium to a new machine running Windows 7 64-bit Home Premium. On the old 32-bit machine I ran EditPad Pro as my plain text editor, and naturally Windows installed it in C:\Program files\. Being a 32-bit editor, on the new machine Windows installed it in C:\Program files (x86)\. At this stage I installed x2 and had no problems until I decided to upgrade EditPad to the latest version, which Windows recognized as a 64-bit application and installed into C:\Program files\. So far so good.
The latest version of EditPad Pro works well and is correctly associated with .txt files. I even checked the box in its Options to include a shortcut to it in the SendTo folder(s), and this works fine in Windows Explorer.
However, when I run x2 Lite and try to send a .txt or any other file to EditPad Pro via the SendTo folder, all I see is a shortcut with a Windows default shortcut icon (not EditPad's), and clicking the shortcut tells me the specified path (C:\Program Files (x86)\EditPadPro\...) does not exist and please check the path again.
When I repeat this using Windows Explorer, the same file opens readily when sent to EditPad Pro and the shortcut bears the correct icon.
The old directory C:\Program Files (x86)\EditPadPro\ had been deleted.
So I thought it was simply a matter of checking all the EditPro shortcuts and eliminating any that point to the old location. This was done using Windows Explorer's Search. In all the SendTo folders containing EditPad Pro icons, the icons contained the correct, current filepath (and bore the correct icon). I also searched directly for all EditPad Pro shortcuts, and all were correct. So this problem now seemed localized to x2.
Even after cleaning the registry the problem persisted. I can't send any files to EditPad Pro using x2 (though of course I can Open With this app). This seems to be a phantom shortcut known only to x2, since it does not appear in Windows Explorer.
I have not struck anything like this before and would welcome any suggestions. Running 2.1.0.2 Ansi Lite.
SendTo folder - phantom shortcut
Moderators: fgagnon, nikos, Site Mods
most probably the problem is xplorer2 lite being 32 bit. You can try the xplorer2 64 bit (free trial) here
www.zabkat.com/x2-64bit.htm
www.zabkat.com/x2-64bit.htm
There's an interesting little mystery here, as essentially this comes down to the makers of EditPad Pro creating a rather odd link file: instead of using an absolute path to their application, they embedded an environmental variable into the link creating a relative target path - which is perfectly normal and anyone could do it - except this isn't precisely what they did.
This is kind of a long explanation, but I had never seen a link have 2 different values for the same actual property before, so it took me some time to figure it out - bear with me.
The variable %ProgramFiles% derives its content from the ProgramFilesDir value under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion, which on an x64 system any 32-bit application (such as x2-Lite) would actually read from the "Windows [x86] on Windows64" registry key HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion.
Thus, from the point of view of Windows Explorer (or any other x64 programme) it returns "C:\Program Files", and predictably from x86 x2-Lite it returns "C:\Program Files (x86)".
Which is all perfectly normal, and would have been quite clear if they had simply created a regular shortcut like anyone else, because right-clicking on the properties of such a link would have revealed the environmental variable label itself, and the user would be fully aware of what they were looking at.
Instead, they decided to activate the SLDF_PREFER_ENVIRONMENT_PATH flag on the link which "Recalculates the IDList from the path with the environmental variables at load time, rather than persisting the IDList."
"What the heck does that mean?" I hear you ask.
It means that to anyone actually looking directly at the properties of the link (after right-clicking on it), they don't actually see %ProgramFiles% in the text (even though it's there), they see a pre-resolved string which is presented as a real path.
"So what?", you say. "Isn't it all the same when the smoke clears?"
Not exactly. It means that when the OP looked for the .lnk files in the Send-To folder (which incidentally is C:\Users\<UserName>\AppData\Roaming\Microsoft\Windows\SendTo\" on both x86 and x64 systems), he used Windows Explorer (since apparently he didn't know you could just use GoTo -> Special Folders -> Send To within x2 itself). And upon finding the shortcut, he went to its properties to "correct" it - except what he actually saw was the proper full path of an x64 declension - and said to himself, "WTF? This is already the correct path!".
If he had right-clicked and viewed the properties (of the exact same link) in x2-Lite he would have actually seen the "incorrect" (x86) path, and said "Ah, this is wrong, I'll just fix it", and upon clicking "Ok" would have certified a proper absolute-path to the EditPad Pro binary, and everything would have been fine as that would replace the original relative one.
So what's the moral of the story?
This is technically the fault of the makers of EditPad Pro for being clever and employing unnecessary Shell Link Data Flags - as the data in the link's "Start In" control clearly shows the x64 path solution (this time as a "real" absolute string) no matter if viewed from an x64 application or an x86 one - so they knew damn well what they were doing, and could have just created the link with that in the first place.
And why did they do this? Who knows - maybe the programmer was bored that day. In fact, it represents poor coding for as the "Send To" link is created during runtime (not during installation), the programme itself is assuming a "standard installation path", which may not be true if it had been previously customised.
Bottom line: x2-Lite was just doing what it was supposed to do (as any x86 file manager would - Q-Dir x86 responds exactly the same way) - and if the link had been a traditional one, no one would have been any the wiser. The solution is to edit the link target from within x2-Lite, not from within Win Explorer.
(As no one besides fgagnon will still be reading this far, I'll happily point out to him that I hate all members of the Entitled Generation.
Just thought I'd mention that. )
This is kind of a long explanation, but I had never seen a link have 2 different values for the same actual property before, so it took me some time to figure it out - bear with me.
The variable %ProgramFiles% derives its content from the ProgramFilesDir value under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion, which on an x64 system any 32-bit application (such as x2-Lite) would actually read from the "Windows [x86] on Windows64" registry key HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion.
Thus, from the point of view of Windows Explorer (or any other x64 programme) it returns "C:\Program Files", and predictably from x86 x2-Lite it returns "C:\Program Files (x86)".
Which is all perfectly normal, and would have been quite clear if they had simply created a regular shortcut like anyone else, because right-clicking on the properties of such a link would have revealed the environmental variable label itself, and the user would be fully aware of what they were looking at.
Instead, they decided to activate the SLDF_PREFER_ENVIRONMENT_PATH flag on the link which "Recalculates the IDList from the path with the environmental variables at load time, rather than persisting the IDList."
"What the heck does that mean?" I hear you ask.
It means that to anyone actually looking directly at the properties of the link (after right-clicking on it), they don't actually see %ProgramFiles% in the text (even though it's there), they see a pre-resolved string which is presented as a real path.
"So what?", you say. "Isn't it all the same when the smoke clears?"
Not exactly. It means that when the OP looked for the .lnk files in the Send-To folder (which incidentally is C:\Users\<UserName>\AppData\Roaming\Microsoft\Windows\SendTo\" on both x86 and x64 systems), he used Windows Explorer (since apparently he didn't know you could just use GoTo -> Special Folders -> Send To within x2 itself). And upon finding the shortcut, he went to its properties to "correct" it - except what he actually saw was the proper full path of an x64 declension - and said to himself, "WTF? This is already the correct path!".
If he had right-clicked and viewed the properties (of the exact same link) in x2-Lite he would have actually seen the "incorrect" (x86) path, and said "Ah, this is wrong, I'll just fix it", and upon clicking "Ok" would have certified a proper absolute-path to the EditPad Pro binary, and everything would have been fine as that would replace the original relative one.
So what's the moral of the story?
This is technically the fault of the makers of EditPad Pro for being clever and employing unnecessary Shell Link Data Flags - as the data in the link's "Start In" control clearly shows the x64 path solution (this time as a "real" absolute string) no matter if viewed from an x64 application or an x86 one - so they knew damn well what they were doing, and could have just created the link with that in the first place.
And why did they do this? Who knows - maybe the programmer was bored that day. In fact, it represents poor coding for as the "Send To" link is created during runtime (not during installation), the programme itself is assuming a "standard installation path", which may not be true if it had been previously customised.
Bottom line: x2-Lite was just doing what it was supposed to do (as any x86 file manager would - Q-Dir x86 responds exactly the same way) - and if the link had been a traditional one, no one would have been any the wiser. The solution is to edit the link target from within x2-Lite, not from within Win Explorer.
(As no one besides fgagnon will still be reading this far, I'll happily point out to him that I hate all members of the Entitled Generation.
Just thought I'd mention that. )
Last edited by Kilmatead on 2013 Jan 19, 16:43, edited 1 time in total.
-
FrizzleFry
- Platinum Member
- Posts: 1241
- Joined: 2005 Oct 16, 19:09
Well, it was an interesting conundrum - I installed the EditPad Pro utility to see if I could replicate the OP's experience, and I was quite amused to see that the exact same link file could be both correct and wrong at the same time, and how it could display two sets of conflicting details at the same time - and never having encountered a simple .lnk file that behaved like that, it begged to be investigated.FrizzleFry wrote:That must be the longest on topic (except for the last bit) message Kilmatead has ever posted
Nature abhors a vacuum, and I abhor a mystery.