Hey JVP ----

The problem is that there are probably a gazillion ways to do this but some of those ways it's hard to explain without going too far into concepts that the original poster may have problems with understanding. My personal favorite is have a custom form property called "SelectOnEdit" that I have a default value (an object name) in each form but that can be modified by Got/LostFocus as appropriate....

Your way works well too, but you've got to applaud Ed's contribution as the ultimate embodiment of KISS for this particular problem.

>I have enjoyed reading this thread <g>.....sort of...
>
>What is astonishing to me, is that nobody suggested creating a container class with a pageframe and a command button. I think Garrett came closest of all. From a design standpoint, you have two classes - a command button and a pageframe - that need to know about each other. At the very least, you have a command button that needs to know about the pageframe.
>
>However, consider this...
>
>Names/containership. What if the name of the pageframe changes? Or, what if
>it's location changes? The hardcoded path will fail in either case.
>
>If you encapsulate things in a container, you can have more effective messaging between the objects. If you have to trap errors, you can consolidate that code in the Error() of the container. It's purely a design thing. Then again, you asked for a "Generic Set Focus". Hardcoding with explicit names is hardly generic. Something tells me that in the next 6 months or so, you may have to re-visit that code for one reason or another that could be avoided if code was encapsulated in a class. And.. if you needed to build another app that needed that same component, well... you would not have to rewrite anything...assuming the class was designed correctly.
>
>VFP has some great OO features. Why folks still bang thier head against the wall when the solution is very simple is beyond me... < s >.
>
>
>Just another point of view....
>