Title: String Conversion Problem

Yes, the IF statement’s rules are governed by the CALC command, so you can use mathematical constants, etc.

 

You may want to consider using the <@CHOICELIST> command, which I have found very useful, convenient, and I don’t believe will suffer from this sort of a problem.

 

Also, the statement: <@IFEQUAL <@COL 1> @@room>selected</@IF> would also be adequate to the task, shows acceptable shorthand and, again, I don’t believe it would suffer from the problem.

 

I didn’t test either of the above, however, and Witango does prefer to convert to numbers whenever doing comparative statements.

 

Robert

 


From: David Shelley [mailto:[EMAIL PROTECTED]
Sent: Friday, November 04, 2005 2:42 PM
To: [email protected]
Subject: RE: Witango-Talk: String Conversion Problem

 

That’s a weird bug. It’s apparently interpreting the E as an exponent, as in 104=104e0.

If you prefix the values in the IF tag with an ascii character it should work properly.

 

 

          <OPTION VALUE="<@col 1>"<@IF EXPR="('Room<@col NUM=1>' = 'Room<@VAR request$Room>')"> SELECTED</@IF>><@col 1></OPTION>

Dave Shelley

 

-----Original Message-----
From: Lawrence Reeve [mailto:[EMAIL PROTECTED]
Sent: Friday, November 04, 2005 2:31 PM
To: [email protected]
Subject: Witango-Talk: String Conversion Problem

 

Hello,

 

I ran into the following problem on Witango running on solaris against sybase:

 

I have a varchar(10) field called room in a table called hosts.

 

I have a form with the following select field:

<@assign scope=request name=room value='<@COLUMN "hosts.room">'>

<SELECT NAME="room" ID="room" SIZE=1>  
<OPTION VALUE=""></OPTION>
      <@rows array=roomsArray scope=request>
          <OPTION VALUE="<@col 1>"<@IF EXPR="('<@col NUM=1>' = '<@VAR request$Room>')"> SELECTED</@IF>><@col 1></OPTION>
  </@ROWS>
</SELECT>

The rooms array consists of the following values:

 

        <OPTION VALUE=""></OPTION>
      <OPTION VALUE="103E">103E</OPTION>
      <OPTION VALUE="103F">103F</OPTION>

        <OPTION VALUE="104">104</OPTION>

        <OPTION VALUE="104A">104A</OPTION>
      <OPTION VALUE="104B">104B</OPTION>
      <OPTION VALUE="104C">104C</OPTION>
      <OPTION VALUE="104D">104D</OPTION>

        <OPTION VALUE="104E">104E</OPTION>

        <OPTION VALUE="104F">104F</OPTION>
      <OPTION VALUE="104G">104G</OPTION>

        <OPTION VALUE="105">105</OPTION>

 

This works fine to display the correct room number when changed unless I select room 104. If I select room 104 and enter, '104' is entered in the database, but the form displays '104E'. The view source of the form below shows why. Both 104 and 104E are selected, and the last one is displayed.

 

<SELECT NAME="room" ID="room" SIZE=1>  
        <OPTION VALUE=""></OPTION>
      <OPTION VALUE="103E">103E</OPTION>
      <OPTION VALUE="103F">103F</OPTION>

        <OPTION VALUE="104" SELECTED>104</OPTION>

        <OPTION VALUE="1040A">1040A</OPTION>

        <OPTION VALUE="104A">104A</OPTION>
      <OPTION VALUE="104B">104B</OPTION>
      <OPTION VALUE="104C">104C</OPTION>
      <OPTION VALUE="104D">104D</OPTION>
      <OPTION VALUE="104E" SELECTED>104E</OPTION>
     <OPTION VALUE="104F">104F</OPTION>
      <OPTION VALUE="104G">104G</OPTION>
      <OPTION VALUE="105">105</OPTION>

</SELECT>

 

Since this only occurs with room numbers with an E at the end, I assume Witango is doing some kind of conversion where it reads both 104 and 104E as the same number.

 

Has anyone run into this. Is there an elegant fix?

 

 

-- 

Lawrence Reeve
[EMAIL PROTECTED]
650 604 4529

________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf

Reply via email to