Ok, but you can’t have custom fields within a sheet’s properties, just within the sheet set’s properties so what do you do if the sheet name is longer than one line?Originally Posted by sinc
|
Ok, but you can’t have custom fields within a sheet’s properties, just within the sheet set’s properties so what do you do if the sheet name is longer than one line?Originally Posted by sinc
This was the experiment that I did- I’m not trying to come off as a smart@$$, I just thought this was the best way to put everything we’ve been writing together in one spot with some background to back it all up.
Problem: Automating Sheet Title Block Information Utilizing Fields and Sheet Sets in AutoCAD 2006
Objective: To find the best method for using fields within the titleblock of a drawing to automate information and meet the following criteria.
Hypothesis: There is no way to achieve all the objectives using the current tools.
- the information must remain editable. (for modifying line breaks, etc.)
- its position within the title block should remain constant.
- its use should be intuitive and completely “hands- off”.
- the information should be included in the sheet template and properly implemented from there.
Experiment:
Constant: Sheet files are created from a template containing the intended information by using Sheet Set Manager.
Test1: create field and place in paper space in template file.
Result: The field updates upon regen, the field’s width can be modified either in its properties window or by double-clicking and entering into the text editor. Modifying a field’s width containing multiple words will cause it to break to additional lines if the width that is set is not wide enough for all of the text. The line breaks can not be customized. The field entry can be edited to include additional text as in a multi-line text object. The field’s position cannot be locked.
Test2: create field within a multi-line text object and place the object in paper space of the template file.
Result: The result of placing a field in a multi-line text object is the same as above except that (1) the width can be pre-established and (2) additional text can be entered in the template.
Test3: create a block containing multiple fields and place the block in paper space of the template file.
Result: the fields do not update upon nor do they propagate the intended information at the initial insertion of the block object. This is because the block’s contents are not editable in the drawing therefore the fields aren’t actively attempting to read any information. Each field’s position is locked in place relative to the other fields. The block can be made non-explodable to preserve its content’s relative position. The fields’ widths and multiple-line properties are editable as described above.
Test3a: edit block in block editor to update fields
Result: The fields do not update in the block editor because entering the BE exits the current drawing space. The fields’ relative position is editable within the BE.
Test3b: edit block in place to update fields
Result: The fields update upon regen. The fields’ relative position is editable while editing in-place.
Test4: create a block containing multiple attributes. Each attribute contains a field. The block is placed in paper space of the template file.
Result: The fields update upon initial insertion and upon drawing regen. This is because the attribute information of a block is editable and live in the drawing environment without having to enter into the BE or by editing the block in place, therefore the fields are actively reading their intended information. The attribute’s position within the block can be locked preventing accidental misplacement. Attributes do not have multi-line capabilities and their width cannot be controlled.
Conclusion: By using fields placed within attributes of the titleblock we are able to automate the completion of the title information and lock their positions within the block maintaining a consistent appearance. Information that is too large for its intended space is dealt with by providing multiple attributes in place of multiple lines of text. The user must re-enter the automatically populated information to maintain proper titleblock structure. Requiring the user to do this somewhat defeats the purpose of having this automation in the first place, but we’ll take what we can get.
Wish list item: Multi-line Block Attributes. (I know it’s been in the wish lists for years)
you may come to your own conclusions but the ones of the previous post is what works best for us.
Thanks for all the replies. I forgot I had made this post I've been so busy. Then it popped in my head so I checked the thread. What I've done thus far is use mtext, but still you cannot control where the break is short of sizing your mtext window and that doesn't always produce the results you want... Maybe down the road they'll find a way to add that functionality.
Though this appears to be a rather "dated" thread, I think I got it to work a few days ago using the <alt> <enter> key-combination. I'm just learning how to work with tables so I'm not sure if my memory about that is correct. I do remember that going to multi-line was the focus of what I was trying to do but I also had a lot of other formating I was trying to arrange to create a table with a specific setup of tables and columns with multiple sub-columns. I finally managed to get the layout of the table looking the way I wanted but now I'm trying to figure out which fields to select for use in each column.
I'm working on a project that has about 220 sheets and I'm trying to learn how to implement a "sheet list table" to automate as much of the data between sheets as possible. But I'm also using the 2006 version of C3D so perhaps the specific fields I need were not developed back then. I haven't found much info in the provided "help" files so if anyone has some suggestions for other resources on working with tables and fields in 2006 C3D, I would certainly appreciate hearing about it.
If anybody stumbles upon this rdomke69 pointed me in the right direction with my problem:
When referencing the content of a mtext (A) in another mtext (B): If you use regular enter hits to get line breaks it wont work (they show up as "\P"), but if you use shift+enter the line breaks in "B" will be as you entered them in "A"