CAD Line Arrows Keep Disappearing

[RicochetX]

So I’m having an issue with the arrow attachment to objects. When I copy the arrow to different places on my detail, and then delete the original object the first arrow was attached to, it deletes all the copied arrows too. I just deleted a CAD block and lost 5 arrows of my detail. Is there an option to turn off the attachment of arrows to objects? The only thing I saw in the help says, “Lines with arrows can be attached to other objects. They attach to a closed polyline-based object along its edges, but can attach to an architectural object anywhere within its 2D symbol in floor plan view. If an arrow is attached to another object, deleting that object will also delete the arrow.” It seems that even though I’m copying the arrow to a new location it still stays attached to the original object, unless I move the arrow head to attach to a new object and even then it doesn’t always seem to work. I would just as soon not have arrows attach to anything.

 

[Ridge_Runner]

I've had this happen often. I have tried to move the copied arrow to another object but, like you, it will still delete sometimes when I delete the old. Never figured it out or the setting to turn the association off.

 

Mike

[Archnot-Boltz]

Chief needs to set it up (by default) that when you delete or move the object, CAD line etc that the arrow is pointing to, the arrow should not disappear nor should it follow the moved items. This could be an On/Off on the fly toggle or On/Off default setting in cases where one might want that type of behavior. Sometimes when I move objects or CAD lines that are in the same proximity as the the arrow, the arrow will follow that moved object. I'm surprised that this topic didn't get a lot more response.-BB

[rlackore]

I absolutely hate Chief's text arrow behavior. The vast majority of the time I want my annotations to be "dumb" with absolutely no object-specific dependency. I spend A LOT of time fixing arrows and text during detail/section editing & development. I posted a "fix" request in the Suggestion Forum several versions ago - so far no joy.

[Joe_Carrick]

This is interesting.  I had never noticed that the line with an arrow would be deleted if the object it was "connected to" was deleted.  I normally use "smart" annotation and only want the leader line to disappear when I delete the text.  OTOH, if I do in fact delete the object I think I might also like the leader & annotation to be deleted - but maybe not always. 

 

In my testing, I found that when a "leader line" is used:

• if the object is deleted the leader line is deleted but the text box will remain
• if the text box is deleted the leader line will also be deleted
• if the arrow is moved to another object the original object can be deleted without effecting the leader line
• if the arrow is just moved to an empty arrow, deleting the original object also deletes the leader line

It's an interesting set of "rules" that probably shouldn't apply to "dumb" annotation (ie: no macros).  IOW, when there are no macros in the annotation the arrows and text should be independent of any other objects.

 

 

[rlackore]

1 hour ago, Joe_Carrick said:

It's an interesting set of "rules" that probably shouldn't apply to "dumb" annotation (ie: no macros).  IOW, when there are no macros in the annotation the arrows and text should be independent of any other objects.

 

Well put. I like the idea of the "smart" behavior being tied to the presence of a macro (that pulls data from the associated object, I presume). This makes sense. +1.

[Alaskan_Son]

1 hour ago, Joe_Carrick said:

It's an interesting set of "rules" that probably shouldn't apply to "dumb" annotation (ie: no macros).  IOW, when there are no macros in the annotation the arrows and text should be independent of any other objects.

 

 

This gets complained about often enough that people should be making suggestions for a "Disconnect Arrow" toggle or something similar.  I don't agree that the behaviour should be limited to macros though.  There are plenty of situations where its valuable to have the arrow move with the object it's referencing. 

[Joe_Carrick]

8 minutes ago, Alaskan_Son said:

There are plenty of situations where its valuable to have the arrow move with the object it's referencing. 

If there are no macros in the text..... is the arrow really referencing a specific object?  If so, which object? 

 

There may be overlapping objects and the arrow could be attaching to the wrong one.  This brings up another little (maybe not so little) problem:

• The arrows don't always connect to the correct object.  When there are overlapping objects, a macro designed to reference a specific object type, the arrow might connect to the wrong object. 
• An example of this could be a roof plane.  If the arrow is connected in the overhang area it works fine, but if it happens to hit on a wall or even a room it won't connect to the roof plane.

It would be really nice if the system was smart enough to connect only to an object for which the macro(s) were valid.

 

 

 

[Alaskan_Son]

21 minutes ago, Joe_Carrick said:

If there are no macros in the text..... is the arrow really referencing a specific object?  If so, which object? 

 

There may be overlapping objects and the arrow could be attaching to the wrong one.  This brings up another little (maybe not so little) problem:

• The arrows don't always connect to the correct object.  When there are overlapping objects, a macro designed to reference a specific object type, the arrow might connect to the wrong object. 
• An example of this could be a roof plane.  If the arrow is connected in the overhang area it works fine, but if it happens to hit on a wall or even a room it won't connect to the roof plane.

It would be really nice if the system was smart enough to connect only to an object for which the macro(s) were valid.

 

 

 

 

Ya,  most of these are different subjects entirely with no easy answers.  Arrows could definitely use a lot more control though as you've pointed out...

• It can be extremely difficult to get an arrow to connect to the correct object in some circumstances.  Sometimes the only solution is to drag the object out into an open area, connect the arrow, and then drag it back into position, and even then...
• If we explode a CAD block in that view, the arrow may disconnect on us and jump to something else or even nothing at all.  Very irritating. 

 

With regard to arrows that have no macros associated with them...I'm just talking about arrows that point to specific objects or locations.  Maybe they're pointing to a wall, the corner of a building, a cabinet, a countertop, a fixture, etc.  If we are noting something about that object, it makes sense for the arrow to move with the object.  I mean that's what arrows are generally for right...to point to specific things? 

 

Besides that, I also use the automated connectivity behavior of arrows not to point to things per se but simply because they move with the object.  This can be helpful for setting up customized dimensioning tools (usually with macros that are NOT referencing anything).  And arrows can also be used on molding polylines so that they automatically resize when the connected object(s) are resized.

 

With regard to the idea of smart arrows that only connect to valid objects.   That sounds like it could be a cool option but would it really be all that helpful?  I mean, don't most of your macros include exceptions that would make them valid in most all situations anyway?  I would support this suggestion, but I think in all reality it wouldn't prove to be all that helpful.  For me personally, I've had the most problems with connections to polylines and those connection issues aren't a result of arrows connecting to invalid objects but on the contrary...connecting to other perfectly valid polylines and therefore returning incorrect values.  As you know it would really just be a huge help if the connections were simply stable...smart might just be a bonus.