FP 2003: Replace starts new line after inserting text

[Guest]

Hello,

I'm using FP 2003 on XP Pro. I don't remember FP doing this before, and
would be interested if it's everyone's experience with Replace in HTML.

In all attempts to Replace text in the HTML, either on a single page or
throughout a site, FP inserts the replacement text, then breaks the line,
putting the text after the insert on a new line. It doesn't cause any
rendering problems, of course, but it makes visual mincemeat of the HTML and
causes problems later when I run other editing scripts on the code that
expect text to be in certain places.

So, a) is this the common experience with FP 2003, and b), any workarounds
(within FP).

Thanks for any help,

Ian J.

 

[Steve Easton]

After you are done replacing, switch to code view, right click and select "Reformat HTML"

--
Steve Easton
Microsoft MVP FrontPage
95isalive
This site is best viewed............
........................with a computer

 

[Guest]

Thanks for your suggestion, Steve. That does work, except it reformats all
the text on the page to what looks like a 70 to 80 column width by inserting
the ASCII equivalent of a Word paragraph mark at the end of each line.
Unfortunately for me, I process the pages of my sites outside of FP using
Visual Basic scripts and don't want those extra characters in the text. I
know they're considered whitespace in HTML, but they're still ASCII to me.

I gather, then, that FP 2003 inserting a Word paragraph mark after
completing a Replace is true for all users of this version and there are no
other workarounds. FP 2002 did not do this, so I will keep my fingers
crossed this feature is taken back out in the next version, as it doesn't
seem to serve any function.

Thanks again for your help.

Ian J.

 

[Ronx]

I do not see this behaviour in the FP 2003 search/replace.

When entering the Replace string, make sure you have not entered a
carriage return as well. The cursor should be immediately after the
last character, not on the next line.

 

[Ian Jaffray]

Thanks for the info, Ron, that FP 2003 doesn't exhibit this behavior for
you.

I checked to make sure I'm not inserting a CR after the "Replace with ..."
text, and I'm not. This happens for me even if the original text line is <
70 or 80 characters. It's consistent behavior for all "Search options" in
the "Find and Replace" dialog.

Do you know of any global settings in FP that might be causing this
behavior? Also, other than a reinstall, is there a way to "reinitialize" all
FP options setting?

The version of FP I'm running is: MS Office FrontPage 2003 (11.6356.6408)
SP1.

Thanks for your help,

Ian J.

 

[Stefan B Rusynko]

Do you have your tag settings in Tools Page Option Code Formatting to
- 999 for line length
- Unselect allow line breaks within tag
--




