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!
Solved! Go to Solution.
Solved by Gary_J_Orr. Go to Solution.
Solved by David_W_Koch. Go to Solution.
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
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
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
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.
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
@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.
@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.
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?
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.