>>>>True, very very true! And I say this out of my own experiences. Having admitted that, I ask you: Have you tried NewClass? I ask this because it might be the case that the method I chose may be more vertile and flexible that you probably presuppose.
>>>
>>>I wrote a builder which would do that (not as complete and versatile, though) when I needed it. The general conclusion from that and couple of other builders is that it isn't that hard to do if only the original code to replace (or classes to replace) are done in at least half-consistent manner. If they are all different cases, tough.
>>
>>Can you please elaborate on that, for the sake of, hopefully, a (for other too) interesting debate?!
>
>I had a couple of cases when I had to replace controls with other controls. One was about a hundred containers with several controls on them, which were copied from one form to another (datetime selectors for reports), and had to be replaced with one composite control, where a few properties had to be set, based on properties of the old controls. The builder to do this wasn't hard to make, because the code in the old controls was consistent- the controls were named the same, had the same properties etc. Less than 5% of the cases had to undergo some manual intervention.
>
>The other case was a special class where I had a textbox in a container - which actually emulated a commandbutton in VFP7, for some of the properties I wanted to have didn't exist in VFP7's commandbutton. Once the app was upgraded to 8, I replaced those composite objects with regular commandbuttons. Again, using a builder I wrote for the occasion. Ah, yes - the commandbuttons couldn't be yellow in VFP7, that was the reason. This app was about rock'n'roll, couldn't keep the buttons at their default colors :).
>
>The point here was the consistency - if you're doing something like this, you want to have the ability to read the properties, maybe even some code, programmatically. To do that, your builder has to know some names, and those names need to exist in every case where you apply it (or you write some ugly kludge to go around their absence). If the naming convention is the same in all the cases, writing such code is worth the while. If the cases have little to no similarity - IBM (immer besser manuel).

I get the impression that you're focusing on the problem of replacing old names/classes in old apps and libraries by new ones. My personal opinion is that such an action is too ambitious. Rather, I advocate that NEW classes are properly named. And team members should not (no longer) have the freedom to invent any name they personally prefer.

For some of us, and for closed projects, it is probably too late. For new projects, and for those who are still willing to improve the methods and techniques, there is a chance for improvement here.