VFP 8.0 - How to handle this.

I have multiple compiled .exes using VFP 8.0. Each one is called by a prg,
calls the form and when the form is destroyed, clear events is issued.
Now, I want to call each of these individual .exe's from another .exe. (a
form acting as a main menu). But the problem is that when I run the
individual .exe the entire app is closed because each .exe issues a clear
events in the destroy event.
I thought about creating a public variable when the main menu is
initialized. Then in each individual .exe during the destory event,
checking for the existence of the public variable. If it does not exist,
then the destory event would issue the clear events and act as normal. If
the public variable does exist, then the destory event would only release
the form and return to the main menu.
Is there a better way to handle this. I want to minimize changes to my
existing .exes.
Thanks,
John

Man-wai
Mon Mar 10 10:01:11 CDT 2008

> I thought about creating a public variable when the main menu is
> initialized. Then in each individual .exe during the destory event,
> checking for the existence of the public variable. If it does not exist,
> then the destory event would issue the clear events and act as normal. If
> the public variable does exist, then the destory event would only release
> the form and return to the main menu.

How about a DBF or maybe a registry instead of a public variable?

--
@~@ Might, Courage, Vision, SINCERITY.
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Xubuntu 7.04) Linux 2.6.24.3
^ ^ 23:00:01 up 12 days 8:48 0 users load average: 0.08 0.02 0.01
? ? (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa/

John
Mon Mar 10 10:09:14 CDT 2008

Thought about dbf, but if system closes prematurely, then field may not be
set properly for next run.
I'm not sure about registry? Any ideas?
Thanks,
John


"Man-wai Chang ToDie" <toylet.toylet@gmail.com> wrote in message
news:%23$HcB%23rgIHA.4712@TK2MSFTNGP04.phx.gbl...
>> I thought about creating a public variable when the main menu is
>> initialized. Then in each individual .exe during the destory event,
>> checking for the existence of the public variable. If it does not exist,
>> then the destory event would issue the clear events and act as normal.
>> If the public variable does exist, then the destory event would only
>> release the form and return to the main menu.
>
> How about a DBF or maybe a registry instead of a public variable?
>
> --
> @~@ Might, Courage, Vision, SINCERITY.
> / v \ Simplicity is Beauty! May the Force and Farce be with you!
> /( _ )\ (Xubuntu 7.04) Linux 2.6.24.3
> ^ ^ 23:00:01 up 12 days 8:48 0 users load average: 0.08 0.02 0.01
> ? ? (CSSA):
> http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa/

Stefan
Mon Mar 10 11:24:00 CDT 2008

> I thought about creating a public variable when the main menu is initialized. Then in
> each individual .exe during the destory event,

How about sending a parameter like "tlKeepReadevents" and
receiving it via LParameters line either in the "main.prg" of your
other.EXE, or directly in form.Init()


hth
-Stefan


"John Germany" <jgphotography@windstream.net> schrieb im Newsbeitrag
news:%233Hm8JrgIHA.4376@TK2MSFTNGP05.phx.gbl...
>I have multiple compiled .exes using VFP 8.0. Each one is called by a prg, calls the
>form and when the form is destroyed, clear events is issued.
> Now, I want to call each of these individual .exe's from another .exe. (a form acting as
> a main menu). But the problem is that when I run the individual .exe the entire app is
> closed because each .exe issues a clear events in the destroy event.
> I thought about creating a public variable when the main menu is initialized. Then in
> each individual .exe during the destory event, checking for the existence of the public
> variable. If it does not exist, then the destory event would issue the clear events and
> act as normal. If the public variable does exist, then the destory event would only
> release the form and return to the main menu.
> Is there a better way to handle this. I want to minimize changes to my existing .exes.
> Thanks,
> John
>
>
>



--
|\_/| ------ ProLib - programmers liberty -----------------
(.. ) Our MVPs and MCPs make the Fox run....
- / See us at www.prolib.de or www.AFPages.de
-----------------------------------------------------------

John
Mon Mar 10 11:29:52 CDT 2008

Thanks!

"Stefan Wuebbe" <stefan.wuebbe@gmx.de> wrote in message
news:unABnssgIHA.5780@TK2MSFTNGP06.phx.gbl...
>> I thought about creating a public variable when the main menu is
>> initialized. Then in each individual .exe during the destory event,
>
> How about sending a parameter like "tlKeepReadevents" and
> receiving it via LParameters line either in the "main.prg" of your
> other.EXE, or directly in form.Init()
>
>
> hth
> -Stefan
>
>
> "John Germany" <jgphotography@windstream.net> schrieb im Newsbeitrag
> news:%233Hm8JrgIHA.4376@TK2MSFTNGP05.phx.gbl...
>>I have multiple compiled .exes using VFP 8.0. Each one is called by a
>>prg, calls the form and when the form is destroyed, clear events is
>>issued.
>> Now, I want to call each of these individual .exe's from another .exe. (a
>> form acting as a main menu). But the problem is that when I run the
>> individual .exe the entire app is closed because each .exe issues a clear
>> events in the destroy event.
>> I thought about creating a public variable when the main menu is
>> initialized. Then in each individual .exe during the destory event,
>> checking for the existence of the public variable. If it does not exist,
>> then the destory event would issue the clear events and act as normal.
>> If the public variable does exist, then the destory event would only
>> release the form and return to the main menu.
>> Is there a better way to handle this. I want to minimize changes to my
>> existing .exes.
>> Thanks,
>> John
>>
>>
>>
>
>
>
> --
> |\_/| ------ ProLib - programmers liberty -----------------
> (.. ) Our MVPs and MCPs make the Fox run....
> - / See us at www.prolib.de or www.AFPages.de
> -----------------------------------------------------------
>