TextPad 7.2.0 64 does not appear in Explorer Context Menu
Moderators: AmigoJack, bbadmin, helios, Bob Hansen, MudGuard
TextPad 7.2.0 64 does not appear in Explorer Context Menu
Installed TextPad 7.2.0 on a Windows 7 Enterprise 64-bit system. Configure | Preferences | General has the "Context menu" option checked under "Put shortcuts to TextPad on:". PC has been rebooted several times since the install of TextPad 7.2.0. Otherwise, TextPad works OK.
been there, done that (multiple times)
It already is. I indicated that in my first post, above:
| [it] has the "Context menu" option checked under "Put shortcuts to TextPad on:".
Not only that, I've checked it, rebooted, and then (when that did not work) unchecked it and rebooted, then checked it and rebooted ... all several times (I take the opportunity to check or uncheck it each time I reboot the system). I have also uninstalled and reinstalled 7.2.0 several times.
No joy.
| [it] has the "Context menu" option checked under "Put shortcuts to TextPad on:".
Not only that, I've checked it, rebooted, and then (when that did not work) unchecked it and rebooted, then checked it and rebooted ... all several times (I take the opportunity to check or uncheck it each time I reboot the system). I have also uninstalled and reinstalled 7.2.0 several times.
No joy.
Thought this was resolved in 7.2, but I guess not. Follow the instructions at the link.
http://forums.textpad.com/viewtopic.php?t=12539
http://forums.textpad.com/viewtopic.php?t=12539
(2[Bb]|[^2].|.[^Bb])
That is the question.
That is the question.
Working, but I have a new clue why it is failing
I followed the (convoluted) instructions at the referenced thread, and eventually got it working. It took several tries since I initially misinterpreted the significance of the back-to-back reverse slash characters. (They have to be there in a .REG file as part of the meta-syntax, but not there in the actual Registry data when hand-editing the Registry.) After it did not work the first time, I edited the .REG file because I figured out that the PATH in which the fix-up .REG file presumed TextPad had been installed was not where I had, in fact, installed it. But in editing the .REG file to correct that, I obviously botched the edit (apparently, from what Mr. Google tells me, blank lines are important, and of course those back-to-back reverse slash characters as well). In the end, I resorted to hand-editing the Registry, eventually getting it right with just single backslash characters, and, after a reboot, TextPad showed up on the Windows Explorer right-click context menu.
However, after going through all that, I had an idea. I never install critical, key software in the "regular" locations (one of the "Program Files" folders) -- even some Microsoft software, such as Office -- since I want to easily and simply backup subsets of "things" on my hard drive, including what I consider to be critical software. Having "stuff" installed in a set of separate locations (different root directories) simplifies backup and checking for changes made [this is easily done using the best utility program ever developed: Beyond Compare]. I had TextPad installed in path whose root folder name was longer than 8 characters and included a blank. I uninstalled TextPad, cleaned up the Registry, and started from scratch, installing it in (literally) "C:\WinApps\TextPad". Note that there are no blanks and no directory name longer than 8 characters. Doing that resulted in TextPad working correctly without having to merge a fix-up REG file or manually edit the Windows directory. However, I did have to reboot the system before it took effect, despite checking the box. But, except for the reboot (which should not have been necessary, right?), it works just fine when installed in a regular 8.3 directory name path.
Just to make sure that this was not my imagination, I went through three additional uninstall/reboot/install/reboot cycles, installing into "C:\WinApps\TextPad", and it worked every time. I conclude that there must be some problem with "long" directory names.
This system uses Windows 7 Enterprise (64-bit), with all current Microsoft Update fixes applied. It's replacing my previous 32-bit system as soon as I get everything installed on the new one. While I was at this, I ran some more experiments on the 32-bit system, since it was available for "play." TextPad 7.2 re-installed correctly on my soon-to-be-retired 32-bit Windows 7 system without any problems, both into the default path and into a path with "short" directory names.
It appears that whatever causes this behavior has something to do with a 64-bit system AND "long" directory name(s).
However, after going through all that, I had an idea. I never install critical, key software in the "regular" locations (one of the "Program Files" folders) -- even some Microsoft software, such as Office -- since I want to easily and simply backup subsets of "things" on my hard drive, including what I consider to be critical software. Having "stuff" installed in a set of separate locations (different root directories) simplifies backup and checking for changes made [this is easily done using the best utility program ever developed: Beyond Compare]. I had TextPad installed in path whose root folder name was longer than 8 characters and included a blank. I uninstalled TextPad, cleaned up the Registry, and started from scratch, installing it in (literally) "C:\WinApps\TextPad". Note that there are no blanks and no directory name longer than 8 characters. Doing that resulted in TextPad working correctly without having to merge a fix-up REG file or manually edit the Windows directory. However, I did have to reboot the system before it took effect, despite checking the box. But, except for the reboot (which should not have been necessary, right?), it works just fine when installed in a regular 8.3 directory name path.
Just to make sure that this was not my imagination, I went through three additional uninstall/reboot/install/reboot cycles, installing into "C:\WinApps\TextPad", and it worked every time. I conclude that there must be some problem with "long" directory names.
This system uses Windows 7 Enterprise (64-bit), with all current Microsoft Update fixes applied. It's replacing my previous 32-bit system as soon as I get everything installed on the new one. While I was at this, I ran some more experiments on the 32-bit system, since it was available for "play." TextPad 7.2 re-installed correctly on my soon-to-be-retired 32-bit Windows 7 system without any problems, both into the default path and into a path with "short" directory names.
It appears that whatever causes this behavior has something to do with a 64-bit system AND "long" directory name(s).
Yep, there is ... a long-outstanding bug
| I suspect there's a bug somewhere that ought to be addressed.
There most definitely is ... a long-outstanding bug. I've been dealing with this bug on various systems since my first 64-bit Windows Vista system. I was never able to get it working on any 64-bit Vista system at all. But I had the same sort of problem with other applications as well, and so, given the fact that I really didn't need a 64-bit system for any particular application (I simply wanted to try it and be at the bleeding edge), I just backed off 64 and went back to 32. When I first migrated to Windows 7 many years ago, I kept cold feet and simply installed the 32-bit version. Every time I built a Windows 7 system for someone, I installed TextPad to see if it would work correctly the first time (always with its default installation path, sad to say it now appears), but it never did. Now you can't even buy a reasonably high-performance PC without 8 GB or more RAM, and even if a box only has 4 GB, it still has 64-bit Windows 7 loaded (I suspect that's because one can usually add more RAM, so they don't want to give anyone a reason not to be able to upgrade). So everything you can buy and every PC I build pretty much is or has to be a 64-bit system; that, of course, means that the Windows Explorer context menu registry entries have to be different. Lots of software packages had trouble getting this right. But then some never burped at all. Clearly TextPad can and sometimes does install correctly and work right on other folks' 64-bit systems, which leads me to ask: what's wrong with my systems and why has it never worked for me (taking all the defaults) on any 64-bit system? That simply makes no sense. But, as I indicated in my previous message, it now works for me, every time, on every 64-bit system I've tried lately, provided I install it in a PATH where all folder names are no longer than 8 characters and contain no blanks. Why that is the case for me is beyond my pay grade.
There most definitely is ... a long-outstanding bug. I've been dealing with this bug on various systems since my first 64-bit Windows Vista system. I was never able to get it working on any 64-bit Vista system at all. But I had the same sort of problem with other applications as well, and so, given the fact that I really didn't need a 64-bit system for any particular application (I simply wanted to try it and be at the bleeding edge), I just backed off 64 and went back to 32. When I first migrated to Windows 7 many years ago, I kept cold feet and simply installed the 32-bit version. Every time I built a Windows 7 system for someone, I installed TextPad to see if it would work correctly the first time (always with its default installation path, sad to say it now appears), but it never did. Now you can't even buy a reasonably high-performance PC without 8 GB or more RAM, and even if a box only has 4 GB, it still has 64-bit Windows 7 loaded (I suspect that's because one can usually add more RAM, so they don't want to give anyone a reason not to be able to upgrade). So everything you can buy and every PC I build pretty much is or has to be a 64-bit system; that, of course, means that the Windows Explorer context menu registry entries have to be different. Lots of software packages had trouble getting this right. But then some never burped at all. Clearly TextPad can and sometimes does install correctly and work right on other folks' 64-bit systems, which leads me to ask: what's wrong with my systems and why has it never worked for me (taking all the defaults) on any 64-bit system? That simply makes no sense. But, as I indicated in my previous message, it now works for me, every time, on every 64-bit system I've tried lately, provided I install it in a PATH where all folder names are no longer than 8 characters and contain no blanks. Why that is the case for me is beyond my pay grade.
Looks like a phase of the moon bug
For reasons unrelated to this issue, I recently had occasion to install TextPad on three absolutely identical PCs with Windows 7 Pro (64-bit). TextPad won't remain on these PCs (since non-programmers will be using them), but they presented an opportunity. The very first software installed on each of these PCs (after Windows itself, McAfee anti-virus, and Microsoft Office) was TextPad. I let the install take all defaults (meaning into a path with "long" directory names), expecting failure (as usual) in each case. Just as I expected, the TextPad install on the first PC failed, but the next two worked!
My conclusion: This is a "phase of the moon" bug. I suspect the install process runs some code that is testing a random bit in memory somewhere and doing the wrong thing. This could explain why the developers can't find (and fix) the bug, since it does not happen on their PCs. Such bugs are very difficult to shoot. Perhaps they should try starting with an absolutely clean, real hardware (not virtualized) PC, with only Windows installed, and see what happens.
Reinstalling TextPad into a path with no long directory names on these three systems was successful, so I still consider it likely that installation into a path with at least one long directory name is a prerequisite to this bug's appearance. But the fact that I have now observed a successful install into such a path means that, while necessary, this is not a sufficient condition for the bug to manifest itself.
I think it's going to take a bit of luck for these guys to find this bug. It could be that the bug is not even in their code, but in the code for the installer they use (which I suspect is not something they wrote, but just license).
My conclusion: This is a "phase of the moon" bug. I suspect the install process runs some code that is testing a random bit in memory somewhere and doing the wrong thing. This could explain why the developers can't find (and fix) the bug, since it does not happen on their PCs. Such bugs are very difficult to shoot. Perhaps they should try starting with an absolutely clean, real hardware (not virtualized) PC, with only Windows installed, and see what happens.
Reinstalling TextPad into a path with no long directory names on these three systems was successful, so I still consider it likely that installation into a path with at least one long directory name is a prerequisite to this bug's appearance. But the fact that I have now observed a successful install into such a path means that, while necessary, this is not a sufficient condition for the bug to manifest itself.
I think it's going to take a bit of luck for these guys to find this bug. It could be that the bug is not even in their code, but in the code for the installer they use (which I suspect is not something they wrote, but just license).