|
Short Description
|
error encountered when sending "@" to host
|
|
Entered
|
By:
PeteL
When: 1998-08-26 11:24:28 Build: 1.03.20d
|
|
Categories
|
Type:
Problem
Department: Product
Category:
3270 Datastream
|
Description
|
we have an application that has a "scratchpad" for entry of free-form text, which we have implemented as a textarea, although I don't think that has anything to do with this problem. I noticed 2 errors on the log yesterday indicating that errors were encountered trying to send particular datastreams to the host. I noticed that hey both contained "@" in the text, as in "call so-and-so @ 1-800-555-1212". Since this is the EHLLAPI key prefix, I suspect that has something to do with this problem.
|
|
|
|
Append
|
By: WindSurfer When: 1998-08-26 22:13:12 New Status:
Pending Customer
|
|
Comment
|
Is the template using TEACTION KEY or TEACTION PUTDATA? The TEACTION KEY will have a problem with the @ sign-- we can provide a function for you that will "double-up" the @, which turns it into a single @. Another trick would be for you to search for the @ with a TextFind and do the doubling-up in SurferScript.
|
|
|
|
Append
|
By: PeteL When: 1998-08-27 06:24:28 New Status:
Pending IE
|
|
Comment
|
It is using KEY - your suggestion does not seem a viable solution - it would have to be done on virtually any input field for which TEACTION KEY were used to send the data to the host. That being the case, far better for TEACTION KEY to do it instead. If it compared the @ plus character immediately following it to a table of valid EHLLAPI key sequences, it could quickly determine whether it needed to treat it as a piece of text or a key sequence.
|
|
|
|
Append
|
By: WindSurfer When: 1998-08-27 09:24:54 New Status:
Accepted
|
|
Comment
|
I think in normal circumstances that fixing the @ processing to just ignore anything that's not recognized is definitely the way it should work and we will fix this week.
However, for this particular issue, I think you will want the "TextNoEscapes" function or whatever , since any email address has a high chance of being a valid EHLLAPI escape (for example, surfer@ieinc.com has a valid @i sequence for PF18), and in comment text I think email addresses are going to come into play more and more.
|
|
|
|
Append
|
By: PeteL When: 1998-08-27 09:50:05 New Status:
Pending IE
|
|
Comment
|
agreed - that does make it a bit stickier, unless the EHLLAPI key sequences were "standalone" (prefixed and/or suffixed with a blank or something, which I don't think they necessarilly are) or "bracketted" (prefixed and/or suffixed with something other than blank). Either of those would probably alter the datastream, though, and so wouldn't be good solutions. However, in this case,
TEACTION KEY "something that includes @[eraseeof]"
the @F is not included as an escape character, it is put in there by Screensurfer's translation of the mnemonic - so how would that combine with the TextNoEscapes ?
|
|
|
|
Append
|
By: WindSurfer When: 1998-08-27 10:32:12 New Status:
Pending Customer
|
|
Comment
|
Basically-- the TextNoEscapes is used for any user input from the web page, not the entire string being passed to the function. So, you can have <TEACTION KEY '@0'+TextNoEscapes(web.line1)+'@t'+TextNoEscapes(web.line2)+'@E'>
Any @-signs in web.line1 and web.line2 will be doubled-up by the TextNoEscapes function to become double @@ signs, which the EHLLAPI processor interprets as a single @.
|
|
|
|
Append
|
By: PeteL When: 1998-08-27 11:13:34 New Status:
Pending IE
|
|
Comment
|
I know you won't like this because of the translation overhead, but personally I'd prefer to have a global setting to assume that ALL @ should be read as text, with an override capability if I want an individual KEY to read it as a key sequence. (of course the converse would be true, too, if I set the global setting to assume they were key sequences). I much prefer the mnemonics because you can read them. As you can see from your example, using TextNoEscapes will be FAR more coding overhead.
|
|
|
|
Append
|
By: WindSurfer When: 1998-08-27 11:53:00 New Status:
Accepted
|
|
Comment
|
That isn't so hard to implement, but it will be something that is done at compile time so that the default flag will be set at compile time.
Overhead isn't a big deal, since it is just a boolean flag on whether to care about @ signs or not.
Will involve a registry setting like KeyMnemonicsDefault=YES which you will have to change to NO to get the default you are looking for. Then will add an attribute to the TEACTION KEY to enable the passing of real mnemonics.
|
|
|
|
Append
|
By: PeteL When: 1998-08-27 13:17:46 New Status:
Pending IE
|
|
Comment
|
So then in my case, I could set the default to NO, then I could still do a
<TEACTION KEY "text with @ in it[enter]">
but I couldn't do
<TEACTION KEY "text with @ in it@E">
right?
The overhead I was referring to was the overhead associated with converting the square-bracket mnemonics to the EHLLAPI key sequences, not that associated with the @. You've mentioned in the past that you prefer the @-style because there's no conversion required.
|
|
|
|
Append
|
By: PeteL When: 1998-09-04 13:45:44 New Status:
Closed
|
|
Comment
|
seems to be working fine
|