Community

I'm sure the first question will be: Why am I still using TextPad 4.7.3? When I got my first Windows system, I wanted an easy to use, but powerful editor. A friend recommended TextPad 4. When TextPad 5 came out, I was ready to upgrade, but my friend advised me not to and listed all the reason I wouldn't like it. I trusted his judgement and never upgraded. To be honest, with the exception of this issue, TextPad 4.7.3 has always served my needs just fine.

Anyway...

I have made quite a few macros over the years, from simple ones such as moving a single line up or down, to much more complex ones that reformat entire files. Over the years they have always worked reliably. However recently I've noticed that they have become unreliable, but it seems completely random, and more likely to happen if my system has been up for a few days continuously, rather then being freshly booted. After a reboot, the macros seem to work fine.

For example; My macro to move lines up/down selects the current line, cuts it, moves the cursor up/down, pastes the line, then repositions the cursor at the start of the line so it can be repeated. You can hold the hotkey and the current line will move up or down in the file. In the past it always worked perfectly. Now, they may work fine, or they may just randomly delete lines and start moving other lines. When this happens, use them enough and eventually, they'll delete everything in the file. Yet open a new file, type some lines and they work perfectly.

At first I thought the macro files on the drive had gotten corrupted, so I manually re-entered them. Without even saving them, the newly created scratch macro wasn't reliable either. Reboot and everything is fine, at least for a while.

There's really no way to predict when the macros will fail, other than they never seem to misbehave if I'm demonstrating the problem to someone. Then they always work perfectly. It seems it's always when I'm in a hurry to get something done, or I trust the macro to do a complex job.

Can anyone think of anything that would cause this? I currently have 29 macros in the menu, could there be a bug where TextPad becomes unreliable if you have too many Macros? I want to get rid of some of the ones I don't use any more, but then I have to renumber the filenames (TextPad is pretty bad about suggesting filenames that are already in use) and re-assign all the hotkeys.

No other part of TextPad is giving me trouble, only the macros. Well, no new troubles.

Rekrul wrote:I'm sure the first question will be: Why am I still using TextPad 4.7.3?

The problem is: who still has such an installation to be able to reproduce your issue? Even the developers might be unable to have those anymore, let alone would release a new version of such an old branch. I know this dilemma from both perspectives: user and developer.

Rekrul wrote:To be honest, with the exception of this issue, TextPad 4.7.3 has always served my needs just fine.

While that is surely true I would miss Unicode support nowadays a lot, and I don't got that with any version older than 8, let alone its regular expression support.

Rekrul wrote:more likely to happen if my system has been up for a few days continuously

If it's the computer in whole you would have experienced issues elsewhere, too. However, running a RAM checker wouldn't be in vain.

Rekrul wrote:they may just randomly delete lines and start moving other lines

Maybe you're experiencing what I narrowed down already without getting any reply: 8.1.2: cursor position inconsistency back from search result - which brings up the question: does it happen to you also when not switching between documents?

Rekrul wrote:There's really no way to predict when the macros will fail, other than they never seem to misbehave if I'm demonstrating the problem to someone.

You have to choose between letting the system run for days being an issue or not. If yes, then it is predictable.

Rekrul wrote:I want to get rid of some of the ones I don't use any more, but then I have to renumber the filenames

This sounds like you didn't try out yourself that many options. Does it affect all macros or have you experienced it only on specific ones? Why not moving all your macro files except the first to another folder, so TextPad only has one macro left? Then try it with a "complex situation". And so on.

AmigoJack wrote:The problem is: who still has such an installation to be able to reproduce your issue? Even the developers might be unable to have those anymore, let alone would release a new version of such an old branch. I know this dilemma from both perspectives: user and developer.

I was hoping that it might be a known issue.

AmigoJack wrote:While that is surely true I would miss Unicode support nowadays a lot, and I don't got that with any version older than 8, let alone its regular expression support.

I don't really have a need for Unicode support. I only ever really edit plain text files in English.

AmigoJack wrote:If it's the computer in whole you would have experienced issues elsewhere, too. However, running a RAM checker wouldn't be in vain.

