Quit To ...

There used to be a DOS-days (Foxbase?) command

QUIT TO <Some other app>

where <Some other app> would start automatically after exiting Fox.

I could probably replicate this by creating a batch file (using some
commands I have forgotten) to start the initial app, but I have a
feeling there's a way to do it inside VFP9SP2 - or maybe with a dll?

Any suggestions?

Steve

Gene
Fri Jul 04 15:51:19 CDT 2008

Steve Meyerson <stevemeyerson@verizon.net> wrote:

>There used to be a DOS-days (Foxbase?) command
>
> QUIT TO <Some other app>

I am not sure that it was in MS-DOS days. I do remember it from
dBASE II under CP/M.

>where <Some other app> would start automatically after exiting Fox.
>
>I could probably replicate this by creating a batch file (using some
>commands I have forgotten) to start the initial app, but I have a
>feeling there's a way to do it inside VFP9SP2 - or maybe with a dll?
>
>Any suggestions?

Use the run command.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Fred
Fri Jul 04 16:02:43 CDT 2008

I don't think there ever was a QUIT TO in Fox anything. There is a RETURN
TO, but that won't do what you want. You may be able to just start your VFP
app within a .BAT or .CMD file that has what ever you want to run after your
app.

--
Fred
Microsoft Visual FoxPro MVP


"Steve Meyerson" <stevemeyerson@verizon.net> wrote in message
news:lf0t64dgn2fjpnfbabi7fmvisstfcvu82i@4ax.com...
> There used to be a DOS-days (Foxbase?) command
>
> QUIT TO <Some other app>
>
> where <Some other app> would start automatically after exiting Fox.
>
> I could probably replicate this by creating a batch file (using some
> commands I have forgotten) to start the initial app, but I have a
> feeling there's a way to do it inside VFP9SP2 - or maybe with a dll?
>
> Any suggestions?
>
> Steve

Sergey
Fri Jul 04 16:36:22 CDT 2008

Steve Meyerson wrote:
> There used to be a DOS-days (Foxbase?) command
>
> QUIT TO <Some other app>
>
> where <Some other app> would start automatically after exiting Fox.
>
> I could probably replicate this by creating a batch file (using some
> commands I have forgotten) to start the initial app, but I have a
> feeling there's a way to do it inside VFP9SP2 - or maybe with a dll?
>
> Any suggestions?
>
> Steve

Steve,

You can use SHELLEXECUTE() Win API to launch any external program

--
--sb--

VFP MVP

Dan
Fri Jul 04 19:26:43 CDT 2008

As others have said, there's never been such a feature in Fox-anything. I'm
not sure how it would work, anyway. QUIT halts the current process and
implicitly hands control back to whatever started the process in the first
place.

You *may* be thinking of QUIT <exprn>, which allowed you to set an MS-DOS
ERRORLEVEL that could be tested in .BAT files.

Dan

Steve Meyerson wrote:
> There used to be a DOS-days (Foxbase?) command
>
> QUIT TO <Some other app>
>
> where <Some other app> would start automatically after exiting Fox.
>
> I could probably replicate this by creating a batch file (using some
> commands I have forgotten) to start the initial app, but I have a
> feeling there's a way to do it inside VFP9SP2 - or maybe with a dll?
>
> Any suggestions?
>
> Steve

Steve
Sat Jul 05 10:51:35 CDT 2008

On Fri, 4 Jul 2008 17:26:43 -0700, "Dan Freeman" <spam@microsoft.com>
wrote:

>As others have said, there's never been such a feature in Fox-anything. I'm
>not sure how it would work, anyway. QUIT halts the current process and
>implicitly hands control back to whatever started the process in the first
>place.
>

