Disappearing Tags

[FitzUS]

I've been having some difficulties working with TAGS and spaces.

While trying to fix the problem I was testing some options and created the attached drawing.  There are 3 simple spaces made with two overlapping polylines.  When one of the polylines is adjusted (say pull the grip on a corner) two of the TAGS disappear. 

It may be related to the fact my TAG tool on the toolbar has been malfunctioning.  Whenever I try any TAG tools (door, window, or room) I get a dialog box stating "The tool cannot be found in the current workspace".  My workaround is to insert the MVBLOCK that is my tag then use TAGADDSELECTED to select the TAG I want and attach it to the SPACE.  It all seems to work fine but if the space is changed the TAG disappears.

First, is there any recommendations on how to get the Scheduling Tag toolbar to work? 

Second, is there a better manual way of attaching custom TAGS to entities?

Thanks!

[David_W_Koch]

Your file did not successfully attach to the post.

[FitzUS]

Sorry-

I've tried several times, but it appears I don't have the ability to upload drawings at work.  I'll try from home later.

I've been trying some workarounds and came up with some additional questions:

1) The architect working with us has asked that the TAGS be green in color and not ByLayer,(I don't know why).  It seems that MVBLOCKS can only be ByLayer.  I tried even changing the attribute definitions to be green but that does not work.  Just curious to know if it is possible to override.

2) Since I've been making slight adjustments to the TAGS I have to reattach them to get the attribute definitions to move, or show if I add a new one.  Is there some sort of BATTMAN command that works with MVBLOCKS?

Thanks,

Tom

[David_W_Koch · Accepted solution]

1) You could select an instance of your Multi-View Block, right click, select Edit Object Display from the context menu and then, on the General Properties tab of the Object Display dialog, assign a specific color to that instance of the Multi-View Block. If all of the objects in your visible view block(s) are set to be color "ByBlock", then that color should show. Not sure why the architect is asking tags to be a hard-coded color; perhaps they are using color-dependent plot styles???

2) If you are making changes to the Multi-View Block Schedule Tags by editing the view block(s) that are referenced by the Multi-View Block Definition, linework changes should be reflected automatically, but, as you have found, attribute changes are not. Type MVBLOCK at the Command line, and then use the Update option to push the attribute changes onto existing instances of the Multi-View Block (similar to the way ATTSYNC can be used to update attributes on existing instaces of an AutoCAD attributed block).

If addthis.com is blocked, several features in the forums, including the ability to attach files, fail to work. I also cannot attach files at work.

[FitzUS]

You were right about the properties of the BLOCK that make up the MVBLOCK.  They were set to ByLayer.  Changing them to ByBlock made everything work fine.  It is a dumb reqeust from our Architect.  They will be reformatting the layouts using InDesign and there may be some issues with translations.

Also, using the update option for MVBLOCK is useful for getting the ATTRIBUTES to update.  I wish they had that option on the right click menu.

As for my original question regarding disappearing TAGS, I found a workaround to the block to uploading drawings.  Thankgoodness for WiFi.

Here is an example of my disappearing TAGS drawing.

Tom

[David_W_Koch]

I took a very quick look at your file, and was able to reproduce the issue with the disappearing tags. Figuring out why it is doing that may take some time.

[Gary_J_Orr]

To your original question:
the problem with the tags disappearing is actually a result of how the spaces were created and are maintained.
You have 2 overlapping polylines that are defining and controlling 3 spaces. It's creating a conflict.
Removing the "associative" value of the spaces immediately resolves the issue.

[FitzUS]

The example posted is a simplified drawing of an issue I am having on a larger project.  Simply changing the spaces to be "manually" updated is not acceptable.   The space itself maintains it's integrity when the polylines are modified, why can't the TAG do the same?  What is the use of TAG that disappears if I adjust a wall in a design?  Even if I explode the polylines into simple lines the same issue occurs.

I think it is disturbing to have a software program erase information from a document when there is no intent to do so.

Tom

[Gary_J_Orr]

To further my response:
if you remove the associativity, then delete the overlapping polylines, then create new polylines from the spaces, set the "bounds spaces" property on the p-lines to yes, then make each of the spaces associative again you will have associative spaces that work without the conflict.

[Gary_J_Orr]

Sorry... I didn't write the program nor the reactors that fire to do all of the updating (first of the spaces then the tags)... I don't even work for Autodesk or any of it's resellers... In fact I'm out of work right now and simply used some of my time to see if I could help out.
And I agree, it should work better. But this is what we have and I was simply showing you where I found the issue (the overlapping polylines).
What you chose to do about it is up to you.

[FitzUS]

My original project is just that.  POLYLINE boundaries in lieu of walls.  However, when we have opened drawings completed in the last week the TAGS were simply gone.  I created that test drawing to see if I could reproduce it on a simple drawing and post that.  It seemed to recreate the problem but I did not try to reduce it further.  I still think there is something wrong with the way I am creating TAGS. 

[FitzUS]

Sorry to come off a bit harsh.  I realize that nearly everyone on this forum is a volunteer and it has been an amazing resource (especially David Koch).

