Bug in TextPad v4.6.2?
Posted: Fri Apr 11, 2003 12:47 pm
There's a very, very annoying problem with the latest version of TextPad v4.6.2. I just updated from v4.4 and this started happening immediately (platform: W2k Pro within company Windows network) and has something to do with the way how new version locks the files or keeps them open.
We use TextPad solely for our development work and use Microsoft VisualSourceSafe for version control. Now, this is what happens with new version with defaults settings:
-in VSS, select a file and select View (editor in settings has been set up to be TextPad) -- the VSS repository is stored in network drive that I have read & write access. This normally doesn't check out the file and opens the file to the editor in read-only mode.
-by clicking the View and selecting "View SourceSafe's copy of the file" opens TextPad, but TextPad simply _freezes_ -- doesn't open the file, but becomes unresponsive to anything and hangs the VSS as well. Only way to get out of this is ctrl+alt+del and kill the TextPad. After that, the VSS continues to work normally, but TextPad wont. This happens in all of our machines, so it is not a unique problem related to my computer.
This problem doesn't happen when I select "Edit" instead of "View" and choose to copy the checked out file to the local work folder and open that one into the Textpad.
The problem can be solved by going to TextPad's preferences and checking the box "Keep files locked while editing them" under the File selection. But selecting that setting, causes another problem:
-if the "keep files locked while editing them" is checked and you choose "Edit" (not View this time) from VSS and select "Copy this file to my local folder and edit it there" (orsomethinglikethat), everything seems to work fine and TextPad doesn't crash.
-but when you've made your changes and want to check in the file and select "Check In" from VSS for the file, VSS gives you an error "File <filename> is already open" and refuses to check it in. Only way to overcome this problem is to close the file in question from TextPad and check it in again at that point.
We had to downgrade back to v4.4 because of this annoyance and we truly hope that this is solved as soon as possible.
We use TextPad solely for our development work and use Microsoft VisualSourceSafe for version control. Now, this is what happens with new version with defaults settings:
-in VSS, select a file and select View (editor in settings has been set up to be TextPad) -- the VSS repository is stored in network drive that I have read & write access. This normally doesn't check out the file and opens the file to the editor in read-only mode.
-by clicking the View and selecting "View SourceSafe's copy of the file" opens TextPad, but TextPad simply _freezes_ -- doesn't open the file, but becomes unresponsive to anything and hangs the VSS as well. Only way to get out of this is ctrl+alt+del and kill the TextPad. After that, the VSS continues to work normally, but TextPad wont. This happens in all of our machines, so it is not a unique problem related to my computer.
This problem doesn't happen when I select "Edit" instead of "View" and choose to copy the checked out file to the local work folder and open that one into the Textpad.
The problem can be solved by going to TextPad's preferences and checking the box "Keep files locked while editing them" under the File selection. But selecting that setting, causes another problem:
-if the "keep files locked while editing them" is checked and you choose "Edit" (not View this time) from VSS and select "Copy this file to my local folder and edit it there" (orsomethinglikethat), everything seems to work fine and TextPad doesn't crash.
-but when you've made your changes and want to check in the file and select "Check In" from VSS for the file, VSS gives you an error "File <filename> is already open" and refuses to check it in. Only way to overcome this problem is to close the file in question from TextPad and check it in again at that point.
We had to downgrade back to v4.4 because of this annoyance and we truly hope that this is solved as soon as possible.