Community

Hi,

I have a problem with a macro which consists of three replace operations. When executed, it performs the first two but not the last one. If these replace operations are performed manually in the same sequence as the macro, they work correctly. If the first two replaces are recorded as one macro and the third replace as a second macro, then running the two macros in sequence works correctly. I just cannot get all of them to run as a single macro.

The replace operations are:
Quotation marks are added for clarity only.

I have tried the following variations: Posix-style regex, and using \n& in place of \n\0 but the result is always the same - these expressions will work if performed manually or if split into two macros, but not as a single macro.

Is it a bug or am I missing something?


Thanks,

fs

Just to make it easier to diagnose, can you provide sample of original text and expected results when done?

Also, are the three regexs listed in the same order as desired in the macro?

And lastly, when you say it doesn't run, what are the symptoms? Does not find? Does not replace? does not start? Generates error message?

I just finished running manually to see results.

My test copy was about 9 successive groups of the following 4 lines of 2 UpperCase characters, like:

AA
BB
CC
DD

-------------
My results looked like this (first line is blank):

Aa:
BBCc:
DDAa:
BBCc:
DDAa:
BBCc:
DDAa:
BBCc:
DDAa:
BBCc:
DDAa:
BBCc:
DDAa:
BBCc:
DDAa:
BBCc:
DDAa:
BBCc:DD

I just finished recording one single macro that ran and provided same results as running manually.

Posix was off, set to run on current document, did Replace All. Macro was set to run once, cursor started at top of document.

I will try to attach my macro to a PM for you to try.
===================
Back again, PM does not allow attachments. If you want to provide email address I can send to you, or I can ftp to some site if you provide me access information.

I suspect you just have a typo in your macro but you cannot see that. Please vote for editable macros at: http://www.textpad.com/forum/viewtopic.php?t=3775

Hi Bob.

Result of running macro which has all three replace operations is that is performs the first two replace operations but not the last one.

Example:

Original text:

NAMEA
Line one text.
Line two text.

NAMEB
Line three text.
Line four text.
Line five text.

Desired result (achieved when performed as three manual operations or as two separate macros):

Namea: Line one text. Line two text.
Nameb: Line three text. Line four text. Line five text.

(Blank line is not a problem)

Result of running 3 find/replace as a single macro:

Namea: Line one text. Line two text. Nameb: Line three text. Line four text. Line five text.

I don't believe it is a typo because when I record the macro I have been selecting the find/replace text from the drop-down lists so it should be exactly the same text as used when I have performed it manually.

I cannot see that I am doing anything wrong here. Each replace operation is run as a "replace all" and and the macro as "Play once".

Was originally seen with 4.4.0 but is the same with 4.7.2

Thanks for your input.

fs

Your desired results:

Namea: Line one text. Line two text.
Nameb: Line three text. Line four text. Line five text.

My manual results with your sample text:

Namea: Line one text. Line two text.
Nameb: Line three text. Line four text. Line five text.

My results running my single macro:

Namea: Line one text. Line two text.
Nameb: Line three text. Line four text. Line five text.

I did run into some problems if there were trailing spaces on the test lines.
Perhaps you need to modify the RegEx to allow for trailing spaces?

Notes on resulting lines:
Line 1 (blank) has no spaces and only has "\n".
Line 2 (Namea) ends with 2 spaces before "\n".
Line 3 (Nameb) ends with 1 space and does not have "\n" at the end of the line.

What else can I do for you? I see no problem when no trailing spaces on the lines. Am using WIN98SE and TextPad 4.7.2

Bob Hansen wrote:I see no problem when no trailing spaces on the lines.

Yes, you're right. The first replace won't work if the NAMEX line has a trailing space. As it happens, they don't in the source text so that hasn't been a problem. I can't see that trailing spaces on the other lines will present any problem (other than double-spaces which aren't a problem).

