3
I was having the same problem. I finally tried XOBJ_DTYPE_OTHER and it worked just fine. So, I searched through the XoopsObject code and found the serialization issue. Then I searched these forums for an answer.
I'd have to agree with succhi that this should be transparent for symmetry purposes just as in the other data types. I should be able to just send the array when I use the assignVar or setVar instead of manually serializing it in my code first. I spent over an hour on this little bitty issue.
It would be easy to add a switch to the setVar and assignVar areas (I'd be happy to write and submit the code). But, I wonder how much usage is made of this because the "fix" would (could?) break others code. I did a quick search on the core and the modules that I regularly use. Not a lot of usage generally and NONE in the core (interesting, eh?). CBB (and likely NewBB2) and Liase are the only module usages I see (of the ones I use regularly).
I'll post it as a bug since I couldn't find it listed on SourceForge. I guess it's always possible this is by design, but there aren't any notes to that effect. How many modules will it break if we were to "fix" this?
I think for now, I'll just use the OTHER object type and examine my arrays myself. That way if it ever is dealt with, then I'll only have to change the object type in the class rather than remove a bunch of serialize() statements and worry about compatibility.
Any comments on this issue from Core developers?