AutoCAD Find and Replace Wildcards are broken

Update in 2015 – it’s not a bug as such but a usability issue – as an aside the dot (period) wildcard matches any single non-alphanumeric character, similar to a question mark but much more restrictive. Curiously I would expect it to match a dot, which is does here. The cause of the confusion is still the lazy versus greedy aspect.

This frustrated me so much over the years that I wrote a replacement for Find and Replace where you can be selective about what wildcards to use. Oh, and it lives in a tool palette so you don’t have to keep opening and closing a window. Check it out.

…returning you to the original post…

I found this bug when doing a find and replace on some IP addresses in an AutoCAD drawing. I was using it as a template for a new drawing so I wanted to reset the IP addresses to a default to avoid duplicating the existing values.  Here is what I started with …

so far, so good

So, I fired up my trusty AutoCAD Find and Replace window, like thus…

AutoCAD Find and Replace window. Finding *.*.*.* and replacing with

… and then selected the block in question & hit Replace All. I got this …

Not the desired result. Huh?

That ain’t right. I tried the same thing in Excel. From this …

Same procedure in Excel, before

… using the same Find and Replacement text …

Excel Find and Replace Window

… and I got this …

Replacement in Excel - ah, that's better

That’s more like it. To paraphrase Sesame Steet, “One of these things does not work like the other ones.”

So, why are they different?

Initially, I thought the difference was that Excel’s search is greedy and AutoCAD’s search is an inconsistent mix of lazy and greedy. Here is an explanation of the difference between lazy and greedy text searching, as it pertains to using Regular Expressions. In a nutshell, a lazy search reckons it is done when it has found the bare minimum it needs to satisfy the requirements of the search. The * wildcard I used in the find section will match one or more of any character. A lazy search reckons it’s done when it matches one character, a greedy search will keep matching characters until it eventually runs our of ones that match the search string. In Excel’s  case it stops when it gets to a dot, in AutoCAD it did that with the middle but not at the beginning and the end.

The more I looked at it the more I realised that isn’t right. AutoCAD had actually ignored the first and last wildcards in the search. Instead of looking for *.*.*.* it has looked for .*.*. As Occam’s Razor inevitably predicts, it’s not as complex as I first thought – it’s simply somewhat broken.

I’d say that’s a bug, folks. I guess I’ll be using ol’ faithful Excel for that find and replace exercise. Well, actually, it’s not that bad – the ? wildcard still works so I can use ???.???.???.??? in various number of ?’s to (eventually) get there. It’s still a bug, though.

3 thoughts on “AutoCAD Find and Replace Wildcards are broken

    • Hi Rollin. I tried to have a look at it. You need to provide a with installation instructions and also how to actually run it. As a developer, I know I need to NETLOAD a DLL but the only way I could possibly know what command starts it is to decompile the app DLL with Reflector and look for the Command class attributes. An end-user would be lost.

  1. Ooh, another annoyance in 2011 (I haven’t bothered with 2012 yet) – after you do the replace you can’t select an item from the list in the window and zoom to it to see if you’re happy with the replacement. #FAIL

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s