I don't know what you're doing that's different but I still can't get it to work as a single macro (and I really can't see why the last replace should be troublesome). This bothers me somewhat particularly because I only fail to get a successful result when attempting it as a single macro. Out of interest I recorded a macro which added a fourth replace operation to eliminate the double spaces - Replace (2 spaces) with (1 space). This replace doesn't occur when I run the macro. Not sure what that tells us apart from the most obvious.

In any case I've found an alternative (and perhaps better) solution which works around it. I now have: In the process of investigating this alternate solution I chanced upon another quirk in a replace operation (relating to doing an "undo" followed by a "replace next") but that was with 4.4.0, upon checking 4.7.2 it appears that the issue has been dealt with. All-in-all it leaves me with the impression that Textpad has "issues" with its implementation of regexes and/or macros. If re-working the macro implementation in Textpad results in addressing these "issues" then it gets my vote (which it already has).

Thanks again for your help and if you have any ideas as to why I might be seeing behaviour that you're not, I'm still interested in chasing this up since I would prefer to know how to avoid it in the future. I've been using 4.4.0 on Win98SE (which I will shortly upgrade to 4.7.2) but I have tested it with 4.7.2 on both Win98SE and Win2k.


fs

Another option to try?
Make 2 macros, but only need to execute one, it will call the other one.

1. Record macro2 first which does the third replace.

2. Then record Macro 1 which does the first two replaces then calls macro #2 which only does the third replace.

Just a thought. No more time now to test this out, but curious to see if it helps you, may provide additional clues.

Just copied my macro to an XP Pro system. FAILED!

This is final results on XP system:

NAMEA Line one text. Line two text. NAMEB Line three text. Line four text. Line five text.

This is all on one line. The final period is in position 97.
Will try on WIN98ME next.

Sorry to give you the good news, but I was mistaken on my last posting.

When I tried macro on WIN989ME, it was different from other 2 systems. Then realized I had spaces at end because of cut/paste from forum. I removed all the spaces at ends of lines and WIN98ME was also good.

I went back to XP, and sure enough, original had trailing spaces. I removed spaces and macro works correctly on all three: WIN98SE, SIM98ME, and WIN XP Pro.

I think that the Sensible Solution is to modify RegEx to account for trailing spaces, or do an initial Regex to remove all trailing spaces, add it to the front of your macro and you will have a 4 step macro that should work.

I tried removing all the trailing spaces before running the macro, still no go.

If you end up with trailing spaces on the NAMEX lines, removing just those should be sufficient. I really can't see that trailing spaces matter on the other lines - don't forget that I get the correct result if I do it manually or split the macro. The macros should be fine as-is for my source text.

I tried linking the macros, no change. Regardless it still doesn't explain why I'm seeing this behaviour when you're not. Maybe I should provide a detailed account of how I'm recording the macro? Perhaps you could send me a copy of the one you've recorded and I'll try it here? (email to tpcf at frogspawn dot cjb dot net)


fs

Just sent macro to you. Enjoy!

Thanks for that, Bob.

First time I tried your macro, it worked (but it wasn't on my original test material which wasn't available at the time, so I made up a small bit of test text). But then I found it still had the same problem as mine...

As best I can tell the problem is this:

If this last line of the source text ends with anything but a printable, non-whitespace character immediately followed by a newline, the last replace in the 3-replace macro won't work!

That is, if the last line ends in a space, or is an empty line (ie the document ends with a double-newline), the third replace doesn't work. Executing the third replace separately, however, works as expected. For some reason, it just fails when executed as part of that macro.

The exception to the above is if the last line doesn't end in a newline, in which case a trailing space is fine.

Very, very strange, and I've no real idea what the exact nature of the problem is in order to be able to avoid it. At one point I had thought that it might have related to my second replace resulting in a single line that was too long (with a large amount of source text) however the problem manifests itself even with very small amounts of text.

Hmm, well this definitely smacks of bug to me now. Do the Helios developers scour this list or does this need to be taken up with them somewhere else?

Thanks very much for your help, Bob.


fs

so I made up a small bit of test text

Can you provide that test2 info? I would like to try it with my macro to see if it also fails.

It was just the same as the original test text I posted earlier (I just had to do it from memory as I didn't have access to my original text or to the Internet at the time). All you need to do is remove any trailing spaces from the NAMEX lines (which is a requirement of the regex in my first replace) then on the last line of text, try it with and without a trailing space. Also make sure there is no empty line after the last line of text. In summary:

- no trailing spaces after NAMEA and NAMEB
- a blank line after the last line of text will always fail
- a trailing space on the last line (with no blank line following) will fail
- remove the trailing space on the last line (with no blank line following) will work

and of course not forgetting that the final replace operation works fine if done separately (either manually or as a separate macro) - it just doesn't work when recorded as part of the original three-replace macro.

This is obviously what you were seeing when you were having success after removing the trailing spaces - except that in a rather bizarre quirk it's only how the last line is terminated that's significant (aside from no trailing spaces on the NAMEX lines which is a pre-requisite).

If you can't reproduce it according to the above drop me another note and I'll set about sending you one of my test files. Oh, by the way, it's your macro that I've been using to perform my testing with (and thanks again for that).


fs

it's your macro that I've been using to perform my testing with (and thanks again for that).

Reminder: It may be my macro, but it is using your original RegExexpressions. Again, I think your Regex should probably be modified to deal with the trailing spaces.

Hmm, well this definitely smacks of bug to me now.

I don't think it is a bug, and I don't think it is OS sensitive. But you are closer to the source data and can work that out better than remote forum users with sample code.

Glad we got somewhere together on this......
================================
You may also be interested in this:
chrisp submitted an "online macro analyser" to a web site on 8/26/03 to dump macro code contents: http://www.overflow.dk/app/tpm/

From his instructions:

"Well this is just a scrach version for people to play with, the best/esey way to run it is to upload the file you wish to analyse, and then select it, using the web-interface.

If you what to run it on you own machine you just downloade the zip file, where the macroreader.asp is in. This can run from any machine width iis install.

It should not be a big problem to convert the script so i can run as a command line tool under windows. "

Referenced from TextPad forum: http://www.textpad.com/forum/viewtopic. ... c&start=15