On Nov 4, 2004, at 2:15 PM, Aparajita Fishman wrote:
I'm really not clear on what is happening and what the problem is. Could you please explain the source of the two CRs and what "messing up the field" means?
Desktop eForms is an application that is a cross between a spread sheet or database applications. Your create "Forms" that have cells or fields. Like a spread sheet, you can assign formulas to fields ( total_price = qty * unit_price). The application can also talk to an external database through HTTP. While we move the forms around electronically, they still get printed.
For instance, in our "Requisition" form, the ID field is set up to call 4D on opening a new form and 4D's job is to return a unique ID. That ID is used to track the form. In the forms application I just set up a cgi call to our server '/4dcgi/getid?form=req'. The 4D method gets the next id and returns it in the blob. The application gets the response and puts it in the id field. The id field is one line deep, non-scrolling field. What is happening with A4D is the unique number is send along with two CRs and the application is dumb enough to try to put 3 lines into a 1 line field - the result is a box representing the CR ("messing up the field"). (image of good/bad form at <http://mu160.aidt.edu:6502/~salex/eforms.html>)
The source of the two CRs is:
C_LONGINT($reqID)
$reqID := SeqNoGet("REQID")
set response header("Content-Type";"text/plain") ` Desktop eForm will only accept certain MIME types
write ($reqID)
Again, it has worked for years with the "Send HTML Blob" method, I was just trying to convert it to A4D.
Steve Alex
_______________________________________________ Active4D-dev mailing list [EMAIL PROTECTED] http://mailman.aparajitaworld.com/mailman/listinfo/active4d-dev Archives: http://mailman.aparajitaworld.com/archive/active4d-dev/
