View Full Version : Gatte and the Dynamic Blocks Issue
derek.96018
2010-03-11, 05:13 PM
Has there been a work around for the problem with gatte not working with dblocks which have had changes made to them ?
An example is that we have two offices and in our dwt title block is a visibility parameter for the two different addresses. So you start a new dwg, change the visibility to the other office and now gatte will not work on the title block across multiple tabs (until the block is reset).
The main problem is that we are undergoing some major creation of dwt files for specific projects for both offices to work from leaving one office unable to use the gatte command.
we are using Acad 2009, no add-ons
Is there really an advantage to using a dynamic block for this? Maybe there are other reasons it is setup that way but it seems to me that it is causing unneeded work. Why not have both addresses in the template and when you start the project just the delete the one that doesn't apply. Same concept as the visibility parameter but without the headache:) Do you have a reason to keep the dynamic block? Or if you don't want to delete the other address, put it on defpoints.
derek.96018
2010-03-11, 07:18 PM
Thanks for the input, and as this does not address this issue, I will answer your questions in case others are wondering the same.
We have stamping engineers in both offices. Having the dblock easy to switch from one address to the other is invaluable.
The dwts are set up for a specific project with generic layouts of equipment in plan and section with callouts, Layout tabs and viewports, general notes....etc.
So yes, set up this way for a reason and it saves way more time than inserting a new title block (for each layout tab even + updating attributes) if something changes.
Thanks again, Derek
I guess since I don't know your workflow I don't undersand the reasoning. Are you needing to have the same title block read a different address within the same set?
derek.96018
2010-03-11, 07:55 PM
If an engineer is out at one office or the job changes from one to another, the address follow the stamping engineer.
I've done something similar with the seals whether they are an image or vectors. We may need them on for some prints and off on others and I don't want to open sheets individually so I put them on layer 0 or defpoints. If they are on 0 they will print and defpoints they obvioulsy will not. I prefer to use images so I can just unload them. You could have both addresses as text, blocks or images and just put the current one on layer 0 and the other on defpoints. I am assuming your title block is an xref and not inserted into each dwg. After re-reading some of the post I realized that may not be the case.
So yes, set up this way for a reason and it saves way more time than inserting a new title block (for each layout tab even + updating attributes) if something changes.
Possible workaround: Edit the titleblock with the address in an XREF. When the address needs to be adjusted, adjust the xref.
Or make the address read drawing properties for the particular address using FIELDS. You could then add an AutoLISP routine to adjust the custom property to the correct address.
derek.96018
2010-03-11, 09:43 PM
No, you are correct. The title block is not xref'd as the dwgs are fairly simple designs (not to mention that some other higher ups are dead set against xrefs as they are "difficult to deal with").
While I do not agree that the defpoints and 0 layer are the right way to go, I do see how you are working things. I could possibly do a layer specific for each office and create a macro, and button to turn one on and the other off (well frz/thaw) to manage them. hmmmm, maybe.
Sounds a little messy and I would have to re-train engineers and drafters to deal with the change.
If I could get it (the address) to update automatically when a user starts the dwg depending upon what office they are in. That would be cool. But a user would still need to be able to manually change it, if it was needed..... maybe onto something....
By the way, many of our subittals are 2-4 pages making Xref'ing almost more work than it is worth.
But still looking for an answer to the original question....
derek.96018
2010-03-11, 10:21 PM
hmmm, Opie maybe onto something here with the fields/Lisp. That would take a little working out of details. thanks for the suggestion.
Any other thoughts ?
ccowgill
2010-03-12, 12:48 PM
I dont know that I have ever used gatte, however it is an express tool, and that is most likely the reason it does not work on dynamic blocks (express tools seem to be overlooked when new features are added to AutoCAD). In our office, I use a reactor based on the user's log in name/location that sets the correct visibility state when the block is inserted, instead of having it already defined in our template. Once the block has been inserted, the visibilty state can be manually changed, but it wont change on its own. For items that we want to show up a particular way in all of our sheets, we use fields that are tied to custom drawing properties, so you enter the data once, and it filters to all the title blocks, no matter what office you are at.
cadtag
2010-03-12, 01:24 PM
If you are using Sheet Sets, you could set the office address as a sheet custom property, and then manage the offices for each sheet. We do that for the 'Signing Professional', as most of our drawings require the dirt guy to sign, but utility and landscape sheets are signed by others
hmmm, Opie maybe onto something here with the fields/Lisp. That would take a little working out of details. thanks for the suggestion.
Any other thoughts ?
Derek,
This shouldn't be that difficult to work up.
Here is a simple example on how to add a custom property to the drawing properties.
Another one on checking if a custom property exists.
Let us know if you need some help. You might start a new thread on your needs in the AutoLISP (http://forums.augi.com/forumdisplay.php?f=91) forum.
derek.96018
2010-03-12, 11:03 PM
Thanks for the info Opie, I'll take a look at the info you posted and see if it will work for us.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.