Malcolm,
I wrestled with this one too some time back. The only thing I could come up with (and it is the brute force method) is to use names different in key areas. Methods/events like Valid, Click, etc. call other methods with names generated by me. These names are not duplicated (usually) and using JustStem() works in these cases.

Is it possible to design your components in such a way or are you looking at a generic solution that will handle every design situation? If so, then I'll go along with Jim in saying you're SOL. Looks like another ER for VFP 8. ;-)

>I'm trying to use the 'return to program' statement to return to method code earlier in my program stack. The problem is that program() returns method code names as objectname.method but the 'return to program' syntax does not accept program names with periods.
>
>So, my first strategy was to use juststem() to strip the objectname prefix from values returned by program(), using the resulting method name as the program name for the 'return to program' statement.
>
>This sort-of-works. What happens is that VFP returns to the most recent routine on the program() stack with the same name. This means that if you have nested method calls of the same name, but from different objects, VFP will return to the most recent method of the same name, not necessarily the method associated with a specific object or the appropriate program stack level.
>
>Does anyone know how to get around this problem, i.e. how I can use a 'return to objectname.method' syntax to return to a specific function on the call stack? Or if that is an impossibility, is there a way to return to a specific function on the call stack by call stack depth, i.e. return to the 5th function on the call stack via something similar to 'return to 5'. I wonder if the VFP C++ Developers Kit allows a FLL to adjust the call stack pointer (depth) or change the current statement pointer?
>
>The motivation behind this query is my intent to create the equivalent of 'try/catch/finally' (ala Java, C++, .NET) error handling logic in my applications.
>
>Thanks!
>Malcolm Greene
>Brooks-Durham Software