It seems that the problem with the macros is confined to the copy, cut and paste operations. I just tried in vain for about 20 minutes to create a macro that copied a line, and then used paste to create a series of commands for a batch file and sometimes the paste would work and insert the contents of the buffer and sometimes it wouldn't. There was no pattern to when it would work and when it wouldn't. I had about 25 lines that I needed to do this to and it might work on the first three, then skip five, work on one, skip four, work on two, etc. Just random.

I didn't want to reboot right now, so I decided to make a macro without using copy and paste. I manually copied the whole list and pasted in two additional copies, then I sorted the list so that all three copies of each line were grouped together. Then I created a macro that simply used the existing copies and inserted the required commands around them. That worked perfectly. Unfortunately, that's not a solution because I had to do the copy and paste manually to ensure that it worked properly, which kind of negates the convenience of using macros.

That's another thing, cut copy and paste always work properly outside of macros. They always work fine when recording a macro. It's only when they're executed as part of a macro that they fail.

Even a test macro that does something as simple as copying a line and then pasting a second copy of it, didn't work reliably.

As you say, I'm not experiencing any other issues with it, or with the computer in general, it's only the macro execution in TextPad that's affected.

In desperation, I tried a couple other programs including Notepad++, but found their macro capabilities to be sorely lacking. In particular, Notepad++ doesn't have conditional execution of the macro. You can record search as part of the macro, but whatever comes after the search will execute regardless of whether the search found anything or not. If you run the macro to the end of the file and the last occurrence of the search term is on the second line, it will just continue blindly making changes to the rest of the file. When I pointed this out, one of the contributors vigorously defended this and said that's how it should work, even though it makes the inclusion of the search function useless inside macros.

AmigoJack wrote:Maybe you're experiencing what I narrowed down already without getting any reply: 8.1.2: cursor position inconsistency back from search result - which brings up the question: does it happen to you also when not switching between documents?

That doesn't seem to be what's happening here. I can open TextPad from scratch, create a macro and it may or may not function correctly.

AmigoJack wrote:You have to choose between letting the system run for days being an issue or not. If yes, then it is predictable.

But even that isn't predictable. A while back, my system had been on for days and the macros all worked fine. Tonight I tried to create a macro from scratch and it failed. BTW, once this starts happening, all the macros using cut & paste become unreliable until I reboot. It's not as if some work and some don't.

AmigoJack wrote:This sounds like you didn't try out yourself that many options. Does it affect all macros or have you experienced it only on specific ones? Why not moving all your macro files except the first to another folder, so TextPad only has one macro left? Then try it with a "complex situation". And so on.

I just tried that and the results were inconclusive. I left a semi-complex macro, moved all the others and then tried using that Macro about ten times in a row. It worked about 90% of the time, but it did fail once.

And now I have to rebuild my macros menu since it moved them all to the inactive menu, placing them in alphabetical order, which is a problem since TextPad assigns hotkeys to menu items, not specific macros. Meaning that all the hotkeys are now assigned to the wrong macros. ARGH!

Rekrul wrote:the copy, cut and paste operations
...
a macro without using copy and paste. I manually copied the whole list and pasted in two additional copies

So your macros rely on the clipboard - interesting. Up to today and for the first half of your reply I never thought of that you mean clipboard operations are executed thru a macro.

Have you tried (when recording the macro) to do the clipboard operations (namely "cut", "copy", "paste") only by choosing their menu items? Even using more appropriate menu items (i.e. "cut other > line" or "Insert > Paste as lines"; please remember I name these menu items from a version that is far beyond 4, so they might differ or items may be missing)?

AmigoJack wrote:So your macros rely on the clipboard - interesting. Up to today and for the first half of your reply I never thought of that you mean clipboard operations are executed thru a macro.

Yes, many of my macros rely heavily on clipboard operations.

For example, I had downloaded a bunch of split files from Usenet and they came with Par2 files which would re-assemble them. I copied the names of the Par2 files (one per file) to the buffer and pasted it into Textpad, which gave me;

file1.mkv.par2
file2.mkv.par2

Etc. The Split files that needed to be joined were all named;

file1.mkv.001
file1.mkv.002
file2.mkv.001
file2.mkv.002

