Topic: block=block - diesel fields do not update

[airportman]

I have about 100 drawings which use an existing titleblock.
I've now made changes to that titleblock (added some diesel fields to the attributes) and would like to update the drawings with my block=block lisp routine.
I have 2 attributes in the titleblock that I have changed to diesel expressions. when I do a block=block update routine, it does not bring in the FIELD diesel expressions from the new titleblock. How do I get this to work. 

[owenwengerd]

Use the ATTSYNC command.

[airportman]

Have tried it. does not seem to work.
Have also tried using BATTMAN SYNC.

[airportman]

I think it has something to do with the OBJECT ID ?    

[owenwengerd]

You'll need to provide more details than "does not seem to work". What does it not do that you expect it to do? Is there an error message? Which version of AutoCAD are you using?

[airportman]

hey owen. love your work with dcl.
what we have here is autocad v2010

the issue i am seeing is the diesel expression in the attribute will not update when i do a block = block update.

[owenwengerd]

Thanks. What is a diesel expression that will not update? What does it display, and what should it display?

[airportman]

the diesel expression (inside a field) for an attribute that is in a titleblock. The diesel expression takes the drawing filename, strips off the ".dwg" portion and then populates the field. This information is then automatically updated anytime you change the filename or when you create a new drawing and use this in your template.

The issue is; the original titleblock did not have the diesel field in the attribute.
When i make the change to the template file and then insert it into the drawing file, you are asked "do you want to redefine the block".
With most blocks when this is performed, the block updates and you see the changes made.
This does not seem to be the case with the diesel expression field.

If you run the BATTMAN command and check the attribute values for the block, they indicate that the fields have changed.
When you hit the SYNC button, nothing happens to the existing block in the drawing.

any ideas would be great.   :realmad:

[owenwengerd]

Sorry, I guess I was not clear. I wanted to know what the expression is in the updated attribute, what it's displayed value is, and what you think it should be.

Redefining a block definition does not affect attributes because attributes are part of the block reference, not the block definition. The ATTSYNC commands updates a block reference.


If you update the attribute definition entities in the block definition, then sync the existing attributes to the new definitions, then evaluate the field, the existing attribute should then display the result of evaluating the updated expression.

[airportman]

owen:

here is the the first expression:

$(substr,$(getvar,DWGNAME),1,$(-,$(strlen,$(getvar,DWGNAME)),7))

and here is the second expression:

$(substr, $(getvar, dwgname),$(-,$(strlen, $(getvar, dwgname)),5),2)

I know that both work fine when i tested them directly in the titleblock. what I am not seeing is the data updating with I updated (redefine) the titleblock.
I have the flags set to 31.
I'm not new to this, but this roadblock is confusing. I might be looking for a variable or something.

[Drafter X]

It may not do what you want the way you want, the diesel has already evaluated the value and gone to the great digital void, redefining the block wont cause it to reupdate. I have seen this before and its annoying, but have not figured out a way to make it re-evaluate the attribute.

[mkweaver]

I don't think this is going to work for you because the field is in the attribute value not in the attribute definition. Attsync does not change attribute values.  This is going to take some code to push the field into the value after you have redefined the block.

[airportman]

its a field within the attribute definition.
The original definition was text. the new definition is diesel.
if i insert the block into the drawing, it comes in with the new definitions.
the trouble is that i have a ton of attributes already populated and i do not want to remove the data.

I know i can do this in 2 parts if needed.

1. I can write an odbx lisp to extract all the data
2. replace the titleblocks with the new titleblock
3. extract the handles for those new blocks
4. translate the data to the new handles
5. push it all back in

does anyone know something quicker? simpler?

[owenwengerd]

mkweaver is correct. I thought that ATTSYNC also updated the attribute value to reflect the new default value in the attribute definition, but the docs make it clear that it does not. This makes me wonder: how exactly did you update the attribute definition in the revamped title block definition? By changing the default value to the DIESEL expression? I'm just wondering if you didn't update an attribute in an instance of the title block and think this updates the definition.

