Talk:LlGetListEntryType

List entries that are strings, but look like other types

(Maybe there's a shorter title for this topic?)

Most of us who have ever had to "unserialize" know that this function returns a type of TYPE_STRING when we have ["<123, 45.4, 0>"]. I have a list coming to me that is like unto ["blah", "133", "1.04"]. So far I can find out what is an integer by using this magic:

    tempStr = llList2String(raw, index);
    if ((string) ((integer) tempStr) == tempStr) { // Test for integer,
        ....
    }

An else will handle the string nicely, as anything that is not an integer/float/etc. is therefore a string... But I can't figure out how to detect a float. Any ideas?
Cron Stardust 23:21, 7 March 2007 (PST)

Using your technique to determine the type by examining the data is going to be flawed and slow. It is best to include type data in your output. Try out TightListTypeParse and TightListTypeDump on my userpage. If you are interested I'll post the Tightlist ESL header file (the advantage of that being there are extra features to the functions that aren't included by default). Strife Onizuka 05:08, 8 March 2007 (PST)

If I was programmatically controlling both ends, that would work beautifully. But I have users typing a long string that is then parsed into a list, then each element is turned into it's own datatype. I know it is a flawed system as (float) "45.4" != 45.4 but the rounding errors are something that I don't think will cause too many problems in my application.

What I figured out in answer to my own question was:

integer isFloat(string data) {
    string elem;
    
    integer len = llStringLength(data);
    for (index = 0; index < len; ++index) {
        elem = llGetSubString(data, index, index);
        if (elem != "0" &&
            elem != "1" &&
            elem != "2" &&
            elem != "3" &&
            elem != "4" &&
            elem != "5" &&
            elem != "6" &&
            elem != "7" &&
            elem != "8" &&
            elem != "9" &&
            elem != ".") {
            return FALSE;
        }
    }
    
    return TRUE;
}

I know, it's going to be slow. If there is a way to optimize, or another, better, solution...

Cron Stardust 21:09, 8 March 2007 (PST)

User input can be a problem that way. Out of curiosity, what are you scripting that you don't already know the datatype of the input? Strife Onizuka 04:24, 9 March 2007 (PST)