Topic: Dynamic Block reverting back to default state after editing lookup name

[ELOQUINTET]

Hey all,

I was wondering if anyone has dealt with this problem and has a solution. I have a bunch of cases with variable heights. When I first designed the blocks I just put in a linear stretch then added my height to the list in propoerties. In the process of assembling all of my variations I noticed that it was difficult to check them without measuring the heights. Our project managers also think of them by these height designations, not by the height associated to the designations. I thought it would be easier for them and me if I created a lookup that was associated with the Linear Stretch and hide it's grip. It worked great in theory until I reviewed them with my boss and she wanted me to change the wording I have in the Lookup Properties field. When I do this it reverts all of the blocks that I have changed to "HEIGHT 3" back to the original "HEIGHT 2". The attached drawing illustrated what I mean. This wouldn't be so bad if 1 these blocks were not nested and 2 they didn't occur about 150+ combinations. I don't think I can change the way autocad behaves. I was thinking a workaround would be a routine that would allow me to select combo block and it would ask me what lookup state I wanted to make the three nested blocks. Has anyone tried doing something like this yet?

[ELOQUINTET]

By the way, This is also happening with Visibility States  :realmad:

[MP]

I'm afraid dynamic blocks share a similar fate as rtext, mlines, wipeouts, vlax-ldata, express tools ad infinitum insomuch as being half baked and/or abandoned and/or unsupported and/or just not right in the head.

/imo

[ELOQUINTET]

I think they are functional enough that they will survive but only in certain environments. Anyway, I really need this functonality because my blocks keep reverting back to the first lookup or visibility state if I edit the names which is very annoying.

[M-dub]

Sorry, I won't have a solution for you either, but thought I'd chime in on the subject.

This kind of problem is one of the things that scares me about dynamic blocks.  When we create a new drawing, let's say it's an electrical schematic, we insert all of these blocks wherever they're needed.  Let's use a switch for example.  If we insert a switch as a dynamic block and change its state to Normally Closed, we finish the drawing, print it out and all is well.  A year down the road, changes are needed to that drawing, so we open it up but something screwy has happened with the block for whatever reason and the next guy goes to insert it into the drawing again, changing the state of all of the existing occurances of that block back to whatever the default is.  The CAD operator is totally oblivious to this change, but finishes his markups, prints the drawing and distributes it. Two months after that, at 3:00 am, there's an emergency and the maintenance crew needs that drawing to troubleshoot, but thanks to a screwup with a wonky dynamic block, they are unable to find the problem in a timely fashion.

Ok, maybe that's a farfetched scenario, but it is one thing I have thought about regarding dynamic blocks.  I don't know whether that scenario is even possible, but ...

Sorry Dan... I hope someone's able to help you out!

[FengK]

Dan, are you trying to fix a lot of drawings that have these dynamic blocks inserted already or all these 150+ combinations are in one drawing? Anyway, I think i have a fix for you which requires some lisp. If you can wait, i'll get back to you by tomorrow morning, maybe sooner.

[ELOQUINTET]

xy, The way we are working here currently is that our planners are using a block grid which they insert into their working drawing. The source file is a single drawing. I have not issued any of these blocks to anyone yet but I have copied them within this drawing to create the various combinations. I am just thinking about the revision process in the future. I'm very anxious to see what solution you might have as this could be a big problem for me if I don't find a solution now. Thanks

[FengK]

Dan,

As i mentioned earlier, i'll write some lisp code for you. If I understood your problem correctly, here is how i'd approach it:

1. Search for all the instances of block "Using Lookup", whether nested or not, among all the block references in your drawing or in your selectionset; for each instance found, check the value of its dynamic property "Lookup", if it is "3 HEIGHT", mark it for modification later. I'm thinking attaching an xdata, say "3 HEIGHT", to this instance;

2. Modify your dynamic block: change lookup property "2 HEIGHT" to "HEIGHT 2" and "3 HEIGHT" to "HEIGHT 3". Now you'll see some of your blocks are messed up because those "3 HEIGHT" have been changed to "HEIGHT 2" instead of "HEIGHT 3". But the xdata we attached to them in step 1 should still be there.

3. Process all the marked instances (in step 1) and set their values for dynamic property "Lookup" to "HEIGHT 3".

I think that should do it. There might be other/better ways. Did I get it right?

-Kelie

[whdjr]

Dan,

I feel your pain.  I really do.  I have tons of blocks that use attributes and lookups.  On that note I don't know if I would call this an AutoCAD bug but maybe more of a design limitation.  Anytime you add to or change lookup values your blocks will reset themselves upon reinsertion.  I don't know of a way around this currently.  What you can do is put the blocks that have a height of 3 on a different layer.  Then edit the block and let it 'update' itself.  Then use quick select to select that block on that layer and change all the values at once back to 3 within the properties palette.

Kelie,
I don't think your idea will work because every dynamic block has an 'effective name' and an 'anonymous name'.  Because of the anonymous name I don't think you can edit it the way you want to.  I could be wrong, but I don't think it will work that way.  Good luck trying though.  I'd like to know if you get it to work.

[ELOQUINTET]

Kellie,

That sounds pretty much like what I need but could it change the lookup for blocks that are nested.

Will,

I don't think at this point that I will be able to put these on different layers. We have a very strict layering standards and my boss wants to keep them to a minimum.
Our planning template would have to be revised because we have the viewports setup to freeze certain layers in certain layouts. Some of our projects are ongoing for many years so making changes to their template is not an easy matter.

[whdjr]

The second layer could just be a temporary thing until you got them all converted correctly.

[FengK]

That sounds pretty much like what I need but could it change the lookup for blocks that are nested.

i tested it with the drawing u posted, seems to be working. can u post or email me a drawing that's more complicated to test?

[ELOQUINTET]

Will do on Monday. I'm anxious to see what you've come up with.

[ELOQUINTET]

xy,

Here is my drawing for testing. Basically the blocks on the right (unassembled) are being combined on the left then blocked again. The parts on the right have been updated to the correct heights but the secondary heights have not been corrected in the assemblies to the left (see red circles). The top of the bays on the side cases should align with the center case. The numbers at the left of the grids indicate what height they should be while the letters at top indicate bay widths. Let me know if you need anymore info. Thanks for trying to help me I really appreciate it.

[FengK]

Dan,

Wow, you've made a lot of blocks. In the drawing you posted, there are 43 of them named "elev_PK-*_DYN" whose block definition needs to modified, right? i.e., the AllowedValues for Lookup property needs to be changed from "1 HEIGHT", "2 HEIGHT", and "3 HEIGHT" to "HEIGHT 1", "HEIGHT 2" and "HEIGHT 3". Are there other allowed height values? like "HEIGHT 4", "HEIGHT 5", etc. Unfortunately I cannot help you automate this step. You'll have to modify the block definitions manually. I'm not sure if someone else here knows how to modify the definition of a dynamic block via programming. The other two steps: marking block references, and updating them once their definitions have been changed can be automated.

Kelie