Yeah, I know. At least working around this is no big deal. It was just danged annoying until I actually traced through the code. Doing the same thing using objects that are not collections works as expected [AFAIK] so I tried the same with my collection.

To get the expected results, I just changed my actual code to:

PROCEDURE GetFormObjectRef
    LPARAMETERS tcName
    tcName = ALLTRIM(UPPER(tcName))
    LOCAL loForm, loReturn
    loReturn = .null.
    FOR EACH loForm IN THIS.FormList
        IF UPPER(loForm.NAME) == tcName AND UPPER(loForm.BASECLASS) = 'FORM'
            loReturn = loForm
        ENDIF
    ENDFOR
    RETURN loReturn
ENDPROC

>Mark,
>
>All I've got is a huge shot in the dark based upon the way computers used to handle things back in the "dark ages".
>
>Back then it was bad form to exit out of the middle of an iteration structures because it left junk on the run-time stack. These days it's bad form for design reason, but in the case of a FOR EACH structure there's not much choice in a situation like your's.
>
>What I think that VFP may be doing is some internal housekeeping in order to prevent memory problems. IOW, automatically setting loForm to null or something when the loop exists. With that in mind, I'd make the following suggestion for you to try.
>
>Instead of returning the iteration control variable (loForm), when the Forms Manager finds the form it's looking for, assign it to another variable before exiting the structure and return that.
>
>Please let me know how this comes out.