I've been having a problem with lines being unwrapped by MergeTxt().  This post describes what I've been able to figure out about the problem, how I got around it, and feature request for a future FoxWeb version.

In our transition from FW 1.29 to 2.6 (big jump, I know...), we're using a mix of MergeTxt() and .fwx files.  With our hundreds of existing programs in production, but an eagerness to start implementing FW 2.6's great new features (primarily .fwx files), we are attempting some fence-straddling during the transition.

So I've got this legacy program, bulletin.prg .  At the end of the program, it calls:

Bulletin.htm is one of many legacy templates.  Within that template, there is a call to my << TopNavHeader() >> function which I've recently updated to call Server.Execute('pageheader.fwx').  (This creates a global top navigation bar.)

Pageheader.fwx is a simple .fwx file I've recently created.  Server.Execute() processes that file and generates a string with only chr(10) as the end-of-line sequences.  This is no great problem in an HTML environment, but is causing problems within MergeTxt().

MergeTxt() seems to be choking on long strings without chr(13)+chr(10) line terminators.  I searched the FoxWeb forum for this problem, and found some leads regarding to memo fields and input that starts out as very long lines, but those don't apply here...at least not with regard to the source .fwx file.  Pageheader.fwx has 60 lines, none over 80 characters wide.   A hex editor confirms the pageheader.fwx file has chr(13)+chr(10) line terminators. 

With only chr(10) line terminators, MergeTxt() runs all the intended lines together into extremely long lines.  The chr(10)'s are removed completely...not even converted to spaces or chr(13)+chr(10) sequences.  This is a minor problem, as that can eliminate white space critical to page layout.  I imagine that could do worse damage to embedded javascript, <pre> formatted text, etc...although that hasn't been an issue for any of my pages.

It appears my 60-line .fwx script is first unwrapped onto one long line, then wrapped back into lines under roughly 1024 characters long.  I say "roughly", as there are often 800-ish character lines that could have been wrapped much closer to 1024.  (That irregularity really has me scratching my head, but it's really not the issue at hand.)

What *has* been an issue for me is the new line ends that MergeTxt inserts.  I consider a major problem.  Now I'm getting a chr(13)+chr(10) injected every thousand characters or so, always replacing a space.  Being HTML, this is generally not a problem, but becomes a real problem when that space was part of quoted string.  That can render CSS, javascript, etc. completely broken.  Even worse, it is intermittent as the wrapping occurs at different places based on the length of the dynamic content coming from the database.

After more hours than I'd care to admit to my boss, I proved all the above assertions to myself.  I have fixed the problem by converting the output from Server.Execute() to replace chr(10) with chr(13)+chr(10) via strtran().  This fixes what appears to be a deficiency in MergeTxt().  This is not much of a solution, as I have to take care to apply this fix everywhere that Server.Execute() might be used.  At this time, that is only once for the header and once for the footer, but who knows what lies ahead.  Further, who knows when that particular "fix" will cause other problems in the future.



I'm posting my findings for three reasons:

1. To hopefully help anyone else having this kind of problem.

2. To invite the super folks on the FoxWeb support team to point out anything I've got completely backward or something I'm overlooking.  I'm *wide* open to suggestions of better fixes.

3. To suggest a change in how the .fwx templates are processed.  Ideally, they would preserve the EOL sequences in the source .fwx file.  On a possibly more practical level, it would be a *huge* improvement to simply always use chr(13)+chr(10) for line terminators.  Looking at the intermediate .prg files generated, it seems that would be a trivial change to the .fwx parser.  It would also be more platform-appropriate, since we're all running on Windows platforms.



I am eager to hear any insight or confirmation anyone has to offer.

-dave


ps. Of course, the ideal solution would be to get MergeTxt() to stop tinkering with long lines to start with, but I get the impression from other posts that that is more of a FoxPro issue than a FoxWeb issue, so we may be stuck with it.