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:
Checkbox question (1997)
wierd crashes for multi-sendmails on NT (1997)
username/password dialogue (2001)
Help! WebCat2 bug (1997)
Review comparison by PC Magazine: Open for On-line Business (1997)
[OT] DOD again (2003)
Cumulative Shipping charge calculations - your help please. (1997)
getting images' width/height (1998)
using showpage and showcart commands (1996)
[WebDNA] Installing 7.1.702 on CentOS (2012)
same product in cart (1997)
[WebDNA] Anyone worked with Mastercard Payment Gateway Services / WebDNA (2020)
I'm having trouble using [url][interpret][math] together in lookup (1997)
[url] (1997)
WebCat2b15MacPlugin - showing [math] (1997)
Nt's Latest? (1997)
appending to my last post (1999)
Forms & Tables (1998)
Max Record length restated as maybe bug (1997)
Links inside of Text Areas (2000)