Ticket #291 ( Closed )

Short Description Unwanted char "_" in feild
Entered By: JaxAce When: 1999-04-30 16:13:24 Build: 1.03.29B
Categories Type: Problem   Department: Product   Category: HTML Generation
Occasionally, the last input feild arrives with an 
extraneous character in it. Is this a bug or a feature?
- H
From the raw html:
value="_" onFocus="this.form.C_POS.value = 1492'"
Append By: JaxAce  When: 1999-04-30 16:14:49  New Status: Pending IE
[ oops, don't click that box %-]
<INPUT TYPE="TEXT" NAME="F_1492_1" MAXLENGTH=1 SIZE=1 value="_" onFocus="this.form.C_POS.value = '1492'" onKeyUp="SSkc('F_1492_1',event)">
Append By: Jitz  When: 1999-04-30 16:18:42  New Status: Pending Customer
Comment Which build are you currently running-- is it 1.3.29B?

In 1.3.29 there was a regression probably around then that didn't properly convert the dash and underscore's in single-character fields to blanks-- this is fixed in 1.3.29H.

If that isn't it, can you e-mail a diagsurf.log to surfer@ieinc.com with the screen that creates this in it?


Append By: JaxAce  When: 1999-05-04 15:00:15  New Status: Pending IE
yes, build B

oh oh - looks like build H does fix the dash problem, 
but introduces the screen transition problems described 
in tickets (284, 288) concerning V2Beta2.

The underscore problem is far less disconcerting than 
the having the transitions wrong: at least with build B,
we land on the screens expected (with SilentSynchErr set 
to 1 in the registry).

QA is going to whine about the _ in the single fields -
we do have a lot of these 

(single fields, not whiners, that is <g>)

what do you suggest ?


- H
Append By: WindSurfer  When: 1999-05-04 15:15:45  New Status: Pending Customer
Comment Do you know which is the highest 1.3.29 build without the screen transition problem? Doesn't have to be exact--we can then cut a build G that fixes the regresssion very quickly tomorrow morning.
Append By: JaxAce  When: 1999-05-04 16:22:17  New Status: Pending IE

Build C transitions OK.

Builds D thru F  have both problems
(I tried them all, twice).

Yes, build H does remove the "_"
in single-character fields.

Forgot to include another issue that should up with 
1.3.29H.  However, while testing the builds, I looked 
for it again, but I was unable to recreate it - not 
even in H.   Ah, Murphy.

The key control parm maps PGUP=PA1 (and a few other are
mapped too, as in the 101 kbd)  - these all worked fine,
until this intermittent error. Could find anything odd in
traces (sorry, they're toast now).

Diag window showed:

  "Warning: Reading Emulator HTML Form
    (Invalid user AID string: "[cursel", must begin
    with the "@" character and be a valid EHLLAPI
    AID sequence)"

- H
Append By: WindSurfer  When: 1999-05-04 21:14:39  New Status: Pending Customer
Comment Thanks for the feedback--should be able to quickly determine the transition differences between C and D.

The Cursel problem is funny-- we know what the problem is: [cursel] is not a valid mnemonic (should be [curselect]). Next question is what key is mapped to this in the sskeys.dll...we will just add [cursel] to the internal table as well as update sskeys to be correct.

Will let you know when the new build is ready.

Append By: Jitz  When: 1999-05-05 13:30:56  New Status: Pending Customer
Comment Hmmm, difference between C and D is that in D we implemented full TN3270E...which includes responses back to the host.

Can you please try with build H to set the SS CONFIG registry setting "Basic TN3270E" to 1 ?

This will keep SS operating at the same level of TN3270E support it was before, where you can specify a target LU and stuff, but you don't get into the positive response mode per-buffer.

We will also do some more tests with the traces you sent us, because they show the clock going off (transition) following a "empty write" and it shouldn't do that if your default for Screen.DefaultReadystate is IgnoreEmptyWrites.

Append By: JaxAce  When: 1999-05-05 15:35:49  New Status: Pending IE
Comment Please read next append...
Append By: JaxAce  When: 1999-05-05 15:49:12  New Status: Pending IE

ah ha !!

it's the reg setting IgnoreTN3270E = 1 
that makes the basic TN3270 screens work.

So what's the difference between



    Basic TN3270E?  

Let me run through it again before you reply...
Append By: JaxAce  When: 1999-05-05 16:36:36  New Status: Pending IE
Comment The transition problems are there in H with basic TN3270.
Append By: WindSurfer  When: 1999-05-05 16:50:06  New Status: Pending Customer
Comment There are three levels of TN3270, and the whole thing is confused by various stages of implementation over time...but the simple guide is when connecting to a full TN3270E host:
TN3270         - Set IgnoreTN3270E to 1

TN3270E Basic  - Set IgnoreTN3270E to 0
                 Set Basic TN3270E to 1

TN3270E Full   - Set IgnoreTN3270E to 0
                 Set Basic TN3270E to 0
Meanwhile, looking at the log it seems that what is happening is some conflict starting with D that has caused a problem in IgnoreEmptyWrites for your situation-- can you re-send a log under H for the latest test (with IgnoreTN3270E 0 and Basic TN3270E 1)?

You can send to surfer@ieinc.com

Sorry for all the run-around here.

Append By: JaxAce  When: 1999-05-05 17:25:16  New Status: Pending IE
Logs on the way...
no problem - I'm causing most of the run around!
Append By: WindSurfer  When: 1999-05-05 18:20:49  New Status: Pending Customer
Comment TN3270E in any mode was interfering with "IgnoreEmptyWrites" logic...surprisingly this wasn't caught until now, but probably due to the subtle nature of screen transition problems.

A fix is in on a test system-- will apply to base build tomorrow and post to ftp site when ready...

Append By: WindSurfer  When: 1999-05-07 10:59:11  New Status: Pending Customer
Comment ftp://ftp.ieinc2.com/pub/surfer/T1_3_29I.zip and ftp://ftp.ieinc2.com/pub/surfer/T2_0_4B.zip are both ready on the FTP site-- one is the V1.3 build with the IgnoreEmptyWrites fixed for TN3270E and the other is the version 2.0 version of the same.
Append By: WindSurfer  When: 1999-05-10 12:24:19  New Status: Pending Customer
Comment Err, this time we tested it (one more tweak remained for TN3270E to work properly with "IgnoreEmptyWrites").

New builds at:
ftp://ftp.ieinc2.com/pub/surfer/T1_3_29J.zip --and--

As mentioned, this time we tested the fix and confirmed that it works with your host :)

Append By: JaxAce  When: 1999-05-12 14:20:13  New Status: Pending IE
T1_3_29J.zip --and--

29J has both the transition and the "_" 
problems fixed - thanks!

Although I've only tested a few screens,
2.0.4C seems to transition correctly, but still
has the "_" problem.
Append By: WindSurfer  When: 1999-05-12 14:32:04  New Status: Pending Customer
Comment There is now an ftp://ftp.ieinc2.com/pub/surfer/t2_0_4D.zip that has the "_" fixed also...

Thanks for the testing!

Append By: JaxAce  When: 1999-05-13 11:13:24  New Status: Pending IE
You're welcome.

The 2.0.4D build works ok on transistions and the
single-wide fields no longer contain the "_". However,
it has a new glitch in parsing the field - it's
more difficult to reproduce, but I caught it in the
logs - will forward them to you all.

It places a "_+" in the second field.
Append By: WindSurfer  When: 1999-05-13 12:54:31  New Status: Pending Customer
Comment Hmmm-- Screensurfer doesn't put the "_+" there- the host does, as it looks like an edit error and it is identifying the field missing the account #?

I think to reproduce, you put in AXE with no account number on the screen you were testing.

If this is an input field, Screensurfer keeps the _ here is because it treats the "_" the same as a "-" (underscore same as dash) and if there is only one dash and data in a field, the dash is kept, since it could be a minus sign on a negative amount.

Also, when Screensurfer displays this field, it is an output field, so no suppression takes place anyway...

Append By: JaxAce  When: 1999-05-13 14:02:28  New Status: Pending IE
Can't reproduce it, as I said. Merely going to the
AXE tran doesn't cause it. 

Is it certain from the trace files that the
3270-to-html translator error, causing it to
appear to come from the host? 

I'll have to have people watch for it since it's

- H