Document User Text "Date Modified" Broken?

I’m trying to build a titlebox template because I’m so tired of doing it manually for each drawing and thought I would give the Document User Text a try. Using the built-in keys, first I selected “Date” and it populated the table just fine and I put in a couple more, ModelUnits, PageName, PageNumber and then tried to put in DateModified. I cannot figure out what the trick is to get this one to populate in the table. It seems as though when I add it, it changes Date to DateModifed even though the key’s name remains “Date”. I deleted the “Date” key and inserted the DateModified key and the table was populated with a key named “Date” that if I go back into it, is actually attached to DateModified. What is going on here? Can I not have both “Date” and “DateModified” keys simultaneously or am I missing some trick to this?

Hello - I’ll test this - sounds like a bug to me…


Thank you. I just found that if I have a Date key and then insert my own key (not from the predefined list) called DateModified, it does not work and deletes the key. Something is certainly not working right.

Also broken with scale and other keywords. Put a post about this and other issues over the weekend.

LewnWorx, that is interesting. I did not have a problem manually entering a key called “Scale”. I just went back in and checked and it still is there, currently without any values, but I don’t immediately see it broken. How did the “scale” keyword break for you?

Curious you are also trying to work on a titleblock. There are posts going years back in the forums with people wanting better built in support for titleblocks. I think they should really bump that up their priority list. Who does any drafting without putting a titleblock in it? Seems like it might be something of importance/use to lots of people using Rhino.

Thanks for the report. I am able to reproduce and spotted the issue.

1 Like

Travis, did you catch my other post on this (linked above) regarding the quote formatting and inability to import key value pairs for document text as csv?

The quotes being reformatted to leading / trailing quotes (and then not working as a result) is kinda painful as you have to manually fix several quotes each time you “touch” an entry in a text object to get it to evaluate correctly and thus display the attribute or document text field correctly. Particularly painful if you’re concatenating several fields in a single text string as even one wrong quote will result in the text string returning #####

@LewnWorx I noticed that, however I was not able to repeat the import issue. are you selecting CVS or TXT import options on the import dialog or are they not available for you?

In terms of the quote formatting please send me some examples and I will take a look. I am working on text fields this month so now’s the time to fix the old and improve the new.

I spotted the issue mentioned above and was able to patch it last night. @wim validated the fix this morning and it should go out in 6.21.

Fast work Travis! Thank you, looking forward to the 6.21 update.

1 Like


I was selecting CVS import. They were showing as not available. They DO show as available for Attribute text, but not for Document text.

As for the quote formatting:

Easy to reproduce:

Here’s what one should look like:


Note that all quotes are straight (not leading or following).

Now if I bring up the edit text dialog, and attempt to modify the field (Selected all of “Checked_By” and changed it to “Dave”, i get the following:

In essence any text you touch that has a quote near it will get changed to a leading or trailing quote.

Note that the first quote remains untouched ("c70 but any quotes in text that touches anything you edit gets converted to a leading or trailing. Only solution to fix I’ve found is to manually copy a straight quote and paste that over all the altered ones. There’s no way of typing a straight quote into the dialog directly.

Unfortunately the forum parser is doing the same thing and converting them as well but if you look at the source text of the post you’ll see they’re correct.

RH-55514 is fixed in the latest Service Release Candidate