Occasionally, the last input feild arrives with an 
extraneous character in it. Is this a bug or a feature?
- H
From the raw html:
<pre>
<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)">

[ 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)">

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?

Thanks...

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 ?

thanks,

- H

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

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.

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.

ah ha !!

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

So what's the difference between

   IgnoreTN3270E 

and

    Basic TN3270E?  

Let me run through it again before you reply...

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

You can send to surfer@ieinc.com

Sorry for all the run-around here.

Logs on the way...
no problem - I'm causing most of the run around!
-H

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

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

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

T1_3_29J.zip --and--
T2_0_4C.zip 


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

and 
Although I've only tested a few screens,
2.0.4C seems to transition correctly, but still
has the "_" problem.

Thanks for the testing!

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.

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...

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
rare.

- H