Dan,
Thanks. I'm sure you know more Fox stuff than I, but I'm probably the
older one :(. It may have been as far back as dBASE II, but I'm
positive and I'd be willing to bet there was a QUIT TO command early
in the xBase days. Hopefully someone (Wayne Ratliff?) can back me up
on this - or maybe I'm getting TOO old?

What I'm actually trying to do is allow my user to switch from one of
my exe's (Divorce.exe) to another (different) exe with the same name
but in a different state's folder.

Another question: Can I have the user run 2 or more of these exe's at
the same time while using only one set of runtime files in
\Windows\System32 ?

Steve

Fred
Sat Jul 05 12:27:19 CDT 2008

Sure, multiple .EXEs can be run off of the same runtimes, no problem. They
just all have to be started from the OS directly or the RUN /N command or
the API as Sergey suggested. If you use DO, you can't run them separately.

--
Fred
Microsoft Visual FoxPro MVP


"Steve Meyerson" <stevemeyerson@verizon.net> wrote in message
news:4c4v6497rbkega4nmhv942ph410835a8vt@4ax.com...
> On Fri, 4 Jul 2008 17:26:43 -0700, "Dan Freeman" <spam@microsoft.com>
> wrote:
>
>>As others have said, there's never been such a feature in Fox-anything.
>>I'm
>>not sure how it would work, anyway. QUIT halts the current process and
>>implicitly hands control back to whatever started the process in the first
>>place.
>>
>
> Dan,
> Thanks. I'm sure you know more Fox stuff than I, but I'm probably the
> older one :(. It may have been as far back as dBASE II, but I'm
> positive and I'd be willing to bet there was a QUIT TO command early
> in the xBase days. Hopefully someone (Wayne Ratliff?) can back me up
> on this - or maybe I'm getting TOO old?
>
> What I'm actually trying to do is allow my user to switch from one of
> my exe's (Divorce.exe) to another (different) exe with the same name
> but in a different state's folder.
>
> Another question: Can I have the user run 2 or more of these exe's at
> the same time while using only one set of runtime files in
> \Windows\System32 ?
>
> Steve

Zootal
Sat Jul 05 14:52:14 CDT 2008

The only Quit To that I can remember back then was Quit to DOS - not Quit to
<some other app>. Quit doesn't take any parms, so you can't even tell it
what to run after it quits. I've used Dbase II and III, and I don't recall
anything like that. Might you be thinking of RETURN TO? That allows you to
return to a desired level of the stack that is above you.

> Dan,
> Thanks. I'm sure you know more Fox stuff than I, but I'm probably the
> older one :(. It may have been as far back as dBASE II, but I'm
> positive and I'd be willing to bet there was a QUIT TO command early
> in the xBase days. Hopefully someone (Wayne Ratliff?) can back me up
> on this - or maybe I'm getting TOO old?
>
> What I'm actually trying to do is allow my user to switch from one of
> my exe's (Divorce.exe) to another (different) exe with the same name
> but in a different state's folder.
>
> Another question: Can I have the user run 2 or more of these exe's at
> the same time while using only one set of runtime files in
> \Windows\System32 ?
>
> Steve

Dan
Sat Jul 05 15:12:04 CDT 2008

Steve Meyerson wrote:
> On Fri, 4 Jul 2008 17:26:43 -0700, "Dan Freeman" <spam@microsoft.com>
> wrote:
>
>> As others have said, there's never been such a feature in
>> Fox-anything. I'm not sure how it would work, anyway. QUIT halts the
>> current process and implicitly hands control back to whatever
>> started the process in the first place.
>>
>
> Dan,
> Thanks. I'm sure you know more Fox stuff than I, but I'm probably the
> older one :(. It may have been as far back as dBASE II, but I'm
> positive and I'd be willing to bet there was a QUIT TO command early
> in the xBase days. Hopefully someone (Wayne Ratliff?) can back me up
> on this - or maybe I'm getting TOO old?
>
> What I'm actually trying to do is allow my user to switch from one of
> my exe's (Divorce.exe) to another (different) exe with the same name
> but in a different state's folder.
>
> Another question: Can I have the user run 2 or more of these exe's at
> the same time while using only one set of runtime files in
> \Windows\System32 ?
>
> Steve

Yeah, Gene says it existed in dBase II on CP/M. I'm almost certain it did
NOT make it into dBase III but that goes back a LONG way! <s>

I'm curious why you have different exes for each state. Wouldn't it make
more sense to have one core EXE, with state-specific behavior driven by
meta-data? Then you could switch states by switching meta-data instead of
messy chained exes.

Dan

Steve
Sat Jul 05 19:08:36 CDT 2008

On Sat, 5 Jul 2008 13:12:04 -0700, "Dan Freeman" <spam@microsoft.com>
wrote:
>
>Yeah, Gene says it existed in dBase II on CP/M. I'm almost certain it did
>NOT make it into dBase III but that goes back a LONG way! <s>
>
>I'm curious why you have different exes for each state. Wouldn't it make
>more sense to have one core EXE, with state-specific behavior driven by
>meta-data? Then you could switch states by switching meta-data instead of
>messy chained exes.
>
>Dan
>
I started with that approach, and I'm sure I could make it work, but
switched for several reasons. The program would have to be huge and
more difficult to maintain because unlike bankruptcy, the divorce laws
and requirements can vary tremendously from state to state. Their
interfaces would be somewhat different and the data required will
vary. For example in my state of Virginia (which is where my program
is used now), it varies from city to city and in Newport News it even
varies some from judge to judge (6 of them).

The other (and perhaps more compelling) factor is I envision selling
individual "modules" for each state as my client expands his horizons.
If I have to maintain 56 (incl. territories) separate exe's, I'll be a
happy (and rich) man :)

Steve

Gene
Sat Jul 05 22:35:04 CDT 2008

"Dan Freeman" <spam@microsoft.com> wrote:

[snip]

>Yeah, Gene says it existed in dBase II on CP/M. I'm almost certain it did
>NOT make it into dBase III but that goes back a LONG way! <s>

It did not make it into III AFAICR. quit to depended on on
CP/M's handling of submit files (the CP/M equivalent of batch files).

>I'm curious why you have different exes for each state. Wouldn't it make
>more sense to have one core EXE, with state-specific behavior driven by
>meta-data? Then you could switch states by switching meta-data instead of
>messy chained exes.

He might have to call an external program. I have suggested that
he look at the run command.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Dan
Sun Jul 06 02:55:22 CDT 2008

Steve Meyerson wrote:
> On Sat, 5 Jul 2008 13:12:04 -0700, "Dan Freeman" <spam@microsoft.com>
> wrote:
>>
>> Yeah, Gene says it existed in dBase II on CP/M. I'm almost certain
>> it did NOT make it into dBase III but that goes back a LONG way! <s>
>>
>> I'm curious why you have different exes for each state. Wouldn't it
>> make more sense to have one core EXE, with state-specific behavior
>> driven by meta-data? Then you could switch states by switching
>> meta-data instead of messy chained exes.
>>
>> Dan
>>
> I started with that approach, and I'm sure I could make it work, but
> switched for several reasons. The program would have to be huge and
> more difficult to maintain because unlike bankruptcy, the divorce laws
> and requirements can vary tremendously from state to state. Their
> interfaces would be somewhat different and the data required will
> vary. For example in my state of Virginia (which is where my program
> is used now), it varies from city to city and in Newport News it even
> varies some from judge to judge (6 of them).
>
> The other (and perhaps more compelling) factor is I envision selling
> individual "modules" for each state as my client expands his horizons.
> If I have to maintain 56 (incl. territories) separate exe's, I'll be a
> happy (and rich) man :)
>
> Steve

Thanks for that explanation!

To be honest, I would kill myself before taking on 56 versions of the same
software.

The software suite I'm currently helming actually runs in all 56
states/territories. (Really!) The code can get pretty gnarly, but it's one
set of code that runs everywhere.

And take it from me that selling individual "modules" (which is something we
do) will only further complicate your life if they're different for each
state.

Imagine getting in a change request that MUST be done. But you can't just do
it once. You have to do it 1*56 times. And if it affects optional modules
(and it always will) you have to do it 1*56*56 times. The first time you get
a 2*56*56 request you'll wish you'd abstracted a little more and had a
single code base.

You might get rich, but forget about sleep. ;-)

Dan

Steve
Sun Jul 06 06:46:30 CDT 2008

On Sun, 6 Jul 2008 00:55:22 -0700, "Dan Freeman" <spam@microsoft.com>
wrote:
>
>To be honest, I would kill myself before taking on 56 versions of the same
>software.
>
>The software suite I'm currently helming actually runs in all 56
>states/territories. (Really!) The code can get pretty gnarly, but it's one
>set of code that runs everywhere.
>
>And take it from me that selling individual "modules" (which is something we
>do) will only further complicate your life if they're different for each
>state.
>
>Imagine getting in a change request that MUST be done. But you can't just do
>it once. You have to do it 1*56 times. And if it affects optional modules
>(and it always will) you have to do it 1*56*56 times. The first time you get
>a 2*56*56 request you'll wish you'd abstracted a little more and had a
>single code base.
>
>You might get rich, but forget about sleep. ;-)
>
>Dan
>

