No, it DOESN't have a concept of null, which is why assigning a struct member to be null causes problems. Take these three statements (including the comment).
<!--- no decalaration ---> Myvar = "hello"; Myvar = null All are very different. The first results in "myvar" being undefined. The second results in "myvar" holding a string, and the third results in "myvar" being defined, but not holding anything. Take that the next step to structures (what you're dealing with): <!--- no declaration ---> structInsert(mystruct, "mykey", "hello"); structInsert(mystruct, "mykey", null); Querying the struct for "mykey" after the first results in a key doesn't exist error, after the second results in a string, and after the third results in the weirdness you're experiencing. Of course, this code is impossible, because we can't assign null natively in CF, but stuff coming from ActionScript (or COM, or Java), CAN assign null values. CF structs are backed by a hashtable of some sort, and all Java hashtables that I've seen allow null to be inserted as a value. If the value is null for the key "mykey", the hashtable will return true when asked if the table contains a value for "mykey", but if you try to use that value, you'll get an error, because CF doesn't know how to do anything with a null value. This is exactly what you describe. If CF had the concept of NULL, this problem would go away, along with many others. Cheers, barneyb > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of David Ross > Sent: Wednesday, February 25, 2004 1:24 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Testing For [undefined struct element] > > Yes, this is exactly what's happening. CF has a concept of NULL > (otherwise how would cfdump spit out "undefined struct element"), it > just likes to throw errors before allowing you to test for it. > > Basically, I have arrived at if structkeyExists() == true and > assigning > the value into a dummy var errors, then it's null. Talk about > overhead... > > -dave > > > >>> [EMAIL PROTECTED] 2/25/2004 4:10:49 PM >>> > Actionscript (along with most other languages) has a concept of null, > but CF > doesn't. That's probably what you're running into. Definitely > something CF > needs, particularly now that we have CFCs. > > Cheers, > barneyb > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Dintenfass > > Sent: Wednesday, February 25, 2004 1:02 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [CFCDev] Testing For [undefined struct element] > > > > structKeyExists() and isDefined() should be false if it's > > truly "undefined" > > (as in CFARGUMENT with no default), so there must be some > > other state you > > are experiencing -- bummer that this is even more complicated than > we > > thought. > > > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > > Behalf Of David Ross > > > Sent: Wednesday, February 25, 2004 11:23 AM > > > To: [EMAIL PROTECTED] > > > Subject: [CFCDev] Testing For [undefined struct element] > > > > > > > > > This is along the lines of the <cfargument> tag bug? thread > > a few weeks > > > ago. I have come across a situation where I have a coldfusion > struct > > > that has [undefined struct element] in some of it's values, > > and I can't > > > figure out how to test for it. > > > > > > Basically what is happening is that my CF struct came from > > flash, and > > > in certain cases flash assigned "undefined" to certain > > object members. > > > Now my data is back in CF, and I need to test for these > "undefined" > > > values. It's pretty quirky the way CF is handling this > > situation... it > > > passes the isDefined() and structKeyExists() tests, yet > > trying to access > > > it throws and error, so I can't test it's value (I guess it > > doesn't have > > > one anyways). Is try/catch my only option? I think I can > > work around the > > > issue but was wondering if anyone has any insight... > > > > > > thanks, > > > > > > Dave > > > > ---------------------------------------------------------- > > You are subscribed to cfcdev. To unsubscribe, send an email > > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > > in the message of the email. > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported > > by Mindtool, Corporation (www.mindtool.com). > > > > An archive of the CFCDev list is available at > > www.mail-archive.com/[EMAIL PROTECTED] > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[EMAIL PROTECTED] > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[EMAIL PROTECTED] > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
