>>>A slightly different method from Jim's suggestion is one used by many of the commercial frameworks. In your base form you have an 'AfterLoad', 'AfterInit' etc. methods. In the base form code you call these functions, so that the base form's LOAD method would include "thisform.AfterLoad()" at the end of all its other commands.
>>>
>>>THen, if you wish to add code to the LOAD event you simply place it in the AfterLoad() method and know that it will be called after the base code is done.
>>>This is a very convenient technique when you have code in base forms, particularly if there are several layers of subclasses involved.
>>>
>>>HTH
>>>Barbara
>>
>>I like that solution. I know that I can remember it if I see the AfterLoad method in the form.
>>
>>Thanks
>
disregard the last message, this silly thing went ahead and sent on my behalf before i was done :).
The only consideration to keep in mind is that you'll probably also need to create a BeforeLoad method to execute before the Load Event code, just to make up for the loss in coding flexibility. And of course, if the default Load Event returns some value that will influence the resulting behavior, your work becomes even more tedious with these other methods just trying to find work-arounds for them.
A prime example:
In the Load Event of some parent class you have:
LOCAL lcTable
lcTable = Alltrim(THISFORM.cTable)
IF !Empty(lcTable)
IF !Used(lcTable)
Select 0
USE(lcTable) SHARED AGAIN
ENDIF
ELSE
RETURN .F.
ENDIF
Now then in your subclass or instance, you have:
LOCAL llReturn
llReturn = DoDefault()
With this returned value, you could essentially prevent the form from coming up or display some error code, or some other possibility.
Travis Vandersypen