You know the feeling when you have a deadline looming and the software just seems to get in the way sometimes.

Tom

[David_W_Koch]

FWIW, I did look at this some more at home last night, and did find that the disappearing act did not occur when a single polyline boundary controlled a single Space, but in your example, where two overlapping polylines form the boundaries for three spaces, then the tags on the outer two Spaces did disappear when editing the polyline boundaries. I tried this with the tags constrained to the space (with and without constraining the rotation) and unconstrained, and that made no difference; the tags on the outer Spaces were deleted no matter the constraint status of the tag.

That is about as far as I got last night. I understand your frustration and, unfortunately, a fix or workaround (other than retagging) does not come to mind. This will probably not make you feel any better, but I was able to reproduce the behavoir in ACA 2010, although in this case, the tag on one of the outer Spaces is persistent (the last one tagged and the last Space created - not sure either of those statuses is significant) and if the edit only affects that Space, then the tags do not disappear.

I will try to find time this weekend to look at this more thoroughly and, if I can reproduce the problem consistently, I will make an effort to inform the Autodesk QA staff of the problem. What happens to it from there is beyond my control or influence, but if they have never seen the problem before, they would not know it needs to be fixed.

[David_W_Koch]

@FItzUS - I have looked at this a little more deeply.  I continue to be able to replicate your issue when using overlapping polyline rectangles as the boundaries for three associative Spaces.  The last Space created of the three always seems to retain its tag when the Space is modified by editing one of the polylines; the other two will lose their tags if the Space is modified by the edit.  I cannot replicate the issue if the boundaries are Lines or Walls.

[David_W_Koch]

---

@Anonymous wrote:

@FitzUS - I have looked at this a little more deeply.  I continue to be able to replicate your issue when using overlapping polyline rectangles as the boundaries for three associative Spaces.  The last Space created of the three always seems to retain its tag when the Space is modified by editing one of the polylines; the other two will lose their tags if the Space is modified by the edit.  I cannot replicate the issue if the boundaries are Lines or Walls.

---

I should have also noted that in my test file, I used all out-of-the-box US Imperial content, including the non-project Room Tag.  So I do not believe the issue lies in the way you are making your tags.  I also went back into the copy of your file in which I had originally looked at the issue.  I copied the polylines, Spaces and Schedule Tags that you had placed, and exploded the polylines to lines.  When editing the Lines (being careful to maintain continuity of the boundary by editing the endpoints of the adjoining lines as well), the tags did not dissappear for me.  I also drew Walls, Spaces and Schedule Tags in that file in a similar configuration, and editing a Wall did not cause the tags to disappear.

[Gary_J_Orr · Accepted solution]

The "problem" is the complexities of trying to find boundaries for associative "fill" objects when you have overlapping plines.

This problem is not specific to associative spaces (you just see it due to the tags disappearing). But it has been a challenge for those that write the code since associative hatching. Ever have overlapping plines and try to hatch within them? It can create some unexpected results, and dragging the plines around cause even more unexpected results.

The programmers for the spaces tried a new approach... and for the most part it works (associative spaces are much more reliable, in terms of finding and maintaining expected boundaries, than associative hatches are).

