Difference between revisions of "NULL KEY"

From Second Life Wiki
Jump to: navigation, search
(Undo revision 1180241, reads strange either way)
m (<lsl> tag to <source>)
 
Line 7: Line 7:
 
Despite fitting the syntax criteria to be a valid [[key]], when fed to a {{LSLGC|Conditional}} as a key it executes as [[FALSE]].
 
Despite fitting the syntax criteria to be a valid [[key]], when fed to a {{LSLGC|Conditional}} as a key it executes as [[FALSE]].
 
|examples=
 
|examples=
<lsl>integer isKey(key in) {
+
<source lang="lsl2">integer isKey(key in) {
 
     if(in) return 2;
 
     if(in) return 2;
 
     return (in == NULL_KEY);
 
     return (in == NULL_KEY);
}//returns 2 if it's a valid key, 1 if it's NULL_KEY</lsl>
+
}//returns 2 if it's a valid key, 1 if it's NULL_KEY</source>
<lsl>// NULL_KEY itself is evaluated as FALSE only when it is casted as a key.
+
<source lang="lsl2">// NULL_KEY itself is evaluated as FALSE only when it is casted as a key.
 
default {
 
default {
 
     state_entry() {
 
     state_entry() {
Line 20: Line 20:
 
         else                { llOwnerSay("Casted NULL_KEY is FALSE"); }// Correct.
 
         else                { llOwnerSay("Casted NULL_KEY is FALSE"); }// Correct.
 
     }
 
     }
}</lsl>
+
}</source>
 
|notes=In most situations NULL_KEY isn't needed; an empty string ("") will suffice. To take advantage of this certain practices have to be avoided. In many applications keys are checked against NULL_KEY to determine if they are valid; this is bad practice.
 
|notes=In most situations NULL_KEY isn't needed; an empty string ("") will suffice. To take advantage of this certain practices have to be avoided. In many applications keys are checked against NULL_KEY to determine if they are valid; this is bad practice.
  

Latest revision as of 16:05, 23 January 2015

Description

Constant: string NULL_KEY = "00000000-0000-0000-0000-000000000000";

The string constant NULL_KEY has the value "00000000-0000-0000-0000-000000000000"

NULL_KEY is a string. However it is only really useful as a key.

Despite fitting the syntax criteria to be a valid key, when fed to a Conditional as a key it executes as FALSE.

Related Articles

Functions

•  llAvatarOnSitTarget
•  llDetectedKey
•  llGetNotecardLine
•  llGetLandOwnerAt
•  llGetPermissionsKey
•  llGetTexture
•  llListen

Events

•  attach

Examples

integer isKey(key in) {
    if(in) return 2;
    return (in == NULL_KEY);
}//returns 2 if it's a valid key, 1 if it's NULL_KEY
// NULL_KEY itself is evaluated as FALSE only when it is casted as a key.
default {
    state_entry() {
        if (NULL_KEY) { llOwnerSay("NULL_KEY is TRUE");  }// Correct.
        else          { llOwnerSay("NULL_KEY is FALSE"); }// Never.
 
        if ((key) NULL_KEY) { llOwnerSay("Casted NULL_KEY is TRUE");  }// Never.
        else                { llOwnerSay("Casted NULL_KEY is FALSE"); }// Correct.
    }
}

Notes

Like any LSO string constants longer then 3 characters and used in multiple places in the code, they should be stored in a global variable. The result will be a considerable memory savings. This does not apply to scripts compiled with Mono. See LSL Constants vs Globals for more information about this and examples.
In most situations NULL_KEY isn't needed; an empty string ("") will suffice. To take advantage of this certain practices have to be avoided. In many applications keys are checked against NULL_KEY to determine if they are valid; this is bad practice.

LSL makes it easy to check if a key is valid. Simply use the key as the parameter for a conditional.

That is, instead of if(uuid != NULL_KEY), use if(uuid). if(uuid) will only return TRUE if it is a valid key that is also not a null key.

Deep Notes

All Issues

~ Search JIRA for related Issues
   NULL_KEY is no longer a NULL_KEY when passed to a function

Signature

string NULL_KEY = "00000000-0000-0000-0000-000000000000";

Haiku

My hopes for nothing
but for thirty two zeros,
have been dashed, four times.