Larry,

Thanks for your feedback. I came to the same conclusion you did concerning unique names (polymorphism be damned). However, just to be sure, I've decided to track both 'return to' routines *AND* program() stack depth in my error handler framework. When my framework traps an error, I walk the program() stack backwards checking for the first program() that matches my 'return to' value. If I find a match that doesn't match my expected stack depth then I know that my 'return to' will return me to the wrong place in the calling stack (in which case I abort).

Not perfect, but at least it prevents unintended diasters. The side benefit to tracking expected stack depth is that I will be able to use this information if and when MS or a 3rd party FLL adds the capability to 'return to <nLevel>'. I think there's some tips on here on the UT and on the Wiki that describe how to write up a feature request for MS? Looks like I need to get off my lazy ass and write up a feature request for 'return to <nLevel>'.

BTW, I love your and Jims descriptions of my situation - pissin in the wind and SOL. They describe my situation and frustration accurately (:

Regards,
Malcolm

>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