Jump to content

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


Recommended Posts

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 by flarn2006
Link to comment
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.

Link to comment
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 by flarn2006
Link to comment
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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.