Use a Dynamic Text Field inside a Text Field for Value Lookups?


See attached image for the specific question.
I am trying to nest a text field inside a text field which is one part of a Block. The intent in this application is to use a standard Block for the titleblock of this layout. The User text referring to a GUID (see image) hosts key/value pairs onto a piece of geometry in the Rhino model essentially functioning as a dictionary. Since I want to be able to re-use the titleblock Block on multiple layouts, I am trying to lookup the name of the assembly based on the layout Page Name. Unfortunately when attempting to do this only the Page Name was called and doesn’t appear to be able to be used as a key to lookup the value hosted on the geometry.

Is what I’m trying to do possible? If so, what syntax should I be using to properly referencing?
Please advise, thanks!
-Tim

This is not currently possible in V6. We have rewritten text fields in the V7 WIP to provide a bunch of new functionality along these lines.

In V7, you can write a text field that looks like
%<UserText("block", "keyname">%
which would grab user text from the text’s parent block

You could also write
%<UserText("layout", "keyname">%
which would grab user text from the layout that the text is being drawn in

Hi Steve thanks for getting back. I believe this is what I’m already doing with how I’m using UserText in other parts of the model. Only instead of referencing a block or layout, I’m referencing a single geometry based on it’s GUID. What I’m hoping is to be able to wrap one user text query inside another to return results relative to the layout. So in my particular case, what I hear you suggesting is to apply User Text to the Layout and then key off of that? As things change across the model / layout I was hoping to centralize the key/value pairs that all text fields refer back to streamlining updates to our drawing set. I can imagine a number of scenarios not tied to developing layouts where having a nested text field to be used as a key for another text field could be very useful indeed.

Can you point me to the latest stable build of Rhino 7 WIP to download? Just want to be sure I’m not testing off of a daily build of the platform.

We will have some level of nested text field evaluation support in V7, but we aren’t there yet. If you want more “global” key/value pairs, then you may want to consider the DocumentUserText instead.

Ok I will download the latest build and do some testing to see how things go.
Yes, we are planning to use the DocumentUserText to work similar to a “Project Information” window. Adding a simple prefix to the new Keys/Parameters helps to quickly make updates to user text related to our project. I’ll update my findings on this string if the features our found to be getting handled more effectively in R7 vs R6.
Thanks Steve!

After downloading the latest Rhino 7 WIP at the time of this post I was unable to do the nesting text field method as described in this thread. At this time the Layout does not yet have any additional fields to include properties or add custom properties to assist in managing a documentation set. Also while testing and researching there is no connection to use Grasshopper to assist managing layouts at this time. So plan to be systematic when making changes that require being propagated across an entire set.

One suggestion would be to have the ability to reuse UserText Keys (aka parameters/properties/attributes) and allow Grasshopper (or some other means) to batch apply those pre-defined Keys to multiple layouts/objects at the same time. Maybe the most scalable way to do this is having a Block definition receive a new UserText Key that when applied while editing the Block, will be available in any instance of the Block already used throughout the model. Each Block could have a different Value for that new Key but the Key would be immediately available to be filled in rather than requiring you to have to re-add the same key across every copy of the Block and potentially any new instances of that Block re-used in the future.

Food for thought, thanks all.
-T