Re: Find and Replace is NOT "Replacing" but adding to it??
Quote:
Originally Posted by
BlackBox
No worries; it must have been an enhancement in 2013, as the screenshots I posted were from your sample drawing in 2012... Either way, I'm glad you got it sorted, and kudos to reidcharley. :beer:
Ok, to beat a dead horse..
I just tested with AutoCAD 2012 (which I still have on my machine) and apparently this method needs to be used for 2012 too.
It behaved the same way it did in 2013, where a wild-card simply put "SEE PLAN" between the EL. and the elevation number(s) [see screen shot].
Testing the same drawing adding the ["] to the[*] = find [EL. *"] it replaced them as I expected.
So I don't know when this changed, apparently I haven't done it in a while where I used a wild-card.
~Shrug~
This is good to know though...
Re: Find and Replace is NOT "Replacing" but adding to it??
Quote:
Originally Posted by
tedg
Testing the same drawing adding the ["] to the[*] = find [EL. *"] it replaced them as I expected.
My 'Use wildcards' option was not checked.
Re: Find and Replace is NOT "Replacing" but adding to it??
Quote:
Originally Posted by
cadtag
Thanks -- that makes sense.
I'll cordially disagree though, with the statement that it's not a bug. It may be working as designed, but it's still a bug inasmuch as it does NOT work as expected, nor is it consistent with other uses of the '*' as a wildcard character that I've encountered in 30 years. Invariably the * has meant 'from here on to the end'. that end may be a 'end of line', end of string, or a predefined delimiter (eg the period in a dos filename).
so: "the EL. * replace would overwrite EVERYTHING after [modEL. ] even if what followed happened to be hundreds of characters long, and we don't want it to work like that "
is incorrect -- as I _do_ want and expect it to work like that. I can see advantages to having an ending character, but in the case of No Ending Character being supplied, the asterix should be a wcmatch the remainder of the string.
I agree with all of this.
I know I've used wild-cards in "find and replace" for years and years, and it's worked as expected (as you described).
I'm not sure when this change happened or if it's documented, but it should be (I haven't found it... yet).
Not sure why Autodesk would change it in the first place?
Autodesk fixing what isn't broken again?
:banghead:
Thanks again to "reidcharley" for providing the solution, can you tell me/us how you knew this?
2 Attachment(s)
Re: Find and Replace is NOT "Replacing" but adding to it??
Quote:
Originally Posted by
tedg
I agree with all of this.
I know I've used wild-cards in "find and replace" for years and years, and it's worked as expected (as you described).
I'm not sure when this change happened or if it's documented, but it should be (I haven't found it... yet).
Not sure why Autodesk would change it in the first place?
Autodesk fixing what isn't broken again?
:banghead:
Thanks again to "reidcharley" for providing the solution, can you tell me/us how you knew this?
I used 2011 to test. I think it has always worked in this fashion, albeit differently than any other occurrence of the wildcard use. See attached for demo of the danger if it behaved as other instances.
Attachment 93355
Attachment 93354
Re: Find and Replace is NOT "Replacing" but adding to it??
Quote:
Originally Posted by
reidcharley
I used 2011 to test. I think it has always worked in this fashion, albeit differently than any other occurrence of the wildcard use. See attached for demo of the danger if it behaved as other instances.
Attachment 93355
Attachment 93354
Ok, maybe you're right and I never ran into this particular situation.
I know when I've wanted to find and replace something that is surrounded by a common word or character, I would use that to my advantage.
And so you've prooved with the suggestion of adding the " inch mark.
By saying find [EL. *"] you're saying find everything that starts with EL. <space> <everthing else> and ends with a "
Maybe I just never ran into this before and assumed the simple[*] would select everything and replace it with my values.
Re: Find and Replace is NOT "Replacing" but adding to it??
FWIW- 2009 is borked up the same way.
Expected behavior is not a danger, it's the unexpected behavior that causes problems.
And this is unexpected behavior that causes problems. Using TedG's examp, of changing EL: 12.23 to EL: SEE PLAN, that will invariably fail - because i almost never bother using a foot mark on elevations (I do civil in the States, so there's no other unit that would be used for elevations and no reason to include the '). I'd have to do it the hard way, changing EL: ##.## to EL: SEE PLAN
Re: Find and Replace is NOT "Replacing" but adding to it??
Yah, it's still broken in 2013. It's a lazy / greedy search thing. I wrote about it at http://cadbloke.com/2011/03/15/autoc...dcards-broken/. I'm still working on the solution to this. With a bit of luck / lot of time I will ship something by the end of the year that fixes this problem.