This is probably a long shot, but are the LoadObjectData error codes documented anywhere publicly?

[Sparkette]

I'm trying to make a simple, compact, square Boolean constant to put in an array so it looks like a grid of pixels, using XML heap editing black magic. The most significant change I made was converting the multiCosm to a bigMultiCosm so I could color each state separately. It ended up failing to load the block diagram. This isn't a surprise, as I am after all changing data in ways it wasn't necessarily designed to handle, but it did get me curious about what the exact error was, since who knows, maybe it was something I could fix. So I turned on dprintf_logging (in Ned) and tried it again, and this was the output:

LoadObjectData error 5, [VI "lvtemporary_436621.vi" (0x000000000a3c9660)], UID 113, tag 'table' (256), dpid 0
LoadObjectData error 8, [VI "lvtemporary_436621.vi" (0x000000000a3c9660)], UID 111, tag 'partsList' (194), dpid 79
LoadObjectData error 8, [VI "lvtemporary_436621.vi" (0x000000000a3c9660)], UID 104, tag 'ddo' (52), dpid 19
LoadObjectData error 6, [VI "lvtemporary_436621.vi" (0x000000000a3c9660)], UID 110, tag 'dco' (48), dpid 21
LoadObjectData error 8, [VI "lvtemporary_436621.vi" (0x000000000a3c9660)], UID 7, tag 'termList' (268), dpid 29
LoadObjectData error 8, [VI "lvtemporary_436621.vi" (0x000000000a3c9660)], UID 3, tag 'nodeList' (164), dpid 27
LoadObjectData error 8, [VI "lvtemporary_436621.vi" (0x000000000a3c9660)], UID 2, tag 'root' (214), dpid 126

I'm guessing the answer is no, but is there any public documentation of those error codes?

Edited February 2, 2022 by flarn2006

[Rolf Kalbermatter]

On 2/2/2022 at 6:52 AM, flarn2006 said:

I'm trying to make a simple, compact, square Boolean constant to put in an array so it looks like a grid of pixels, using XML heap editing black magic. The most significant change I made was converting the multiCosm to a bigMultiCosm so I could color each state separately. It ended up failing to load the block diagram. This isn't a surprise, as I am after all changing data in ways it wasn't necessarily designed to handle, but it did get me curious about what the exact error was, since who knows, maybe it was something I could fix. So I turned on dprintf_logging (in Ned) and tried it again, and this was the output:

LoadObjectData error 5, [VI "lvtemporary_436621.vi" (0x000000000a3c9660)], UID 113, tag 'table' (256), dpid 0
LoadObjectData error 8, [VI "lvtemporary_436621.vi" (0x000000000a3c9660)], UID 111, tag 'partsList' (194), dpid 79
LoadObjectData error 8, [VI "lvtemporary_436621.vi" (0x000000000a3c9660)], UID 104, tag 'ddo' (52), dpid 19
LoadObjectData error 6, [VI "lvtemporary_436621.vi" (0x000000000a3c9660)], UID 110, tag 'dco' (48), dpid 21
LoadObjectData error 8, [VI "lvtemporary_436621.vi" (0x000000000a3c9660)], UID 7, tag 'termList' (268), dpid 29
LoadObjectData error 8, [VI "lvtemporary_436621.vi" (0x000000000a3c9660)], UID 3, tag 'nodeList' (164), dpid 27
LoadObjectData error 8, [VI "lvtemporary_436621.vi" (0x000000000a3c9660)], UID 2, tag 'root' (214), dpid 126

I'm guessing the answer is no, but is there any public documentation of those error codes?

I would guess that it uses the standard MgErr codes: 5 - file already open, 8 - permission error which might be a follow-up error, 6 - file IO error which means that something happens during reading or writing of a file that the programmer is not finding another error to map it too.

[Sparkette]

5 hours ago, Rolf Kalbermatter said:

I would guess that it uses the standard MgErr codes: 5 - file already open, 8 - permission error which might be a follow-up error, 6 - file IO error which means that something happens during reading or writing of a file that the programmer is not finding another error to map it too.

Those don't really make sense considering what I did though.

Edited February 7, 2022 by flarn2006

[Rolf Kalbermatter]

20 hours ago, flarn2006 said:

Those don't really make sense considering what I did though.

All I can say is that you are operating in the LabVIEW attic, which has many rusty nails sticking out and blank unisolated life copper wires. 😀

As Greg Mc Kaskle once said in some different words about this attic: We do reasonable efforts to protect the innocent from getting into it and getting hurt, but if someone is determined to go in there he should not complain if he gets hurt somehow.