Hi, gang -

I have a script that's giving me trouble and I thought I'd get your
input. The script controls new record creation in a database that has
custom menus and a button bar for common functions. It's designed to
put users in the right place (field and layout) depending on active
field and window mode.

For example, if they're in Find mode and in the City field, it leaves
them in the City field when entering find, but if they're not in any
field, it will take them to the first field they're likely to search
in rather than the first field in the tab order. Similarly, if
they're in list layout in Browse mode, it will take them to a new
blank record in form layout.

I use a similar script in all my databases and haven't had a problem
before. However, although the script runs correctly on my computer
(Mac OS X, FM Adv 10), it's giving me problems on my client's
computers (Windows, FM Pro 8.02). Both sessions are currently single-
user. The relevant section of the script is as follows:

# form layout / browse mode
If [ PatternCount ( Get ( LayoutName ) ; "Form" ) and Get
( WindowMode ) = 0 ]
New Record/Request
Go to Field [ Table::Person ]
Exit Script [ ]
# form layout / find mode / no active field
Else If [ PatternCount ( Get ( LayoutName ) ; "Form" ) and Get
( WindowMode ) = 1 and IsEmpty ( Get ( ActiveFieldName ) ) ]
New Record/Request
Go to Field [ Table::Number ]
Exit Script [ ]
# form layout / find mode / active field
Else If [ PatternCount ( Get ( LayoutName ) ; "Form" ) and Get
( WindowMode ) = 1 ]
New Record/Request
Exit Script [ ]
etc.

What's happening is that when the user is in form layout in Browse
mode (first step above), the script goes to the field "Person," but it
skips the step "New Record." However, as I mention above, it performs
correctly on my machine.

I've reviewed the feature history for FM and don't see any problem
between versions 8 and 10. Could there be a difference between Mac
and Windows I'm not catching? Or perhaps something else?

Thanks in advance for your thoughts.
-J.

Is there anything that happens before the first script step you posted?
Maybe a re-login step?

The reason I ask is that I just discovered that the relogin step (and
perhaps others) need a pause after them before they can perform certain
other script steps. This is a bug and I've reported it to FileMaker.

Another possibility is that your script has Set Error Capture [On] and
prior to running this script data entry was done and the field
validation is failing. In this case, you would get no warning and the
new record would not be created.

If you have FM Pro Advanced, what happens when you step through your
script using debugger? Any error codes? or it magically works perfectly?

Finally, you say you are on 8.0v2, but the latest version of 8.0 is v3.
Do you still have the problem after an upgrade?



jahn wrote:

Hi, Howard -

Good questions. The script steps prior to the ones I listed are If
statements for determining layout and table -- for example, if the
layout is a utility table for the developer, just make a new record;
if it's the admin table, show a message that new records can't be
created; if the layout isn't named with Form or List, exit the
script. These are to prevent new records from being created if, say,
the user is in a dialog layout and hits ctrl-N by accident.

I've run the script with error capture on as well as off and there's
no difference on my end, but then the problem isn't here, it's on my
client's machine, and there version always has error capture on.
Tomorrow I'll have them flip error capture off and see what the result
is.

The script debugger doesn't uncover anything, but that's to be
expected since my machine's not having any problems. If nothing comes
of the error capture experiment tomorrow, I'll seek out a Windows
machine with FM Advanced and see what I can find out.

Lastly, I erroneously thought my client was on FM 8.02, but they're
actually on 9.0v3.

Thanks again for your help. Any other ideas on the problem are
welcome. If I find out what's causing the trouble, I'll post it here.

Best,
-J.

Problem solved. When I spoke to my client this morning, he said he
was getting error messages of the type "cannot write to disk" whenever
he tried to input data. This made me think that even though he had
opened the file from email, he hadn't unzipped. I'd forgotten that in
Windows you can do that sort of thing, and I'd just assumed my client
had unzipped it before trying it out.

So the reason the New record button wasn't working was because new
records couldn't be created in the uncompressed file, even though he
could log on and navigate records, etc. Once he extracted the
database, it worked fine. Yet again, the kind of mistake that makes
me slap my head and say doh.

Thanks for your input.

Best,
-J.