In any case, you don't need to replace the existing title blocks, you just need to update the values of the attributes. If it's only one or two attributes, you can just update them using their tags to find them in the existing title blocks and hard code their new values in your code, without worrying about the block definition at all. If it needs to be more generic, you can do the same thing except use the updated block definition as the source instead of hardcoding the new values.

[airportman]

here are some images of what i am dealing with.
The diesel expressions are in a field, inside the attribute definition.
when i insert the block into the drawing (with the same block), i get the redefine option and follow through (typical).
the next image i provided shows that same block in one drawing (the original on top).
As you can see the original will not update to show the fields.
any ideas?

[owenwengerd]

That helps clarify what you're doing.

If it's only the drawing number and sheet number attributes that you're updating, I recommend to just write a small lisp function to do that, using hardcoded tag names and new values. You can find all kinds of examples here at the swamp and on the Autodesk forums of lisp code for changing the value of an existing attribute. Here is one I found via Google.

If you don't need to automate the process and if your old values are also fields that can be easily identified via search string, you could probably use the FIND command to replace the old value with the new.

Hopefully that helps.

[Lee Mac]

Below is the explanation copied from my response to your email, posted here for the benefit of others following this thread:

...to provide a quick explanation for the result that you are receiving:

Attribute references contained within a block reference are considered as separate from the associated block definition (this is to enable the attribute references to hold different values across multiple block references); when you redefine a block in the drawing, the block reference geometry is updated to reflect the updated block definition, however, the attribute references are not altered in any way (since they become separate from the definition when a reference is inserted).

The use of ATTSYNC will only update the positions & properties of the attribute references and possibly add or remove attribute references that are either present in the definition and not present in the block reference, or vice versa; the values of the attribute references are not altered in any way.

Since the Field Expressions in your modified block definition are located in the default values for the attribute definitions, these default values will not be applied to existing block references when the block is redefined, and furthermore the values of the attributes references will not be updated following an ATTSYNC operation, as described above.

A potential solution would be to use a custom program to update the values of the necessary attribute references to use the default values held by the associated attribute definitions within the block definition, or even hard-code these updated values in the program itself.

[LE3]

<SideQuestion>
Master Lee, how much do you charge per hour? doing lisp or it is per application? or?
<SideQuestion>

[Lee Mac]

I'm sure you know me better than to think I would discuss such matters on a public forum Luis 

[airportman]

Just to clarify. I was not looking for someone to write me some code. I can write the code.
I was looking for some information that might be beyond my knowledge.
a few things I understand here:

LISP
ODBX (with lisp)
Diesel expressions

where I think this might be a bit more complicated and could have a different outcome, is if I knew how to access the OBJECT ID, to get what i'm looking for from the diesel expression.

I thank you Lee for having a look. I can make it work from here, and I will post it when I got it.

[irneb]

I think the issue you're running into is the working around how AttSync/BAttMan-Sync operates.

If a reference to the block contains an attribute named as per the definition's AttDefs, then that attribute will only be modified to match the properties of the AttDef.

However, if the block reference does not contain an Attrib matching one of the AttDef's - it is created using the default value of the AttDef.

So a "quick-fix" solution for you would be to rename the AttDef inside your new TB to something else that what the same tagname in the old TB was. Then insert, redefine & attsync. This should then delete the old Attrib with the old tagname and re-create the new Attrib with the new tagname and new default value.

An alternative method would be to recreate the field expression through lisp, see other post.

Also if you need to find the ObjectID of an entity so you can use it inside a field expression you build from lisp, then look into the entity's ActiveX object:

Code - Auto/Visual Lisp: [Select]

