Some Twilight Zone Stuff .... In Dynamic Form!

[Rico]

Ok,

So I have a dynamic Block of a Door. No muss no fuss. About 9 visibility states. Lines only, no text, many parameters and actions. On the base drawing, it works great. Just like it's supposed to.

A co-worker inserted an earlier version of it and now it populates his drawing. The block still worked well.

I made some modifications to the base block. For starters, changed the "default size" from 762 to 900) and added a few more numbers to the dimension list for the door jamb. I tested it and it still works great.

So far so good.

My co-worker tries to re-insert and redefine the block, but when he does, the block loses ALL visibility states and none of the changes I made show up. Attsync and battman do not work as there are no attributes associated with this block.

I do not want to purge and re-insert the block because that would mean re-doing all the work ....... ANYONE HAVE ANY IDEAS?

Anything at all?

[Chris.N]

is it possible to go back to the "pre-crash" state of drawing where everything was right in the world, but for an updated door block? I would then recommend purging that drawing, then COPY W/ BASEPOINT (not wblock!) everything in file using a window (make sure all layers are on and thawed, and don't use 'all' from command line...)
I've had funny things happen that have been fixed with this 'restart in middle' method for some files, and have been ok after that.
any reason for the change in 'default' size to begin with? (tho i don't think that it should have done anything...)

[Rico]

is it possible to go back to the "pre-crash" state of drawing where everything was right in the world, but for an updated door block? I would then recommend purging that drawing, then COPY W/ BASEPOINT (not wblock!) everything in file using a window (make sure all layers are on and thawed, and don't use 'all' from command line...)
I've had funny things happen that have been fixed with this 'restart in middle' method for some files, and have been ok after that.
any reason for the change in 'default' size to begin with? (tho i don't think that it should have done anything...)
I'm not sure I understand what you mean ..... "pre-crash state" ..... the drawing itself didn't crash. Just the block became all wonky. Basically, the block seems to have gone the way of the black hole and caved in on itself (if the theories are indeed true). The drawing itself works fine. All that's wrong is that the block shows no visibility states, stretch points or all that jazz.

The change in default size was because the co-worker insisted that the block would be better if it was preset to the typical 900mm (36") door width. Basically, he didn't wanna go to the trouble of dynamically changing it upon insertion.

It seems to me like what has happened is that, upon re-inserting and re-defining the block, it has gotten mixed up and taken both blocks (the obsolete one and the new one) and mixed them together. It's quite frustrating ...... cuz now, said co-worker is saying that DB's are flawed and not worth the effort. Sheesh :roll:

[Chris.N]

I'm not sure I understand what you mean ..... "pre-crash state" ..... the drawing itself didn't crash. Just the block became all wonky. Basically, the block seems to have gone the way of the black hole and caved in on itself (if the theories are indeed true). The drawing itself works fine. All that's wrong is that the block shows no visibility states, stretch points or all that jazz.

The change in default size was because the co-worker insisted that the block would be better if it was preset to the typical 900mm (36") door width. Basically, he didn't wanna go to the trouble of dynamically changing it upon insertion.

It seems to me like what has happened is that, upon re-inserting and re-defining the block, it has gotten mixed up and taken both blocks (the obsolete one and the new one) and mixed them together. It's quite frustrating ...... cuz now, said co-worker is saying that DB's are flawed and not worth the effort. Sheesh :roll:i meant before the block crashed. have you done a 'BE' to see if there wasnt' anything set to 'visible' in base state? (a possibility), and second, if your co-worker uses Toolpalettes like a good caddie, the "base" size can be preset in the tool's "properties" prior to insertion.

[Rico]

i meant before the block crashed. have you done a 'BE' to see if there wasnt' anything set to 'visible' in base state? (a possibility), and second, if your co-worker uses Toolpalettes like a good caddie, the "base" size can be preset in the tool's "properties" prior to insertion.
I'm afraid that no one here at my workplace knows how to use Tool Palettes, except for me of course (and maybe one or two other people). As such, Tool Palettes are not a part of "company standards". Blech. I've been trying to be the harbringer of positive change and innovation, but the people here are very stuck in "their ways" and in routine and in office beaurocracy.

No, the block definitely had a visibility in its base state.

I think it's gonna have to come to a purge and re-insert because I did it to one of the X-ref'd drawings and it worked fine (the block, I mean) after I did that. I just wish people would wait and go slowly. One at a time, until they are positive everything works well. Impatience leads to a purge and re-insert ............... sounds like Confucian philosophy to me. I just created a "new" ancient saying! ;)