Re: BUG in [showif] using ^ (contains)
This WebDNA talk-list message is from 1997
It keeps the original formatting.
numero = 11707
interpreted = N
texte = For operators like contains and begins with, both sides should always be treated as text. Thanks for pointing this out.John.>I seen to have found a bug in the [showif] context when using ^ (contains) >as the operator ... and when both sides of the operator are numbers. I >don't really want to call it a bug, because maybe it's just something that >failed to get included in the html docs, but it's a problem nevertheless. > >The docs say that when using these operators in a showif context: > >= < > > >... and when both sides of the showif comparison happen to be numeric, the >showif will evaluate both sides as numbers. However, the docs say nothing >about this happening when the operator is ^ (contains) - and it DOES HAPPEN >... which causes an unexpected problem that everyone should be aware of ... > >When using the ^ operator in a showif or hideif context and both sides of >the comparison are number, the showif is effectively ignored - as if you >never put it there in the first place. It makes no difference what the >numbers are - the showif is ignored whether the numbers are the same or >completely different. > >The work-around is to make sure the left side does NOT look like a number >to WebCat2. To make it look like a regular string of text instead of a >number, you can simply add a letter to the left side (not the right side) >of the showif comparison like I've done below. > >In other words, instead of using the first technique which does NOT work: > >[showif [publicationID]^[sku]] > >... use the following example which works just fine: > >[showif z[publicationID]^[sku]] > >See? I placed a letter 'z' immediately in front of the left side of the >equation. I would imagine that the following would also work the same way: > >[showif [publicationID]z^[sku]] > >... because in either case, all you're doing is making sure WebCat knows >that the left side of the equation is NOT a number. Apparently that's all >it takes to fix this problem. > >Since I cannot imagine any situation where my work-around technique will >do the 'wrong' thing, I highly recommend that you do this whenever you >happen to be comparing two values using the ^ (contains) operator. > >Please note, I'm recommending that you do this ONLY when using the ^ >operator - not when using any other operators. And don't try using a number >instead of a letter because that won't fix a thing ... :) > >Sincerely, Ken Grome ..... ken@iav.com >http://usarea.net/home.html John A. Hill, V.P. Marketing ********************************* Pacific Coast Software * Home of the Web's best 11770 Bernardo Plaza Ct. #462 * Catalog and Merchant software San Diego, CA 92128 * http://www.smithmicro.com Phone: 619-675-1106 Fax: 675-0372 *********************************
Associated Messages, from the most recent to the oldest:
For operators like contains and begins with, both sides should always be treated as text. Thanks for pointing this out.John.>I seen to have found a bug in the
[showif] context when using ^ (contains) >as the operator ... and when both sides of the operator are numbers. I >don't really want to call it a bug, because maybe it's just something that >failed to get included in the html docs, but it's a problem nevertheless. > >The docs say that when using these operators in a showif context: > >= < > > >... and when both sides of the showif comparison happen to be numeric, the >showif will evaluate both sides as numbers. However, the docs say nothing >about this happening when the operator is ^ (contains) - and it DOES HAPPEN >... which causes an unexpected problem that everyone should be aware of ... > >When using the ^ operator in a showif or hideif context and both sides of >the comparison are number, the showif is effectively ignored - as if you >never put it there in the first place. It makes no difference what the >numbers are - the showif is ignored whether the numbers are the same or >completely different. > >The work-around is to make sure the left side does NOT look like a number >to WebCat2. To make it look like a regular string of text instead of a >number, you can simply add a letter to the left side (not the right side) >of the showif comparison like I've done below. > >In other words, instead of using the first technique which does NOT work: > >[showif [publicationID]^[sku]] > >... use the following example which works just fine: > >[showif z[publicationID]^[sku]] > >See? I placed a letter 'z' immediately in front of the left side of the >equation. I would imagine that the following would also work the same way: > >[showif [publicationID]z^[sku]] > >... because in either case, all you're doing is making sure WebCat knows >that the left side of the equation is NOT a number. Apparently that's all >it takes to fix this problem. > >Since I cannot imagine any situation where my work-around technique will >do the 'wrong' thing, I highly recommend that you do this whenever you >happen to be comparing two values using the ^ (contains) operator. > >Please note, I'm recommending that you do this ONLY when using the ^ >operator - not when using any other operators. And don't try using a number >instead of a letter because that won't fix a thing ... :) > >Sincerely, Ken Grome ..... ken@iav.com >http://usarea.net/home.html John A. Hill, V.P. Marketing ********************************* Pacific Coast Software * Home of the Web's best 11770 Bernardo Plaza Ct. #462 * Catalog and Merchant software San Diego, CA 92128 * http://www.smithmicro.com Phone: 619-675-1106 Fax: 675-0372 *********************************
John Hill
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
validatin (1998)
[OT] javascript field validation with encoded forms (2004)
[WebDNA]