Anuncios

The Autodesk Community Forums has a new look. Read more about what's changed on the Community Announcements board.

christianbaileypaulsen1
719 Vistas, 12 Respuestas

Block Showing "####"

Hi everyone i have a block i made, that usually works really great. Yesterday i inserted about 300 of them in a drawing and it worked fine. I saved my drawing and went home, and this morning i come in and open the drawing and its all messed up. Theres a attribute on the block that displays the x and y coordinate for the block, Today it just shows "####". When i insert a new one from the insert tab it looks fine. Is there any way to fix this. BATTMAN, SYNC, REGEN, REDEFINE, INSERT? Anything at all? Unfortunately i cant share the drawing its messed up on because its a work document but i can share the drawing of the block. Thank you. Theres also a screenshot of the problem.

Hi,

 

usually this symbols appeared when the link between the attribute text field and the object itself is lost. please make save as from your drawing then erase all what you want and just keep a little from those attributes.we need the damaged file itself.

Imad Habash

EESignature

I see no reason why it would be broken. The block definition seems fine, whenever i drop in a new instance of the block it works perfectly. Attached is the damaged file.

the attribute block itself is working fine in the damaged drawing file BUT in the origin scale. your damaged ones are too big than the origin one.

Imad Habash

EESignature

The file name is very nice, but the file is anything but clean in terms of application entries (almost 15,000 applications).

Purge 14866 of 14872 with command -PURGE Option REGAPP.

 

The file was save from a newer Acadversion to a lower Fileformat, so is it also possible you saved or convert this file to DWG2007 or lower?
THAT crash your field (which lost the Link to the refert Object)

 

 

** The Size is ok, the old Blockrefrences are scaled 40x **

Sebastian

I asked a coworker and they said they didnt save as an older format. Could anything else have gone wrong?

In your AttDef, in the Default value, insert a Field, but instead of pointing this Field directly to the BlockPlaceHolder property, point it to a Formula, and in the Formula insert a Field which points to the BlockPlaceHolder property. (It must be a Field within a Formula within a Field within an AttDef.)

 

Crazy, huh?

@christianbaileypaulsen1
I don't know too why the Link to the Insert is broken.
The old inserts based on an different Block version,
so your explaination created 300 inserts/SAVEinDWG2013/CLOSE/REOPEN is NOT true for this uploaded file.
Or you mean with "inserted about 300.." not create by command:insert (or by Toolpalette), instead copy&paste from another File.

In DWG there is tons of garbage, that does not create confidence, we do not know what files, commands were involved.

Fixing is often not possible by Acad command, only with appropriate program extension. But in that case, you can just re-create the attributes. Change the 4 attdef to constant, use attsync, set the attributes back to non-constant and apply attsync again.

OT: And why the Attributes are annotativ - only with one scale / 1:1, no sencefull function, or?


@dmfrazier
Why crazy?
Thats the good possibility of formular-fields, unfortunately, no fields can be nested in DIESEL fields.

Sebastian

In addition to what the others have said, both blocks have problems.  There are several parameters that have no grips, and several lookup tables. There is a visibility parameter that is uneditable in both versions of the block.  The formula field attributes don't make sense to me.  

 

Another thing that doesn't make sense is that your units are meters but you are using Architectural Length formatting.  Both drawings should be recreated with better designed blocks and a better thought out units scheme.

 

As another has said, if you use annotative blocks, you won't need to scale your blocks.

Architect, Registered NC, VA, SC, & GA.
cadffm
en respuesta a: dbroad

@dbroad

There is no visibility parameter, theres one LookUp parameter named 'Visibility'

 

Linear parameters ImperialSize/MetricSize with property Grips=no is ok,

Linear parameters and scale action is a workaround for visibility:

Set metric-Attribute very small / Imperial big or metric-Attribute big and imperial very small

 

The Formular field is for measure imperial-sized drawing in metric unit. (devide by 0.0254)

 

But another unfortunate thing is the position of the LookUp table, which is identical to the insertion point,

so you can not reach the insertion point anymore.

 

 

Sebastian

dbroad
en respuesta a: cadffm

Thanks. It's really confusing to label a lookup table as visibility. Since the drawing units are meters, the measurement is already in meters and the formula should be for imperial measurements, not for meters. You shouldn't display distances as architectural units when the drawing units are meters.

Architect, Registered NC, VA, SC, & GA.
dmfrazier
en respuesta a: cadffm

@cadffm

 

"Why crazy?"

 

To the ignorant, genius can appear to be craziness. Guiño

Since you probably do not want to buy a program from me to correct the problem,
how does it look with the described solution/workaround of me in Post 8 Tested? Is working?

Have you also looked at the many general notes on the block?
DWG -Purge Regapp
Annotation of ATTDEF/ATTRIB isn´t senceful in this kind/Block.
Blockbasepoint under LookUp-Parameter-Grip
Current LookUp-State is Custom and display metric&imperial at the same time, same place
 ('custom' is good for ??? what?)

Please let us know what happened to our help and the block definition, thank you.

-

dbroad
"It's really confusing to label a lookup table as visibility."
Yes, but for this Block and the function below it is a very well label for this parameter.

I hate it more when 90% DynBlockCreaters (  ) did not named the Parameters and Actions with a senceful label.

Sebastian