REALGetPropValue* for Enumeration?

typedef uint8_t(*MyGetter)(REALobject o, long param);

Don’t forget the “long param” for property getters and use right return type.

So I’m getting a crash when using my setter - here’s what I’m doing:

        long param = FieldOffset(FileInfoClassData, fileType);
        void *getter;
        void (*setter)(REALobject, long, RBInteger);
        RBBoolean success = REALGetClassProperty(fileInstance, 1, &getter, (void **)&setter, &param, nil);
        if (success)
        {
            setter(fileInstance, param, fileType);
        }

I’m not using the getter, obviously, so I’m just passing it along to have it. I’m getting 1 back in success and my setter gets a pointer, but when I invoke it I get an EXC_BAD_ADDRESS

If you’re worried about backwards compatibility (i.e. if you wanted your plugin to be usable pre-2019r2) then use REALGetClassProperty, otherwise REALSetPropValueInteger should work just fine.

I tried doing a set with an integer and it didn’t change the value. The value for each instance I created was 0 every time. What is the data type I should be using in my struct for the class data on the plugin side? Should it be a RBInteger? I’ve also noticed that if I instantiate an instance on the Xojo side and try to set the same property my app crashes. I’m thinking I’ve messed up the declaration somehow.

My struct definition is as follows:

struct FileInfoClassData
{
    REALstring nativePath;
    RBInteger fileType;
    REALobject creationDate;
    REALobject modificationDate;
    RBUInt64 length;
};

We have an enumeration called FileInfoType declared as follows:

static const char *FileInfoEnumFields[] = {
    "Unknown = 0",
    "File = 1",
    "Folder = 2"
};

REALenum FileInfoEnums[] = {
    {"FileInfoType", NULL, REALScopeGlobal, FileInfoEnumFields, 3}
};

And then I have it declared with the REALproperty list as follows:

REALproperty FileInfoProperties[] = {
    {"", "nativePath", "String", REALconsoleSafe, REALstandardGetter, REALstandardSetter, FieldOffset(FileInfoClassData, nativePath)},
    {"", "nativeType", "FileInfoType", REALconsoleSafe, REALstandardGetter, REALstandardSetter, FieldOffset(FileInfoClassData, fileType)},
    {"", "creationDate", "Date", REALconsoleSafe, REALstandardGetter, REALstandardSetter, FieldOffset(FileInfoClassData, creationDate)},
    {"", "modificationDate", "Date", REALconsoleSafe, REALstandardGetter, REALstandardSetter, FieldOffset(FileInfoClassData, modificationDate)},
    {"", "length", "UInt64", REALconsoleSafe, REALstandardGetter, REALstandardSetter, FieldOffset(FileInfoClassData, length)}
};

and now?

If it’s your class, you can easily use ClassData macro to access the struct fields directly!?

I think you’ve uncovered a bug with Enums and using REALstandardGetter/Setter. To workaround just pass in a static function and assign it manually like Christian is suggesting. It looks like for Enums the REALstandardGetter/Setters are treating them like Objects.

Yeah, it seems like enumerations are just a no-go in general. If I use the enumeration for one of my properties, even if I can get it to work from the plugin side, it was causing strange behaviors on the Xojo side and just doing something as simple as:

dim myTest as new XFileInfo
myTest.nativeType = XFileInfo.FileInfoType.Folder

Causes the code in Xojo to crash immediately. I guess I’m just going to stop using enumerations given I’ve wasted a day on this :frowning:

Right, using REALstandardGetter/Setter with Enums is buggy, but you can workaround it by setting up the values manually

[code]static RBInteger NativeTypeGetter(REALobject instance)
{
ClassData(FieldInfoClass, instance, FieldInfoClassData, data);
return data->fileType;
}

static void NativeTypeSetter(REALobject instance, long, RBInteger value )
{
ClassData(FieldInfoClass, instance, FieldInfoClassData, data);
data->fileType = value;
}

{"", “nativeType”, “FileInfoType”, REALconsoleSafe, (REALproc)NativeTypeGetter, (REALproc)NativeTypeSetter, 0},[/code]

Okay, I’m probably just going to switch over to using constants moving forward because this seems to work fine. Thanks very much for your help troubleshooting it (both you, William, and Christian). I appreciate your time very much!