Dang, just about finished an app, and I was messing with making a script 
based menu. Some how, I have the start script doing an 'exit application'

Which means... When I open the file it automatically exits filemaker. Any 
one have an Idea how to keep it open to fix my error???

TIA

FYI all I have is FM 7 Pro. Anyone with 7 Dev, might be able to run the 
script debuger on this to help me out.

Thanks.

Dwight Ringdahl wrote:
> Dang, just about finished an app, and I was messing with making a script 
> based menu. Some how, I have the start script doing an 'exit application'
> 
> Which means... When I open the file it automatically exits filemaker. Any 
> one have an Idea how to keep it open to fix my error???
> 
> TIA

If you don't have Allow User Abort [Off] as a script step in your 
opening script, try using the esc key (windows) as you open the file, to 
bypass the script. Not sure what the Mac equivilent is.

Michael Myett

In article <Xns9553E4431D1C7dwr@216.77.188.18>, Dwight Ringdahl
<dr@dialaccess.net> wrote:

>Dang, just about finished an app, and I was messing with making a script 
>based menu. Some how, I have the start script doing an 'exit application'
>
>Which means... When I open the file it automatically exits filemaker. Any 
>one have an Idea how to keep it open to fix my error???

If you have related files, manually open one of the other files and force
the relationship to open the file with the startup script.  This will get
the file open without running the script.  Get to it by selecting it from
the "Windows" menu.

If there is no appropriate relationship, make one, with any field.  Go to
a layout and drag a field onto it from the file with the bad script across
the relationship.  This will force the file open as it attempts to display
the field contents.

All this is based on FM6.  If FM7's relationships work in a suifficiently
different way, pay no attention.

FYI, I've done this to myself a few times and I've taken to working with a
"stub," a one-record file.  One of its fields (I always call it
"constant") contains the number one.  In your main file, make a calc
field, also called "constant" where the calc is the number one.  Relate
the two via "constant."  I use this as a preferences file, a place to
store info in text and number fields I can't store in globals (in a
multi-user environment).

In this stub, make yourself a checkbox field (containing either one or
nothing, from a one-line value list), call it DEV_FLAG.  Back in your
working file, add this conditional to the script(s) you are developing:

If (stub::DEV_FLAG = 1)
    Halt script
else
    (lots of stuff)
    Exit Application
endif

This way, if you are tinkering with the startup script, you can control
its functioning by checking or unchecking the DEV_FLAG box.  If your
startup keeps crashing the app, open the stub by itself, uncheck the box,
then open the main file and the startup script will not run.

Steve Brown

Unfortunately, FM7 is different in this regard.   In 7, doing what Steve 
suggests will open the problem file as 'hidden'.  But as soon as you 
bring it to the foreground so that you can go into scriptmaker, it will 
run its opening script (and close the application).  Give it a try, but 
it should not work.  Unfortunately, I have no other suggestions I can 
think of.

eyebrown@mindspring.com wrote:

> In article <Xns9553E4431D1C7dwr@216.77.188.18>, Dwight Ringdahl
> <dr@dialaccess.net> wrote:
> 
> 
>>Dang, just about finished an app, and I was messing with making a script 
>>based menu. Some how, I have the start script doing an 'exit application'
>>
>>Which means... When I open the file it automatically exits filemaker. Any 
>>one have an Idea how to keep it open to fix my error???
> 
> 
> If you have related files, manually open one of the other files and force
> the relationship to open the file with the startup script.  This will get
> the file open without running the script.  Get to it by selecting it from
> the "Windows" menu.
> 
> If there is no appropriate relationship, make one, with any field.  Go to
> a layout and drag a field onto it from the file with the bad script across
> the relationship.  This will force the file open as it attempts to display
> the field contents.
> 
> All this is based on FM6.  If FM7's relationships work in a suifficiently
> different way, pay no attention.
> 
> FYI, I've done this to myself a few times and I've taken to working with a
> "stub," a one-record file.  One of its fields (I always call it
> "constant") contains the number one.  In your main file, make a calc
> field, also called "constant" where the calc is the number one.  Relate
> the two via "constant."  I use this as a preferences file, a place to
> store info in text and number fields I can't store in globals (in a
> multi-user environment).
> 
> In this stub, make yourself a checkbox field (containing either one or
> nothing, from a one-line value list), call it DEV_FLAG.  Back in your
> working file, add this conditional to the script(s) you are developing:
> 
> If (stub::DEV_FLAG = 1)
>     Halt script
> else
>     (lots of stuff)
>     Exit Application
> endif
> 
> This way, if you are tinkering with the startup script, you can control
> its functioning by checking or unchecking the DEV_FLAG box.  If your
> startup keeps crashing the app, open the stub by itself, uncheck the box,
> then open the main file and the startup script will not run.
> 
> Steve Brown

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California

FileMaker 7 Certified Developer
Associate Member, FileMaker Solutions Alliance