1. ;; Command to place a field showing the length of a picked entity
2. (defun c:FieldLength  (/ en eo pt)
3.   (vl-load-com) ;Ensure VLisp COM extensions are loaded
4.   (if (setq en (entsel "Pick an entity to show its length: "))
5.     (if (and (setq eo (vlax-ename->vla-object (car en))) ;Convert the EName to a VLA-Object
6.              (vlax-property-available-p eo 'Length)) ;Check if the object has a Length property
7.         (if (setq pt (getpoint "\nPick point at which to place field text: "))
8.             (command "._MText" pt "_Width" 0.0
9.                      (strcat "%<\\AcObjProp Object(%<\\_ObjId "
10.                              (itoa (vla-get-ObjectID eo)) ;Include the ObjectID
11.                              ">%).Length \\f \"%lu6\">%")
12.                      "")
13.         (prompt "\nNo point picked, exiting."))
14.       (prompt "\nThat objtct does not have a length, exiting."))
15.     (prompt "\nNothing selected, exiting."))
16.   (princ))

[CAB]

I agree, forget attributes & use fields directly.
The old method was to use Rtext.

[airportman]

And following on the advice of many (in particular IRNEB).
I modified the new TB with new TAGS (containing the diesel expressions).
I rechecked my code, that was throwing up a NIL response for some reason
I added (ARXLOAD "BATTMAN")
I added (acet-attsync var1)
I called a simple "qsave"
I created a script file (for use with ScriptPro 2 - see here: http://labs.blogs.com/its_alive_in_the_lab/2010/10/adn-plugin-of-the-month-scriptpro-for-autocad-now-available.html)

And then the rather simple routine:

Code: [Select]

(defun blockup2 (/ newblk2 redefblk2 ) ;block replace
(vl-load-com)
  (setvar "tilemode" 1)
  (setq newblk2 "SUN_TBD_ISO")                            ;set block name
    (progn               ;do the following:
  ;prepare the block name string using the blockname=blockname format
        (setvar "attreq" 0)                           ;turn attribute request off
  (setq redefblk2 (strcat newblk2 "=M:/CADD Files/LISP_MODS/SUN_TBD_ISO.dwg"))
  (command "-insert" redefblk2 "0,0" "" "" "" );insert an instance of the re-defined block at 0,0
  (command "zoom" "e")                        ;zoom extents
  (command "erase" "l" "")                    ;erase the just-inserted block (leaving an updated block reference)
  (command "zoom" "e")                        ;zoom previous
        (setvar "attreq" 1)                           ;turn attribute requesting back on
        (ARXLOAD "BATTMAN")
        (acet-attsync newblk2)                         ;synchronize attributes
)
(COMMAND ".QSAVE")
  (PRINC)
)
(blockup2)

All said and done.
It worked great.
Thank you (I plan to look more into the OBJECT ID)

[irneb]

Glad you got it working 

[snddd2000]

(command "-insert" redefblk2 "0,0" "" "" "" );insert an instance of the re-defined block at 0,0
Have any vlisp code instead of this code?not use "command"
thanks

[Lee Mac]

(command "-insert" redefblk2 "0,0" "" "" "" );insert an instance of the re-defined block at 0,0
Have any vlisp code instead of this code?not use "command"

Code - Auto/Visual Lisp: [Select]

1. (vla-insertblock
2.     (vla-get-modelspace (vla-get-activedocument (vlax-get-acad-object)))
3.     (vlax-3D-point 0.0 0.0)
4.     redefblk2
5.     1.0
6.     1.0
7.     1.0
8.     0.0
9. )

[snddd2000]

thanks lee,
the redefblk2="block-name=file-name",but get an error "Automation error",
if active-document is not  exist the same block, then use vla-insertblock and redefblk2="file-name" is ok.
if existed the same name block, then use vla-insertblock and redefblk2="block-name=file-name" is not working.
have any solutions? or no way. this block is HasAttributes
thanks

[Lee Mac]

The InsertBlock method will require either a block name (if the block definition already exists in the Block Collection of the Document calling the method), or a filepath to the drawing containing the block definition.

If the full filepath is used, the InsertBlock method will always source the block definition from the external drawing, automatically redefining the block if it already resides in the Block Collection; hence the 'block-name=file-name' format is not required.

[snddd2000]

Thanks a lot, today i try this way, after read your reply, it is OK.
I confused the day before yesterday, i tried the same way, but it did not work. May be other errors caused
After all, eventually it is OK , thanks again.

[Lee Mac]

Excellent, I'm glad that you understood my explanations 

[airportman]

Curious...

at snddd2000 -> why did you not want to call a command inside the lisp?

[Lee Mac]

at snddd2000 -> why did you not want to call a command inside the lisp?

Maybe they were using the code operating with an ObjectDBX Document, or evaluating it within a Reactor callback function?
[no command calls allowed]