|
Short Description
|
Converting text to float
|
|
Entered
|
By:
intek
When: 1999-01-05 13:49:51 Build: 1.03.27e
|
|
Categories
|
Type:
Problem
Department: Product
Category:
SurferScript
|
Description
|
Hello all,
I am not sure if this is a bug or not, but I was noticing that when setting a float with a text variable that has leading whitespace, the float becomes unpredictable. Once I scraped 43.65 with leading (and trailing) white space and the result was 5.4365e-315!
This is easy to protect against with a TextTrim(), however I thought I should mention it since TextTrim(), Len(), etc are a little hard to find in the SurferScript Reference as they are not in the Table of Contents.
jslocomb@intekinfo.com
|
|
|
|
Append
|
By: WindSurfer When: 1999-01-05 15:50:20 New Status:
Pending Customer
|
|
Comment
|
It's pretty much a bug, but it can come from a number of places-- are you actually setting from a text variable, or from a Screen() function directly?
The Screen function when called in a numeric expression has just been updated to perform the truncation for floats and integers prior to conversion.
A text variable actually uses a different conversion when providing a float value, so I'm not sure it needs fixing-- please provide a copy of the TESET tag that you are using...
Note that we just upgraded the SupportCenter, and that you can now use the clipboard to cut & paste SurferScript and HTML, and as long as you bracket with <PRE> and </PRE> tags, all of the tags inside will be escaped so that they appear correctly in the ticket views.
|
|
|
|
Append
|
By: intek When: 1999-01-05 16:58:04 New Status:
Pending IE
|
|
Comment
|
I would have to double check to be certain, but I believe the code was setting a text variable from a screen command like so:
<tedeclare aging_current text 24>
.
.
.
<teset aging_current = screen(10, 12, 24)>
<teif findtext(amt_due_now,"-") <> -1>
<teset amt_due_now_float = findtext(amt_due_now,"-")) * -1>
</teif>
I know this looks wierd, but our clients mainframe represents their "credits" as numeric values with minus signs to the immediate right of the number. Ergo, the necessary conversion.
I just threw a TextTrim() in there and everything works peachy now.
You might also want to change your javascript from converting less than '<' symbols when there is a <pre> tag present?
-jason
|
|
|
|
Append
|
By: intek When: 1999-01-05 16:59:08 New Status:
Pending IE
|
|
Comment
|
Woops. Looks like everything worked out with the < symbols after all. :)
Never mind me...
-jason
|
|
|
|
Append
|
By: WindSurfer When: 1999-01-05 17:12:48 New Status:
Accepted
|
|
Comment
|
Thanks for the interest in the < symbols-- we're playing-around with it right now, and will be switching-over to an explicit FixSamples (onBlur too nasty with Netscape and textareas-- mouse and cursor start to lose each other).
As far as this whole problem goes-- I'm setting the status of this ticket as "Accepted" that an enhancement/fix will go in that will assure that numeric conversions from text variables (and really any text source) will:
- Strip leading and trailing blanks
- Process either leading or trailing dashes as a negative indicator
|
|
|
|
Append
|
By: intek When: 1999-01-05 18:49:18 New Status:
Closed
|
|
Comment
|
Terrific!
Thanks,
-jason
|
|
|
|
Append
|
By: WindSurfer When: 1999-01-05 21:45:52 New Status:
Accepted
|
|
Comment
|
Whoops! Don't close a ticket that is in "accepted" state, or we will lose track of the enhancement--thanks anyway, but I've put it back to accepted.
|