>>>>PMFJI. Is it reasonable to assume that since the application started and therefore the main.prg executed successfully, then any function/procedure defined in the main.prg is always loaded?
>>>
>>>Unless you employ tricks with timers to delete main.prg functions from the stack, yes - assumption being that main prg is the startup program and stays at stack level 1.
>>
>>Do I read this idea that you
use a timer to start READ EVENTS and let main.prg run to it's end?
>
>Embolded would be overinterpretation ;-) If base assumption holds true, the file of stacklevel 1 has to stay in memory until every proc/function called from it is done, so basic question should be answered positive re "reasonable". Tempted to write "guaranteed" I thought about options to remove the program at stacklevel 1 - first ideas were on establishing some object "externally", prime contender some other process - either invoked via something asynch, like old DDE or newer object linking and embedding, batch file starting an exe which in turn does activeX getobject() to first vfp - or perhaps just a timer ? There is a good chance even that is not enough by itself to stop vfp from closing itself down after return value of stacklevel 1 is calculated *and* returned - perhaps a memory leak in objects assigned to _screen or _vfp needs to exist as well.
>
>> Odd idea.
>
>Consider the source ;-))
>
>>Must try how this looks like. ;)
>
>At the moment just pessimistic / defensive thinking from Mainhattan...
>
>regards
>thomas
I thought something like instantiating an APP object, raise an event via RAISEVENT that does READ EVENTS. since it is called by an event, the main.prg should proceed and the APP object stuck in READ EVENTS.
Elbflorenz is optimistic gray
Words are given to man to enable him to conceal his true feelings.
Charles Maurice de Talleyrand-Périgord
Weeks of programming can save you hours of planning.
OffThere is no place like [::1]