| Thanks for the info, Ron, that FP 2003 doesn't exhibit this behavior for
| you.
|
| I checked to make sure I'm not inserting a CR after the "Replace with ..."
| text, and I'm not. This happens for me even if the original text line is <
| 70 or 80 characters. It's consistent behavior for all "Search options" in
| the "Find and Replace" dialog.
|
| Do you know of any global settings in FP that might be causing this
| behavior? Also, other than a reinstall, is there a way to "reinitialize" all
| FP options setting?
|
| The version of FP I'm running is: MS Office FrontPage 2003 (11.6356.6408)
| SP1.
|
| Thanks for your help,
|
| Ian J.
|
| | >I do not see this behaviour in the FP 2003 search/replace.
| >
| > When entering the Replace string, make sure you have not entered a
| > carriage return as well. The cursor should be immediately after the last
| > character, not on the next line.
| >
| > --
| > Ron Symonds
| > Microsoft MVP (FrontPage)
| > Reply only to group - emails will be deleted unread.
| >
| > | >> Thanks for your suggestion, Steve. That does work, except it reformats
| >> all
| >> the text on the page to what looks like a 70 to 80 column width by
| >> inserting
| >> the ASCII equivalent of a Word paragraph mark at the end of each line.
| >> Unfortunately for me, I process the pages of my sites outside of FP using
| >> Visual Basic scripts and don't want those extra characters in the text. I
| >> know they're considered whitespace in HTML, but they're still ASCII to
| >> me.
| >>
| >> I gather, then, that FP 2003 inserting a Word paragraph mark after
| >> completing a Replace is true for all users of this version and there are
| >> no
| >> other workarounds. FP 2002 did not do this, so I will keep my fingers
| >> crossed this feature is taken back out in the next version, as it doesn't
| >> seem to serve any function.
| >>
| >> Thanks again for your help.
| >>
| >> Ian J.
| >>
| >>
| >> "Steve Easton" wrote:
| >>
| >>> After you are done replacing, switch to code view, right click and
| >>> select "Reformat HTML"
| >>>
| >>> --
| >>> Steve Easton
| >>> Microsoft MVP FrontPage
| >>> 95isalive
| >>> This site is best viewed............
| >>> ........................with a computer
| >>>
| >>> | >>> > Hello,
| >>> >
| >>> > I'm using FP 2003 on XP Pro. I don't remember FP doing this before,
| >>> > and
| >>> > would be interested if it's everyone's experience with Replace in
| >>> > HTML.
| >>> >
| >>> > In all attempts to Replace text in the HTML, either on a single page
| >>> > or
| >>> > throughout a site, FP inserts the replacement text, then breaks the
| >>> > line,
| >>> > putting the text after the insert on a new line. It doesn't cause any
| >>> > rendering problems, of course, but it makes visual mincemeat of the
| >>> > HTML and
| >>> > causes problems later when I run other editing scripts on the code
| >>> > that
| >>> > expect text to be in certain places.
| >>> >
| >>> > So, a) is this the common experience with FP 2003, and b), any
| >>> > workarounds
| >>> > (within FP).
| >>> >
| >>> > Thanks for any help,
| >>> >
| >>> > Ian J.
| >>> >
| >>>
| >>>
| >>>
| >
| >
|
|

 

[Ian Jaffray]

Stefan, thank you for the reminder about line length. Mine was set to 80,
which has been OK, but 999 is a better setting for the way I want the text.
I did have "allow line breaks within tag" unselected.

However ... I did find out what was happening. Ron Symonds had told me: "...
make sure you have not entered a carriage return as well. The cursor should
be immediately after the last
character, not on the next line." And I checked to make sure this was the
case, and did have the cursor immediately after the last character of the
Replace text. BUT, what was there was an invisible line break on the next
line that I hadn't inserted, or at least I'm not sure where it came from. It
had survived all the entering of Replace text that I had done, safe on its
own second line because you cannot actually select an invisible CR in the
Replace text box once it's there. You can only delete it using the Del key.
You can see if it's there, on the second or subsequent lines by moving the
cursor there, but it does not select. So, each time I selected the Replace
text to type in something new, the line break character survived.

So, I eventually found it, by retrying Ron's suggestion, by putting the
cursor at the end of the Replace text and then hitting the Del key a couple
of times. Voila, "Find and Replace" now works again as I remember it,
without inserting the line break.

Oddly, again, the invisible line break has survived there in the Replace
text box for many months, during which time I've tried to use Find and
Replace and then hand-correcting the line breaks that were being created; I
eventually gave up and started using external scripts to do global site text
replacing.

You cannot enter a CR in the Replace (or Find) text boxes using the Enter
key (as this will run the "Find Next" command), but you can enter a line
break with Ctrl+Enter, or paste one in along with the rest of the Replace
text (which is probably what happened with me).

In my opinion, special characters in the Find and Replace text boxes should
probably be handled explicitly like they are in Word (with ^l, ^t, etc.),
but I guess they're not really considered to exist in HTML, it's only in the
FP editor that it comes up.

So, many thanks to you, Steve, Ron and Stefan for helping me figure this
out. I appreciate the creativity of your input and am very happy to get back
FP's Find and Replace function.

Ian J.