"Automation Error: Key not found" Only with specific block

[spencer.robertsU8DLN]

I'm writing a routine to handle some automated block renaming based on some metadata stored as block attributes.

I've found that one specific block is causing a "Automation Error: Key not found" error and can't for the life of me figure out what makes this block fail and not its 'siblings'. 

If anyone has any thoughts or suggestion, I've attached the relevant code and a sample drawing where the block are failing.

Thanks for any help you can provide

[pbejse · Accepted solution]

---

@spencer.robertsU8DLN wrote:

I'm writing a routine to handle some automated block renaming based on

---

What you're routine is renaming are the block reference name and not the block definition,

(vlax-for layout (vla-get-layouts (vla-get-ActiveDocument (vlax-get-acad-object)))
...(= (vla-get-objectname i) "AcDbBlockReference")
...(vla-put-name i nn) ..

Simply put, the block "B82160 JT 11" ( nn ) does not exist hence the error.

What is the primary goal of the routine anyway?

I think this sould like this.

      ...(if (and	    
            (= (vla-get-objectname i) "AcDbBlockReference")
            (= (strcase (vla-get-name i)) (strcase bn))
            (tblsearch "BLOCK" nn);<-- here to check the target block exist. |
          )...

Otherwise add the option to create or insert one if needed. 

What is gstart variable for? are you intending to use this as prefix for new block names?

[spencer.robertsU8DLN]

Aha! Thanks for saving me frim bashing my head against the wall on this one. 

The current goal is to rename and redefine a series of block definitions that were created incorrectly through another function, so I believe your approach should work provided I define any needed blocks before hand. 

In the other function, the user uses a dialog box to lookup and display information for our joint definitions pulled from a database. Once the user finds the selection they want, they can then insert that specific joint block, with a definition consisting of the JT number, a part reference, and all other info stored as invisible characteristics so any given insertion could be confirmed to be accurate by using the BATTMAN command. Due to a bug that was discovered after a limited release, many of the block names/part references were incorrect. We found that the attribute data was always correct, so I was trying to write a quick routine that could fix the layouts containing the incorrect blocks leveraging the attribute data within them.

 

Part of the code I posted here is related to the "refresh" portion of the above, where it forces all generated block definitions to adhere to the current standard + data. This is why there was that floating Gstart variable; that's being used for a time elapsed display once the refresh is completed. Sloppy editing on my part.