>I have had a consistant refresh order problem I could use a solution to.

Hi Terry,

Actually we could all use a solution to this one -- and the solution is for MS to give us direct control over control firing order. One of my pet and persistent peeves is that we do not have it (Are you listening, Billy?)

(SET IRE OFF)

Until we get it (and people say I'm not an optimist!!) there are a number of work arounds -- some of which have been mentioned in other responses. Their problem is that they require the programmer to _work_ -- any time the programmer has to work to accomplish base tasks, there is something wrong with the design.

The most comprehensive solution is to create a pseudo firing order and use it in place of the native firing order for everything in which firing order might be a problem. Since my applications usually involve long strings of dependent calculations -- its always a problem for me.

The basic idea is to include a property such as "firingorder" in each abstract control. When the control is subclassed, assign each control an integer representing its firing order on the container. In the init() event of each control, assign a reference to the control to an array on the form called something like "aFiringOrder[]" along with the firing order index number.

At the end of the forms' init(), sort the array by firing order (this actually applies to all container type objects: containers, pages, etc)

Then in certain container methods such as refresh() where order in which events occur needs to be controled, replace the native functionality with somethng like:

WITH thisform
    FOR i = 1 TO ALEN(.aFiringOrder,1)
        .aFiringOrder[i,1].Refresh()
    NEXT
ENDWITH
NODEFAULT

*(Add validation and error checking as desired)

This is all a royal PITA, but it gives you what VFP should have provided natively, absolute control over the order in which events are processed without having to write a lot of method code for each subclassed container and without having to resort to a mediator.

regards,