>>Second, I would create a 2-dimensional form-level array property to hold the view information. You could create a form-level method to retrieve the key value by passing in the view name.
>
>Such that it would look like the pseudo example below?
>
>

>aViewRecord(1,1) = 'View1'
>aViewRecord(1,2) = 'KeyField'
>aViewRecord(2,1) = 'View2'
>aViewRecord(2,2) = 'KeyField'
>

Something like that. Although I would put the Keyfield value in column 2. If you wanted to make it more generic, you could have a 3 column array with one of the columns holding the name of the Keyfield and one holding the actual current value.

>
>>Third and my recommended suggestion is to create a form level collection property. The basics of it are that VFP collection objects are wrappers to arrays. The functionality is already built into it to handle the stuff mentioned in the above paragraph. You can download a few examples from the Downloads section. There are also two articles in the May and June VFUG newsletters (sign-up is free to access newsletters).
>
>So, I would reference the wrapper and it would return the view information? Or did I simplify that too much?

A little oversimplification never hurt anyone. ;-) Methods of the Collection object would act on the array property of the collection and return information you needed. The general collection object discussed in the VFUG article could be augmented to better suit your view collection needs. FWIW, I use collection objects to handle Table, Record, Stored Procedure and Error objects (to name a few). Each collection class augments my base collection class with PEMs specific to the type of object that can reside in it.