Excellent point, Dan. I still have time to change my mind. Actually,
there may be 57 states & territories instead of 56. As I recall, Obama
talked about "all 57 states" in one of his campaign's misspeaks (among
many from both sides).

Thinking "out loud", even if there were only one exe, it may have to
contain multiple "sections" for the states. It would depend on how
different the states are - I'll have to see. I could write each
"section" as if it were a separate program, then combine them into a
single exe where the user just selects a state. That could be almost
as unweildly as separate projects would be.
Steve

Steve
Sun Jul 06 07:00:06 CDT 2008

On Sat, 05 Jul 2008 20:35:04 -0700, Gene Wirchenko <genew@ocis.net>
wrote:

> It did not make it into III AFAICR. quit to depended on on
>CP/M's handling of submit files (the CP/M equivalent of batch files).

Gene,
I was convinced it was in the CP/M version, but then I Googled & found
this in a document called "Rainbow dBASE II an MS-DOS Application
Command and Reference Pocket Guide"

http://vt100.net/mirror/antonio/aacl61axv.pdf

Here's what it says about QUIT on pg 11 (pdf 17):

QUIT [TO <list MS-DOS level commands or .COM files>]
terminates dBASE II and returns control to operating system.
Optionally calls system level programs.
(See G1-5)

??

Steve