Can you lock fields in a block?

[revitrookie]

I have my title blocks setup with fields inside of attributes all linked to the Sheet set manager. Everything works fine as long as everyone uses the S.S.M. to update the title block, but you can still double click on the block, change the attribute & loose the link to the field.

Is there anyway to lock the attribute so that it can't be tampered with & loose the field link?
I've tried using dtext but when I use dtext within a block my fields don't update even with fieldeval set to 31.

thanks.

[RobertB]

Nope. This is a training issue.

[ReachAndre]

Did you try changing the attributes properties to Constant?

Andre

[RobertB]

Did you try changing the attributes properties to Constant?That ought to work for titleblocks. Good one! :beer:

[irneb]

The problem with a constant attrib is it works very much similar to a normal DText / MText inside a block. The value is contained inside the block's definition and thus only shows the same value for all insertions; doesn't work like a normal attrib which is actually a separate (but linked) entity for each block insertion. If using fields, this means something like %<\AcVar ctab>% could work, but an object reference like %<\AcObjProp Object(%<\_ObjId 2130417976>%).Area \f "%lu2">% would show the same object's area in all insertions.

So depending on what you want, it could work fine. If you're obtaining all the values from the SSM, you should have no problem. You could even use MText inside the block instead of AttDef's. But for something else there's unfortunately no option.

[revitrookie]

I did try constant properties for the attribute & it keeps the value of the sheet set property that is was created in. I also tried a field within Dtext & Mtext in a block with the same result. The only way I could get the fields to work with the SSM was to use attributes without checking constant. It just seems like there should be some way to lock the fields or at least have them update when you have Mtext in a block.

[irneb]

That's exactly what I mean by Cons Attribs being (and working) exactly the same as MText / Text. The only values which would show correctly are those which are only relevant to the DWF file as a whole.

The only way to get these "varying" attributes is to not have them as constant. And thus you cannot lock them :| ... thus the answer (as RobertB's alluded to): "Train your staff to not go fiddling with the field attributes." Or better yet: "Train them in how to use fields, so they can fix them if broken." And if you're using SSM, definitely: "Train your staff to use the SSM properties instead of editing the attribute values"

[revitrookie]

It's quite frustrating that I held training meetings, I put together a 7 page step by step manual on creating & revising the S.S.M. I have a huge note next to my title block that says "USE SHEET SET MANAGER TO REVISE TITLE BLOCK" & people still double click & change the text. I'm about ready to give up on the S.S.M. I set up our company title blocks in revit & you double click on the shared parameter change the text on one sheet & it changes the whole set. Flawless.

[irneb]

You know, there's something you could do through Lisp: Redefine the EAttEdit command to check that they're not editing the title block. If they are, show an alert stating they should use SSM instead. If it's some other block then issue the normal EAttEdit command by prefixing it with a full-stop.

[revitrookie]

I don't know a whole lot about lisp but I would be interested to try something. Can you point me in the right direction, I don't know if there is something that's already been written for this or not?

[irneb]

I'm sure I saw something similar to this in this forum: http://forums.augi.com/forumdisplay.php?f=91

But I can't seem to find it now. Maybe if you ask there, someone would know. I could help but for time. :roll: Sorry!

[Kernal_CAD_Monkey]

Constant prevents the field from updating, and I know nothing about lisp (should learn, have to do it in own time).

Has there been any further thought on this?

[irneb]

The principle behind this is to undefine the eattedit command. Then create a lisp defun called c:eattedit which checks if the block to be edited is of a particular name. If so open a custom dialog which only shows some attributes (or sets the locked ones to disabled edit boxes). If the block is not in the list, then run the .eattedit (notice the dot prefix to run the undefined version).

There's several problems with this approach though:

A normal DCL dialog would only allow a dialog similar to the old AttEdit command's dialog.
It would be nearly impossible to also allow the other tabs in the enhanced editor (those allowing changes in the attributes' properies)
The above 2 could be aleviated by using ODCL instead, though then you'd need to install such.
I can't see how you'd allow field codes from a right-click menu (at least not from lisp). Thus going this route would stop your users from being able to insert fields into any of the other attributes.
It would still not stop inadvertent edits through other means, e.g. through the properties palette or through Ctrl+DoubleClick (i.e. ATTIPEDIT command).
After doing this you could run into other errors. E.g. if you have some other custom code which calls the EAttEdit command - this might fail (if not using the dot-prefix idea).


So you can see why Robert's suggested teaching your users instead of programming to stop them from making mistakes. You're effectively plugging holes and you might miss one or two, while making for other possible problems. Not to mention, the coding would be quite complex and specific to only one setup. Thus it wouldn't be a general function which nearly everyone could use for their setup.

[Kernal_CAD_Monkey]

Yeah I can see how training 'should' be easier.
My problem is that I have one particularly curmudgeonly and obdurate old draughtsman who doesn't see why anything should have changed since the 70's, or why he should change how he works (it's always been perfectly good enough... un - till - now), bemoans the demise of BS308 (having not known until this year that 308 had been superseded).

And is determined to break absolutely everything, making it much more hard work for anyone else who has to work with him, because he's exploded blocks and MText, overwritten fields, bound all the xref's, ignored the layer naming schema...

I'm going to stop and possibly tak this to the rant thread.

[Opie]

Then you take it to management. If one bad apple is making job costs to rise, then they need to know why. They will also have the means to correct the behavior. That is if the bad apple wishes to remain in their position.

[cadtag]

Then you take it to management. If one bad apple is making job costs to rise, then they need to know why. They will also have the means to correct the behavior. That is if the bad apple wishes to remain in their position.

+1

technology is never the answer to a management problem

[Mtn Biker ARM]

I realize this is an old thread, but I was having the same problem. I created a new layer, locked it, and put the attributes with fields on that layer. This locks it out of being edited in the properties palette and attribute editor. The only problem seems to be that any other attributes in the block cannot also be edited in attribute manager. You can still edit them in properties palette, however.