>>>>>>>Isn't that what Thor's tool "Copy for comparing..." and "Compare with copied..." are for? I remember reading your white paper recently.
>>>>>>>
>>>>>>>http://www.tomorrowssolutionsllc.com/Articles/Try%20Thors%20Terrific%20Tools%20Part%202.pdf
>>>>>>
>>>>>>They actually give the opposite of what I'm looking for, a list of differences. I want the matching PEMs and only those added at that level. Even better, I want a tool that would take the two classes as input and create the new parent class with all the common PEMs added there.
>>>>>
>>>>>Sounds like a nice job. How long can you wait? The classes are vcx based?
>>>>
>>>>If no one has a tool to recommend, I'll just get the work done, using the code I've already written to get the list.
>>>>
>>>Drew had a hacking tool in MaxFrame where, after you created the superclass in the normal manner, you could hack the intended subclass(es) to be children of this new parent.
>>
>>Thanks. That's actually the easy part. The Class Browser lets you do that. The harder part (which I've cracked) is identifying the common PEMs that have added to the two classes and adding them to the new class. I did something quick & dirty for the task I had. Now I'm trying to turn into a shareable tool with appropriate UI.
>
>Identical EMs lifted to common ancestor: certainly. Ps I am not certain on: current code will continue to run as on init property has same start value. But sometimes Ps are meant as switches for certain behaviour, those I set at the class level even if setting found in superclass is already set the way I like: I gain the ability to introduce another ancestor and am no longer coupled to the setting found in ancestor. Can be argued both ways IMO - perhaps add a checkbox to leave certain Ps alone ? they typically are either boolean or integer (often low numbers [0..7]). No problem in shallow inheritance, but sometimes you enter an environment with deep inheritance and approaching god-class-capabilities.
>
>For me task most often wished to automate is not identifying and moving totally identical EM, but EM (or functions) created with ^c^v and then partially overwritten, keeping identical stretches which should be broken out into common submethods IAC, which is for me reason to stay in manual mode when doing such refactoring, although I will certainly look at your tool if I find classes with common total duplicates.
>
>But I am somewhat of a DRY nut on code smell and taste ;-)

So far, I'm focused on simply elevating the definition of PEMs defined in both of the original classes to the new common parent. I haven't done anything automated about assignment of values to such properties (though I think if they have the same value, I should set it) or about moving code. I also hadn't thought about setting of inherited properties where the two share common values in the PropSheet. All good things to think about.

Tamar