Shared Variable bug when unflattening class from string

[wiebe@CARYA]

I'd at least try to clear the class mutation history. Flattening and unflattening is related to that history. If there is a bug, it might very well be related to that. That would be ironic, as the class mutation history is there to prevent version problems while (un)flattening...

See this thread for clear class mutation VI: Ideal-LabVIEW-development-PC.

And kudo this idea if you're into it: Add-right-click-option-to-delete-class-mutation-history.

[paul.r]

Have you looked at the actual strings being sent? Is the flattened string that is received the same string that was sent? If you attempt to unflatten the flattened class on the senders side, do you also get the error? 

[cirrusio]

> Have you looked at the actual strings being sent? Is the flattened string that is received the same string that was sent? 

They are exactly the same and the equal comparison comes back true as well as the string lengths being equal.

> If you attempt to unflatten the flattened class on the senders side, do you also get the error? 

Nope

[paul.r]

Strange.. I assume this is in the case of your simple example as well? 

If the flattened string that is being sent is exactly the same as the string being received, it sounds like it is more of a flattening/unflattening issue than a shared variable issue, no? Another quick test would be sending the flattened string, then sending it back and verifying that they are exactly the same, and trying to unflatten on both sides with the transferred string. 

[cirrusio]

> Another quick test would be sending the flattened string, then sending it back and verifying that they are exactly the same, and trying to unflatten on both sides with the transferred string. 

So, what I found with the simple test above is that if there is a 1403 on the client side and the string is sent back, then there is a 1403 on the server side and vice-versa.

[wiebe@CARYA]

Those flattened strings are quirky. What could make a difference is whether classes are default. When a class' private data is default, the flattened data will look completely different. IIRC, only the version will be send, but it will be V0.0.0.0, indicating the default should be used. This works on each class in the hierarchy, so even it the child has changed data, the patent might not.

Just saying, if it often works and sometimes doesn't work, that might be something to narrow it down.