How did they do it? they actually "update" the space closest to the edited point (and/or the first one found as having the edited object as it's boundary) and "recreate" any others. The proof of that is simple: check the entity data of the spaces prior to making a modification, then again afterwards as follows:

Before modification:

Command: (entget (car (entsel)))

Select object: ((-1 . <Entity name: 7ffffa19a80>) (0 . "AEC_SPACE") (5 . "47D8") (102 . "{ACAD_XDICTIONARY") (360 . <Entity name: 7ffffa19a90>) (102 . "}") (330 . <Entity name: 7ffffa239f0>) (100 . "AcDbEntity") (67 . 0) (410 . "Model") (8 . "O-Area-Spce"))

Command: (entget (car (entsel)))

Select object: ((-1 . <Entity name: 7ffffa19880>) (0 . "AEC_SPACE") (5 . "47B0") (102 . "{ACAD_XDICTIONARY") (360 . <Entity name: 7ffffa19900>) (102 . "}") (330 . <Entity name: 7ffffa239f0>) (100 . "AcDbEntity") (67 . 0) (410 . "Model") (8 . "O-Area-Spce"))

Command: (entget (car (entsel)))

Select object: ((-1 . <Entity name: 7ffffa19860>) (0 . "AEC_SPACE") (5 . "47AE") (102 . "{ACAD_XDICTIONARY") (360 . <Entity name: 7ffffa199f0>) (102 . "}") (330 . <Entity name: 7ffffa239f0>) (100 . "AcDbEntity") (67 . 0) (410 . "Model") (8 . "O-Area-Spce"))

________________________________

After Modification:

Command: (entget (car (entsel)))

Select object: ((-1 . <Entity name: 7ffffa36010>) (0 . "AEC_SPACE") (5 . "4851") (102 . "{ACAD_XDICTIONARY") (360 . <Entity name: 7ffffa36020>) (102 . "}") (330 . <Entity name: 7ffffa239f0>) (100 . "AcDbEntity") (67 . 0) (410 . "Model") (8 . "O-Area-Spce"))

Command: (entget (car (entsel)))

Select object: ((-1 . <Entity name: 7ffffa19880>) (0 . "AEC_SPACE") (5 . "47B0") (102 . "{ACAD_XDICTIONARY") (360 . <Entity name: 7ffffa19900>) (102 . "}") (330 . <Entity name: 7ffffa239f0>) (100 . "AcDbEntity") (67 . 0) (410 . "Model") (8 . "O-Area-Spce"))

Command: (entget (car (entsel)))

Select object: ((-1 . <Entity name: 7ffffa19f50>) (0 . "AEC_SPACE") (5 . "484D") (102 . "{ACAD_XDICTIONARY") (360 . <Entity name: 7ffffa19f60>) (102 . "}") (330 . <Entity name: 7ffffa239f0>) (100 . "AcDbEntity") (67 . 0) (410 . "Model") (8 . "O-Area-Spce"))

Note that only one of the 3 spaces has the same entity name and handle both before and after the grip edit. That is the one that kept it's tag after the pline grip edit (in the test that I ran this time)... I can run the test many different way, editing different grips from each of the plines, sometimes keeping 2 tags, but often only one survives, all depending on what and where... Since tags are "attached" to a specific space, when that space is deleted so is the tag that is attached to it.

They have actually done a pretty good job with this, all-in-all... spaces are much more stable in their ability to update properly than hatches are. Plus they store the old data as relates to attached property sets and their values and attach those sets to the newly created objects which allows them to "look" the same. Now that this problem has been pointed out to them perhaps they can also track what tags are attached and reattach/recreate them as well...

But, again, for now at least, your problem is the overlapping plines and the way reactors and updating is handled by the application. Try cleaning them up first, then filling them with spaces if possible.

AutoDesk Engineers: Are you listening?

[FitzUS]

Gary and David-

Thanks for the in-depth investigation into my dilemma.  I can now clearly understand why the TAGS are disappearing. 

My original reason for posting the question is that TAGS were disappearing on my project files where I used polylines to segregate spaces.  I am tracing xrefed 2D AutoCAD plans with polylines, but I avoid using closed polylines except for shafts and possibly the building exterior, and then generate SPACES to track the allocation of each area to different departments.  The TAGS would disappear when the files where reopened at a later date, without any modification to the polylines.  The simplified drawing that I posted was just a quick way I thought demonstrated the same problem.  I would never have realized that I would be exposing a flaw in the program without your help.  I'll go back to my original files and use your investigative techniques to see if the same issue is occurring there.  ( I'm out of town this week so I'll have to try when I get back). 

This also might help me figure out another problem.  In some files we have created some, admittedly, ridiculously complex spaces.  Generally all the "dead" space between walls when we examine our gross to net areas. Often these spaces redefine their boundaries when the drawing is reopened, but didn't happen when we were editing.  Our solution was to lock that layer to prevent this from happening.  I didn't bother posting as it seemed we were pushing the limits of the software, but I'll take another look.

Note to Autodesk engineer's who may address this issue:

I may be able to avoid the problem for the present, but it may come back to bite me.  The facilities department of my company has recently invested in a FM program called Tririga (purchased by IBM).  I haven't used it yet, but reading the manuals about translating CAD files into the Tririga format they require every space to be defined by a closed polyline.  This will be easy enough going from AutoCAD to Tririga, but there may be difficulties when the FM information will come back to AutoCAD during any type of major renovation if I cannot easily provide the information to architectural consultants.  Thus creating a break in the life-cycle of data regarding using CAD information for buildings which seems to be such a selling point in much of your recent advertising.

[Gary_J_Orr]

without knowing exactly how you are making your calcs (does everything actually need to be a space to do your math?) I would suggest something to you... this suggestion is what I tell myself all the time and is not an "opinion" of you: I always tell myself two things: KISS (Keep It Simple Stupid) which leads to my other rule, ALWAYS use objects for their intended use to maintain data integrity...
To put this into context for what I think you are doing:
Create spaces for the rooms. Create plines (that are not boundary items) for the composite areas (departments and building extents).
Since plines have calculated areas you can use them and a bit of math to get the differences and calculate ratios just as well as having everything as spaces.
This means that you are not creating spaces where you have walls to run your calculations against and will have fewer issues with overlapping plines as boundaries for the actual spaces. Of course, there are other AEC entities that are specifically designed to group spaces that you might want to consider looking into (this is another thing that I always try to remind myself to avoid: Linear thinking when solving an issue... focusing on a single item as the answer for a complex solution)

[David_W_Koch]

You can generate polylines from Spaces, and you can also create Spaces from polylines. If you need different Space Styles for different uses, then it may get a little trickier to select the polylines for each Space Style. (You can select all of the polylines and add a Space for each in one operation, but all will have the same style.) If the polylines were on different layers, based on use, then you could isolate the polylines for each use and create all of the Spaces for a given use in one operation. Still, any Space-specific data would not be transferred to the Polylines (and vice-versa) automatically (except for the physical data embedded in the Space/Polyline shape).