BUG in [showif] using ^ (contains)
This WebDNA talk-list message is from 1997
It keeps the original formatting.
numero = 11705
interpreted = N
texte = 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. Idon't really want to call it a bug, because maybe it's just something thatfailed 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, theshowif will evaluate both sides as numbers. However, the docs say nothingabout 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 ofthe comparison are number, the showif is effectively ignored - as if younever put it there in the first place. It makes no difference what thenumbers are - the showif is ignored whether the numbers are the same orcompletely different.The work-around is to make sure the left side does NOT look like a numberto WebCat2. To make it look like a regular string of text instead of anumber, 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 theequation. 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 knowsthat the left side of the equation is NOT a number. Apparently that's allit takes to fix this problem.Since I cannot imagine any situation where my work-around technique willdo the 'wrong' thing, I highly recommend that you do this whenever youhappen 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 numberinstead of a letter because that won't fix a thing ... :)Sincerely, Ken Grome ..... ken@iav.comhttp://usarea.net/home.html
Associated Messages, from the most recent to the oldest:
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. Idon't really want to call it a bug, because maybe it's just something thatfailed 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, theshowif will evaluate both sides as numbers. However, the docs say nothingabout 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 ofthe comparison are number, the showif is effectively ignored - as if younever put it there in the first place. It makes no difference what thenumbers are - the showif is ignored whether the numbers are the same orcompletely different.The work-around is to make sure the left side does NOT look like a numberto WebCat2. To make it look like a regular string of text instead of anumber, 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 theequation. 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 knowsthat the left side of the equation is NOT a number. Apparently that's allit takes to fix this problem.Since I cannot imagine any situation where my work-around technique willdo the 'wrong' thing, I highly recommend that you do this whenever youhappen 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 numberinstead of a letter because that won't fix a thing ... :)Sincerely, Ken Grome ..... ken@iav.comhttp://usarea.net/home.html
Kenneth Grome
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:
WebCat2b13MacPlugIn - syntax to convert date (1997)
Search returns all, not 20 (1997)
Bug Report, maybe (1997)
[WebDNA] Cheers (2008)
Forbidden CGI Error (1997)
[WebDNA] How to use [function] (2012)
en/decrypt problem (1999)
Searching on 3 different fields (2003)
New Command prefs ... (1997)
[WebDNA] Email delivery problems? (2010)
Feature: TCPconnect via SSL (1999)
WebMerchant bomb (1998)
4.5.0 (2002)
[include] and v.email (1998)
Re:Emailer setup (1997)
multi-paragraph fields (1997)
[showif]/[hideif] question (1997)
emailer w/F2 (1997)
Help name our technology! (1997)
SMSI - MacWorld (2005)