Pulling Grasshopper Metadata / Document Properties

This post is a continuation from an older post about finding the name of a Grasshopper document.

I'm attaching some Python that pulls some basic data from the document (author, date created, file path, etc.) It includes the code posted in the forum link above which lists add-on libraries currently in use, as well as their versions.

Here are my remaining questions:

Why is the addOns output listing the Grasshopper library and how can I avoid this?
Why is the addOns output not listing the Gh Python interpreter currently in use?
I would like to be able to toggle the run inputs to False and have it leave the recorded data in the output panels (instead of reverting to <null>). This way old data could remain until someone wants to intentionally overwrite it. How might I approach this?

Thanks!

Brian

Attachments:

docMetadata.gh, 14 KB

Replies to This Discussion

Permalink Reply by Giulio Piacentino on June 26, 2014 at 2:47pm

Hi again Brian

thanks for staring a new thread!

1. Because you re-wrote the libraries() function wrongly :) Just go back to the previous version, return both results and then only use the addonLibraries variable!

2. Because the code is written so that it avoids looking at itself. You can consider it with the result by commenting out line 10 in my script, that mentions: "#Ignore this component." Just move the # to the beginning of the line.

3. This is possible in Python only, but you could also use a "Data Dam" component. I would do that.

Does it help?

Thanks

Giulio
--
Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

Permalink Reply by Brian Ringley on June 26, 2014 at 4:11pm

Oh man, the data dam component is rocking my socks.

This is hugely helpful, everything is functioning correctly now. That'll teach me to modify high-quality Piacentino-code...

Thanks Giulio!

Permalink Reply by Brian Ringley on July 10, 2014 at 3:17pm

Hey Giulio,

What if I also wanted to detect user object collections in addition to core libraries and addon libraries? Would this follow a similar logic?

Thanks,

Permalink Reply by Matt McDonnell on September 15, 2015 at 7:10pm

An alternative to the data dam component could be to store the data to the document sticky thread. Accessed via scriptcontext.doc.sticky

I believe that data is saved with the document such that even if the python component or data dam component are 'accidentally' deleted the data itself is still stored in a document dictionary.

Just a thought.

Permalink Reply by Brian Ringley on September 15, 2015 at 8:35pm

Yeah good thought. Ultimately I went with the value export as txt route since the ultimate purpose would be to archive the metadata of the documents current state

Permalink Reply by Giulio Piacentino on September 16, 2015 at 8:19am

the data itself is still stored in a document dictionary.

Please remember that the sticky dictionary is just a Python dictionary in a module. It does not offer persistence. See here.

Giulio
--
Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

Permalink Reply by Matt McDonnell on September 16, 2015 at 5:32pm

Oh yes, you're correct Giulio. I did try to see if the data would remain if I was to save the file, unload grasshopper, and reopen the file and it was still there. However as you've pointed out once Rhino is closed the sticky dict is gone.

Permalink Reply by Brian Ringley on September 17, 2015 at 8:01am

So, in conclusion, write to an external database if you want stuff to be truly persistent

Permalink Reply by Anders Holden Deleuran on September 17, 2015 at 8:31am

Speaking of which, Dave Stasiuk just added a couple of components for "packing/unpacking" data to his TreeSloth plugin. You could probably do something similar in Python by pickling the data to a file I imagine..

Permalink Reply by Brian Ringley on September 17, 2015 at 9:52am

Ah cool thanks for pointing that out. In my case a simple Python *.txt export is good for now - I only need to export, no need to re-import and "unpack." I'd eventually like to write json directly to a web database for this type of thing.

import os

def writeToFile():

# create and open file

ghP = ghdoc.Path
myPath = os.path.dirname(os.path.realpath(ghP))

outputName = ghP + '_docProp.txt'

myFile = open(outputName,'w')

# pass values to file
myFile.write(str(value1) + '\n')
myFile.write(str(value2) + '\n')
myFile.write(str(value3) + '\n')

# close file
myFile.close()

# confirm file write
if os.stat(outputName).st_size > 0:
print 'File successfully written as ' + outputName
else:
print 'output file is empty - check your values'

Permalink Reply by Giulio Piacentino on September 17, 2015 at 10:53am

That's one way. Another would be to use userdata on geometry, on attributes or in a custom document-wide table.

See:
rs.SetUserText(object_id, key, value=None, attach_to_geometry=True) rs.SetUserText(object_id, key, value=None, attach_to_geometry=False) rs.SetDocumentData(section, entry, value)

or their RhinoCommon implementations for details.

Giulio
--
Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

Permalink Reply by Brian Ringley on September 15, 2015 at 3:11pm

Hey all I've updated my Pull Document Properties user object.

I fixed a few errors and added the ability to write the values to a text file.

See attached if you're interested - and let me know if you have anything to add to it or spot some n00b Python that could be more efficient.

I'd still be interested in writing a function to detect all user object names (string list), so if anyone has some tips on this please let me know.

Thanks,

Attachments: