Sent by David Hempy on 05/17/2004 08:44:11 PM:
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:
HTML_out = m.http_headers + MergeTxt('bulletin.htm')
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
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
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,
is intermittent as the wrapping occurs at different places based
on the length of the dynamic content coming from the database.
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.
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.
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
I am eager to hear any insight or confirmation anyone has to offer.
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.