Etc. So I made a macro to insert the Par2 repair command at the start of the line, select to the end of the line, then move back three spaces, copy it, move to thr right one space, paste another copy, add .0* to the end, jump to the start of the line, drop down one line, insert a new blank line, put the command "del" at the start of that line, paste the buffer again, add .0*, then jump to the start of the line and drop down one line.

It should have reformatted the whole file to look like this;

phpar2 r file1.mkv.par2 file1.mkv.0*
del file1.mkv.0*
phpar2 r file2.mkv.par2 file2.mkv.0*
del file2.mkv.0*
phpar2 r file3.mkv.par2 file3.mkv.0*
del file3.mkv.0*
phpar2 r file4.mkv.par2 file4.mkv.0*
del file4.mkv.0*

Etc. Instead I'd get;

phpar2 r file1.par2 file1.mkv.0*
del file1.mkv.0*
phpar2 r file2.par2 0*
del 0*
phpar2 r file3.par2 0*
del 0*
phpar2 r file4.par2 file4.mkv.0*
del file4.mkv.0*

Etc. The buffer would randomly fail to paste.

AmigoJack wrote:Have you tried (when recording the macro) to do the clipboard operations (namely "cut", "copy", "paste") only by choosing their menu items?

Yes, I tried that. There was no difference.

AmigoJack wrote:Even using more appropriate menu items (i.e. "cut other > line" or "Insert > Paste as lines"; please remember I name these menu items from a version that is far beyond 4, so they might differ or items may be missing)?

I just tried that and they were just as unreliable.

It seems that for some reason, TextPad sometimes won't post the contents of the clipboard.

OK, something really weird just happened...

I wanted to test it and manually check the contents of the clipboard after a simple macro using cut and paste failed to work and while I was recording it, I pressed CTRL-X to cut a line, but when I pressed CTRL-V to paste it, it pasted the previous contents of the clipboard instead of the line that I just cut!

As far as I can remember, I haven't had any issues with clipboard operations in any other programs, just TextPad.

Rekrul wrote:insert the Par2 repair command at the start of the line, select to the end of the line, then move back three spaces, copy it, move to thr right one space, paste another copy, add .0* to the end, jump to the start of the line, drop down one line, insert a new blank line, put the command "del" at the start of that line, paste the buffer again, add .0*, then jump to the start of the line and drop down one line.

This is a prime example of what can be done thru a regular expression: search for ^(.*)(\.[^.]+)$ and replace with phpar2 r \1.par2 \1\2.0*\ndel \1\2.0*

Rekrul wrote:The buffer would randomly fail to paste

Most likely the opposite is the case: the clipboard content is pasted before it is filled with what you want it to be filled.

Rekrul wrote:it pasted the previous contents of the clipboard instead of the line that I just cut!

As far as I can remember, I haven't had any issues with clipboard operations in any other programs, just TextPad.

I did experience clipboard issues with other programs, especially when assigning (speak: "cut" or "copy") a large content: although the source program may have finished (speak: ready to process more input/execute other tasks) the content may not be fully assigned to the clipboard yet. Trying to paste it elsewhere (also in the current program, doesn't matter at all) just brings up the previous content. That also explains why it happens with macros (executing these steps too fast) and not when you do it (too slow).

In theory this shouldn't happen. Practically this could be a race condition or unsynchronized threads, speak: assigning the clipboard is one task that is started, but the next task (pasting from the clipboard) can be/is started without waiting for the first task to finish (although the first could have finished already). However, this can only be confirmed by the developer.

(I also imply you don't use any program that hooks to the clipboard (i.e. a clipboard viewer or some kind of clipboard history manager, or Microsoft Office's clipboard tool to store more than one clipboard content), because those can also be the culprit.)


To verify my theory you'd have to record a macro that cuts/copies text and then executes tasks that take a "long" time (i.e. type a character, then delete it, and repeat that 50 times; or call "Edit > Change case > Lower case" 50 times). After that, paste the clipboard content. Does the issue still occur? Try a macro with even longer tasks inbetween. Can't suggest you where to stop experimenting like this. If you notice a more reliable clipboard behaviour then you can at least know where it comes from.

AmigoJack wrote:This is a prime example of what can be done thru a regular expression: search for ^(.*)(\.[^.]+)$ and replace with phpar2 r \1.par2 \1\2.0*\ndel \1\2.0*

