scripts and other file maker capabilities

[gaift]

I have been told to create multiple databases with similar functionality in terms of the interface of the database, specifically to make the database so easy to use that one who has only the slightest knowledge of using a computer can use it. This bringing up certain topics:

First, when doing a find or when running a script on the side of hte database window filemaker prompts the user to either cancel or continue the script, being that im the only comp engineer intern (only comp engineer on site now since other intern left) with a bunch of chemical engineers, not many know what a script is, therefore i was asked if there was any way i can make a button that links the buttons that run the scripts to another button that i can make it seem more obvious than the "Continue or Cancel script" that filemaker provides.

Second, when having certain fields for a single record, i have made a table layout that would display all the records into a table similar looking to an excel spreadsheet however users will not be able to make changes to the table, in this table there are numerous fields therefore wanting to see one field in the table view may prevent seeing another at the same time since the program window isnt that large, does filemaker have the capablity of doing a sort of split screen similar to that of excel?

Thank you,
excuse me for my lack of knowledge of filemaker, im good with code but not so great with working with programs that restrict you to certain layouts.

 

[JeanW]

Hi gaift,

>>First, when doing a find or when running a script on the side of hte database window filemaker prompts the user to either cancel or continue the script, .....

Never let a user do a find in an input screen.

Make a 'special' find/search layout that the user can call with a button on the input screen.
Put all the needed fields on this layout.
In all my years as FM developer I never had an application where the user had to search on every possible field in the data input screen.

This search layout can be tweaked with all the functionalities needed to guide the user.

The start buton will call the find mode, hold FM in find mode while the user is making the input for the search routine.
A button connect to the scriptstep Resume script will fire up the find.
Trap for possible errors (within the script) and guide the user with a few dedicated messages.

At the final search, redirect the user to a list layout where he/she can make a choice to go to a unique record or, when the found set is one record, to go to the input screen (or whatever screen you want).
Seems to be a lot at first sight and sounds rather complicated, but if you want I can give you some simple links where you can find details.
Basically you need 2 layouts and 4 scripts for this.
Maybe less if we could know which version of FileMaker you use.
Because multiple databases can be now multiple tables in one database, again, depends on what your final goal or requirements are.

As for your second point, I'm sure there is another solution for this. If we have a more detail view on what the data is and how you want to display it, and also what the user has to see and why, we can come up with a 'database' solution, not a 'spreadsheet' solution.

 

[gaift]

Thank you, the links would be a big help.
So what youre saying is i should make a "find" layout with the fields people will be searching in and have that layout serve as the "easy way"/user friendly interface. Using scripts that will guide the user in their find and using relationships to tie the rest of the fields together. In terms of having every possible field in the layout, may be true that they dont need to search through every specific detail, however the database i am creating is supposed to be designed so that the users can search through different criteria (in my case, diameter, volume, quality, quantity, etc.)

Also on the group layout i have, i want to make it so the user can not change information in that layout, i just want them to
be able to view it? How can i restrict them from doing so without defining user accounts.

 

[JeanW]

>... the links would be a big help.
Look at

http://filemakeradvisor.com/doc/08899

for a first idea. It's maybe an old one, but the information is basic and still valid.

> So what youre saying is i should make a "find" layout with the fields people ..... (in my case, diameter, volume, quality, quantity, etc.)

Yes indeed, this is the right way to go to avoid problems in the future, to know at every single moment where the user should be in the application and to make sure the user IS there.

>Also on the group layout i have, i want to make it so the user can not change information in that layout,.....without defining user accounts.

Again, split the layouts. Make an input layout and a 'view' layout, which can be a simple copy of the input layout, but with all the fields not enterable.
You need a strict navigation system for this, but with the power of ScriptMaker, this is a one time work.

If you need help with this, feel free...

Basic rule is to give the user only access to fields/layouts which are necessary 'to do the job'. Nothing more.

 

[gaift]

Thanks for the links and help, you truly are an "mvp".

With the algorithm you mentioned, could i simply follow the simple steps to create one with record input and viewing. I would like to seperate the user from viewing a record and an input/edit form, that way they know what they are actually about to do.

For instance, I would like the user to look at the records in browse mode but not allow them to input data there, this way they wont accidently press the keyboard that may essentially alter the record, to modify the record or actually input a new one i would have them click a button that i can add to the interface, which would then take them to an "input" layout where they can only change what they intended to.

Is this along the lines of making the database "Idiot-Proof"?

 

[JeanW]

You have to think about one thing when making a database 'Idiot-Proof'. They become smarter.....

But yes, that's it. Look in the help file for info about fieldvalidation f.i.

With fieldvalidation you can prevent altering fields with e.g. a flagField.
When the user want/need to change the value of a given field, make it possible with a script.
(this is pseudo-code):
Trigger the script with a button on the locked layout.
Go to the layout were the fields can be changed.
If you're in FM7, use the scriptparameter to trap which field it is.
Remove the flag on this field (it will be on this field alone) by putting the script in a loop (this will prevent clicking outside the layout or changing another field etc, make the change.
Provide a sort of 'register' button to accept the new value and reset the flag, so the field will be locked again, ready for the next change.

Another way could be, if the info on the layout allow it, to make a layout with all the fields that are allowed to be changed. Below those fields you can put globalfields with the same name/label(the original fields are not enterable).
With a 'register' button/script you can change the values of the 'real' fields with a loop part in the script and a set field that will loop through the fields and set the 'realfield' = 'globalfield'....

Those are just ideas you can work with. Not knowing your application or how the user are using it, it kind of hard to give a real good workaround.

But, this is FileMaker. You can put a lot of your own imagination as developer in it.