>>>I am haveing problems with refresh() moving my record pointer.
>>>Is there a way to search for all the objects and events that are
>>>effected by a REFRESH()?
>>
>>All objects that have a refresh method are affected by refresh. If your record pointer is moving when you issue a form.refresh, it is because there is code in either the form's or one its control's refresh methods that is moving the record pointer.
>
>Hi Erik and thanks a lot for helping. I thought REFRESH was a simple
>redraw, but it is not. My biggest problem is keeping track of all the
>code I write and where it lives. I know I can print out the FORM with
>the CLASS BROWSER, but my FORM in this app I am writing has two page tabs
>and manying objects. How do I organize my code and remember where all
>my code is? :)))))

There are a couple of methods that I use to find code whose location I can't quite recall...
One is the 'find' function of the method editor. When viewing a form's method, to find where in the form you might have issued a 'SKIP', right click and choose 'find' from the popup menu. In the find dialog, specify all objects, and wrap-around. Type 'SKIP' in the find window. It will automatically search every metho of every control in every container in your form, stopping on all occurences of the specified text.
The other method you can use to search all of your code, is using the class browser. (If your form isn't already classed, just click save as and save it as a class beforehand.) HIghlight your form in the browser window and click the toolbar button whose tooltip reads 'View Class Code'. This will show you all of the code in your methods in that form from top to bottom. (In addition to generated code to instanciate the controls on the form) This is also a good place to learn the syntax of creating objects at run-time.
AS far as how to keep your code organized? Well this falls within good program design. Keeping a consistent way of doing things throughout your apps helps you understand your own work better. I find that even if I wrote a form long ago and don't remember anything about it, I know exactly where all the vital code lies, because when I wrote the form, I did things by the rules of my own framework. I can look at a form and what it is supposed to do, and I automatically know what methods the form must contain, what inhereted properties and methods it utilizes. This comes from being consistent and minimal. When building a form and diagnosing problems, if I add a piece of code to try and see if something works, and it doesn't I immediately remove it (or at least comment it out). There is no (well ok, very little) code lying around without a purpose.
In sum, good program design gives itself to easily traceable and self explanatory code.