View Complete Thread | FoxWeb Forum Home
Date:    Msg ID:   
From:    Thread:   
Are you using MergeTxt in conjunction with html_out to return data to the browser?  Are you also using session variables at the same time?  If yes, this is most probably the cause of your problem.  You may not mix legacy 1.x code that utilizes html_out with code that uses the Response, Session and Auth objects introduced in version 2.0.
One possible solution would be to do a search and replace for all instances of "html_out" in your code.  The new code should use the Response object instead.  For example, the following code:
html_out = "Content-type: text/html" + CHR(10) + CHR(10) + "Hi there!"
would be translated to:
Response.Write("Hi there!")
You do not need to include the content type header, unless your code returns a content type other than text/html (for example if you are returning PDF data).  Other types of headers, such as cookies will  need to be translated to use the corresponding methods of the Request object.

FoxWeb Support Team email

Sent by Bob Keller on 03/15/2005 06:16:18 AM:
I'm looking for any input regarding the running of legacy FoxWeb 1.x code on an updated FoxWeb 2.x server with the compatibility set 'ON'.
In a previous posting I noted the 'problem' of lost variables being recovered by 'refreshing' the main page.  Now it appears that there's an intermittent problem with calling pages from other pages.  The pages are all built with Xbase (FoxPro) code, and displayed using the legacy MergeTxt() function.  When looking at the HTML code on the page previous to any error, the page is missing the next page reference that is inserted programmatically based on the page it was called from.  The result is an error that "Script '.FWX' is invalid, non-existent, or has not been compiled".  There is no FoxWeb error log generated for this error.
We can only recreate this error by going directly to the calling page bypassing the main page that instantiates the session variables.  However, our users seem to be getting this error often enough to call us.  It's hard to fix something when you cannot recreate the error generated by their actions.