>What are the opinions regarding how to store and then use a record pointer for numerous views in an app? I was starting to create properties for the form based on what the current view's recno() was, but then thought there was probably a better, scalable solution.
>
>Let's say for example that I currently have only two views, View1 and View2. I would create form properties called CurRecView1 and CurRecView2 and then store/reference as needed. If I add more views later I will need to add additional like properties. I also use a form property called CurView that holds the alias name of the current view (or the view current when the property is assigned anyway). The problem comes up sometimes when I run save routines and such that I endup having to reference the CurRecView1 and CurRecView2 properties. Things start becoming tangled if I have more views and trying to keep track of all the pointer so that I return to where I was when I left to do something else (with other views).
>
>If my post isn't very clear then you see this the way I do. :) Thanks!
>
>Regards, Renoir

I think that Larry's advice is good with regard to how to handle this, but I have to ask- why are you storing all this at once?

I usually don't run into the need to store pointer information for more than one table at once, because each piece of code that moves a pointer moves it right back exactly when its finished, instead of delegating all the 'restore' functionality to some generic routine that has to do it for n aliases.