Ticket #22 ( Closed )

Short Description WEBTOSCREEN seems to be doing more than it should?
Entered By: PeteL When: 1998-05-13 11:07:18 Build: 1.03.10a
Categories Type: Problem   Department: Product   Category: Not Categorized
Here is a section of a template trace:
11:49:38.715 WebToScreen- Option=""
11:49:38.715 -data Session 1 data entry complete, sending to host
11:49:38.905 -ready Session 1 AID 27 Processed (host returned)
I did not include any AID key with this - why is it going to the host, and what's it sending? Or is it just a trace that hasn't been tweaked for the new WEBTOSCREEN?
Append By: PeteL  When: 1998-05-13 11:13:56  New Status: Pending IE
Comment WEBTOSCREEN is definitely breaking some code - when I remove it, it works fine.

some further info - when I do the submit after setting the form.action, I am doing it via form.submit(), not SurferSubmit(), since I suspected SurferSubmit required an AID key, and I didn't want one processed.

Append By: PeteL  When: 1998-05-13 11:26:49  New Status: Pending IE
Comment more problems, looks like the same thing
12:18:49.863WebToScreen- Option=""
12:18:49.903POP-PUTSECTION Finish DO_ID_CARDS, rc=-1
seems to be happening on second iteration of webtoscreen, but I'm still concerned about the AID key, since if it's really sending one, that's at least a large part of what's going wrong.
Append By: WindSurfer  When: 1998-05-13 11:30:53  New Status: Accepted
Comment Looks like the internal flag is somehow being turned on which allows the AID processing in WEBTOSCREEN-- I'll check into it.

Meanwhile-- a little request, when adding code to a ticket, can you use the <pre> and </pre> tags? What you put-in is actually viewed as html, so that you can do nice formatting things, include lists and so on. The only negative, is that when you get the e-mail describing the append, we haven't figured-out yet how to have your e-mail reader process it as html...

Append By: PeteL  When: 1998-05-13 12:31:58  New Status: Pending IE
Comment some more strange stuff:
before webtoscreen, 
cpos = 483 and screen.cursoroffset = 1085 

after webtoscreen, 
cpos = 1085 and screen.cursoroffset = 0 

after setcursor, 
cpos = 1085 and screen.cursoroffset = 483
these are TESHOW results, from the following transection (I'll try to get it right in the HTML)

pretty confusing!
Append By: WindSurfer  When: 1998-05-13 13:45:41  New Status: Accepted
Comment You got it right, and to make it easier, don't worry about escaping the > since it doesn't bother anything by itself-- now just put a <P> in-between your paragraphs & you're all set!

You can also use <PRE> to make multiple line entry easy, when it should be oriented that way.

We've reproduced & fixed the WEBTOSCREEN doing the AID Enter (stupid bit trick)...cannot reproduce what you are seeing with the cursor-- one of the changes is caused by the WEBTOSCREEN doing an ENTER, since that is going to change the cursor position...but why your SETCURSOR isn't working we can't figure out, since we reproduced your template & runtime, traced it through and the web.c_pos was applied correctly!

Build at ftp://ftp.ieinc2.com/pub/surfer/ss1_3_10.zip has fix to WEBTOSCREEN in it...NOW.

Please test & if WEBTOSCREEN is now working please close this ticket.

Append By: PeteL  When: 1998-05-14 08:09:59  New Status: Pending IE
Comment WEBTOSCREEN is much better, but has a problem in the following situation:

transection that gets invoked does a WEBTOSCREEN - OK

it does a TEPUTSECTION of another transection that does a WEBTOSCREEN - NOT OK - gets rc=-1, and the following message on the screen:

SurferScript Error Encountered

Executing section transections.do_id_cards
Last recognized host connection screen nonflexx.gide
Failing Component Auto Field Write
Description of Failure Invalid Field Write at offset 1, field size 3, write data "PTR"

Current Screen Follows:

Append By: WindSurfer  When: 1998-05-14 08:27:01  New Status: Pending Customer
Comment Any chance the host screen has been advanced to a new screen that no longer has a field at ro1 1, column 1 size of 3?

This error is caused by trying to overwrite an attribute byte-- you can check the event log, which should have an entry that trys to display the area of the screen where this occurred...

Append By: PeteL  When: 1998-05-14 08:40:16  New Status: Pending IE
Comment definitely the host screen has changed, and there is no longer a field of that size/location. I guess this isn't quite as transparent as I thought! Any thoughts, other than that I have to be aware of and handle this situation? Could WEBTOSCREEN simply abort itself in this situation and let the rest of the section continue? Is that advisable? <p>BTW, I seem to have put something in my last message that really screwed up this record. I may have scraped out only some partial table definitions or something.
Append By: WindSurfer  When: 1998-05-15 07:05:02  New Status: Accepted
Comment We will directly edit your append and fix the hanging table-- interesting display!

Build 1.3.10b is being cut today-- a screen.webwritten user-accessible variable will be added, which a "hit" will reset to zero, and WEBTOSCREEN will set to 1...IF this variable is not 0, WEBTOSCREEN will not execute.

This will allow the WEBTOSCREEN to execute anywhere without affect if it already has been executed.

Append By: WindSurfer  When: 1998-05-22 15:58:09  New Status: Pending Customer
Comment Please check if this is still occurring in build 1.3.12 at ftp://ftp.ieinc2.com/pub/surfer/ss1_3_12.zip...if not, please close this ticket.
Append By: PeteL  When: 1998-05-26 08:37:06  New Status: Closed
Comment seems to be fine