Global replace problem

[ptc-953926]

Adepters:



Is there any way that authors can globally remove a leading space from
an element's content? We're using Arbortext 5.2, patch 70. My first
inclination was to use the replace function and select "Match markup".
If I specify the string to find as, for example:



<para>_ (where _ is a space)



the editor, indeed, finds each occurrence. However, if I then tell it
to replace the occurrence with just "<para>" (no space), the editor
reports "Region to substitute is not balanced" and then proceeds to get
hung in an infinite loop presenting me with that error window (which I
can only get out of by killing the application with Task Manager).



I've also tried editing "As XML Source", but in that window the editor
won't even find the search string. So, I'm stumped. Any ideas? I'd
like to not have to write ACL or do this external to the editor.



Dave Hintz

Siemens

[ClayHelberg]

Hi Dave--

Did you try this:

Find/Replace->

Find what: ^[space]
Find within: para
Replace with: [nothing]
Check "Match Patterns" option

The "Find what" pattern is a caret followed by a space. That tells it to look for a space as the first character of the content. It seems to do what you want, based on a quick spot-test.

--Clay

[ptc-953926]

Well, gee, I should have thought of that. Funny thing is, it doesn't
work on my machine running 5.2 patch M070. I tried it on a machine
running 5.2 patch M040 and it worked fine. Then I upgraded that machine
to patch M070 and it quit working. Did someone at PTC break regular
expressions in patch M070? Any clues as to why it wouldn't work?



Dave

[ClayHelberg]

Hi Dave--

For what it's worth, I tested it on 5.3 M030 and it worked OK there.

--Clay

[AndyEsslinger]

FYI:

I just tried it on Editor 5.3 m030 and it works fine. If they broke it
they fixed it later.

-Andy

[steve.thompson4]

Well... Not really...
Both 5.2 and 5.3 are being actively 'patched'. Not certain what the
correspondence is, but 5.2M070 was just released and 5.3 has been out
for some time (also don't remember when the 5.3 M030 patch was
released). In many cases, they're "fixing" the same problems in both
versions at the same time, but with unequal "M" numbers.
Did that make sense?

Steve Thompson
(316)977-0515

[ptc-1787870]

Hi Dave,

Clay's suggestion is great, but it sounds like your Editor version may not allow you to bask in the glory of elegance.

You might try playing with set balancedselections = off (help 1053). This can also be toggled under Tools > Preferences > Edit.

Even though the Help message says you cannot delete tags that would result in an unbalanced situation, this might be an option to try. I seem to recall that the setting changes the behavior of the find/replace dialog. All disclaimers apply.

You'll have to test this approach as I do not have 5.2M070 readily available.

Regards,
Jason

Jason Aiken
Technical Lead
InfoTrust Group, Inc.

[ptc-953926]

After further testing with 5.2 patch M070, it appears the pattern
matching find and replace doesn't work on inline tags. It works as
expected for block tags. Of course, I'd like it to work for both.