I've never been that good with using regular expressions. Every time I tried to use them, I end up spending half an hour studying the help file, doing experimental searches and even then it never quite seems to do what I want.

Besides, not all of my macros operate on lines this uniform. There's a Usenet search site called NZB King which makes broken NZB files. They don't work in any newsreader. I've reported the problem multiple times, but they're apparently going to fix it. So I wrote a macro to do it. The problem is that news readers require the number of parts to be at the end of the subject line for each post, like (1/87), but the site omits this. You can't use absolute movements because you never know how many parts a file has. You can only find that by looking to see how many parts are listed for each file. NZB files follow a rigid format, so I search for the tag that marks the end of a file, move up to the line for the last part, then since I can't know if the number will be one, two or three digits long, I make a duplicate of the line, search for the quotes proceeding the number, then delete from there to the start of the line, then I search for the quotes following the number, delete from there to the end of the line, which leaves just the number, regardless of how many digits it is. I copy it, delete that extra line, then reverse search for the subject line to that part, jump to the end, cursor back to where the number goes, insert it it in the proper format, then search for the tag for the end of that file again and move down a line so that it won't do that one over again. This is repeated to the end of the file.

Admittedly it's not foolproof. It assumes that the highest part number is always listed last, which so far seems to be the case. If it's not, it will copy and paste the wrong number. I suppose you could use a regular expression to delete the unnecessary parts of the duplicate line, but you absolutely have to copy that number and paste it in for the macro to accomplish its task.

I have a plugin for my file manager that will generate a list of files with their sizes listed over to the right. I made a macro that use block cut and paste to put the file size in front of the filename.

AmigoJack wrote:Most likely the opposite is the case: the clipboard content is pasted before it is filled with what you want it to be filled.

I did experience clipboard issues with other programs, especially when assigning (speak: "cut" or "copy") a large content: although the source program may have finished (speak: ready to process more input/execute other tasks) the content may not be fully assigned to the clipboard yet. Trying to paste it elsewhere (also in the current program, doesn't matter at all) just brings up the previous content. That also explains why it happens with macros (executing these steps too fast) and not when you do it (too slow).

When my macro would fail, it didn't post anything. All those lines with "del 0*" were where it should have pasted something. Shouldn't it have pasted the previous filename?

AmigoJack wrote:In theory this shouldn't happen. Practically this could be a race condition or unsynchronized threads, speak: assigning the clipboard is one task that is started, but the next task (pasting from the clipboard) can be/is started without waiting for the first task to finish (although the first could have finished already). However, this can only be confirmed by the developer.

I understand the theory, but what would cause this to only happen sometimes? My macro wasn't copying large amounts of data and if I reboot it will probably handle it just fine. I'd blame some other program taking up too much of the CPU, but Task Manager says that the system idle process is at 99% and everything else is sitting at 0 or 1. I don't have anything actively running, just some programs sitting in the background, like my mail client, my file manager, etc. I haven't yet tried closing everything else to see if that fixes the problem, but I will.

I have to eat my words though; After posting my last message, I tried to copy a filename from the save box in Firefox (right-click, select Save Image, press CTRL-C) and when I went to paste it into a file, I got the previous contents of the clipboard instead. However I've noticed that Firefox can get kind of sluggish at times, not responding to the Enter key when trying to save a file, but I don't know if that can affect the system's copy function.

AmigoJack wrote:(I also imply you don't use any program that hooks to the clipboard (i.e. a clipboard viewer or some kind of clipboard history manager, or Microsoft Office's clipboard tool to store more than one clipboard content), because those can also be the culprit.)

Nope, no clipboard enhancements of any kind.

AmigoJack wrote:To verify my theory you'd have to record a macro that cuts/copies text and then executes tasks that take a "long" time (i.e. type a character, then delete it, and repeat that 50 times; or call "Edit > Change case > Lower case" 50 times). After that, paste the clipboard content. Does the issue still occur? Try a macro with even longer tasks inbetween. Can't suggest you where to stop experimenting like this. If you notice a more reliable clipboard behaviour then you can at least know where it comes from.

OK, I'll try that.