about scripts

[gaift]

when running a script file maker has the integrated feature of having a dialog that goes as follows:
Script:
then it has a button to continue
Then one below that says cancel.

I have the problem of users who click cancel even when their is a guided message specifically saying to not click cancel,
is there anyway that i can only have a button that says continue?

or even better change the dialog, instead of it saying
Script:
Continue
Cancel

i can have it show

(whatever message i want):
Continue.

 

[JeanW]

With the Continue and Cancel button, do you mean the two possible buttons in the status bar at the left when in Browse Mode ?

 

[gaift]

yes
in any case that you run a script can i omit the cancel and only have the user continue this way the user cant get trapped

 

[JeanW]

Make always your user interface in such a way the user will never have access to the Status bar.
Furthermore, make sure the user will never see FileMaker generated errormessages.

Those are all too easy to get a wrong interpretation by the user and will leave them usually in a complete wrong place in your application. Like in a layout with 0 records, not knowing what to do or where to go....

 

[gaift]

how would the script resume or the user be able to click on find which many people here would feel much more comfortable to click. Also in terms of removing the status bar, this would essenitally trap the user in a table layout of the records they had selected. With out the status bar asking to continue or cancel the script the user is essenitally locked into the table layout.

Is there any way i can just not have the cancel button.

 

[gaift]

As i was looking over the database, i realized i will need the status bar since the employees here would generally like to see how many records there are, is there also a way to disable the buttons on the status bar that will navigate the user through the different layouts.

 

[JeanW]

Basically, if you are the only user of the database, you can use everything, if there are more users, lock them out everything. Don't give them access to menus, side bars, scripts, or every little thing where they can walk around and...well 'kill' the application.

Script every move the user has to do in your database.
Therefore you need a few fields in every table.
The basic fields are f.i. (not limited)
zc_constant_cni = calculation indexed, number = 1
dateCreate_aed = auto enter Creation Date
dateModi_aed = auto enter Modification date
timeCreate_aeh = auto enter Creation time
timeModi_aeh = auto enter Modification time
nameCreate_aet = auto enter Creation Name
nameModi_aet = auto enter Modificatio Name
recordCount_cnu = calculation unstored = Get(TotalRecordCount)
recordFound_cnu = calculation unstored = Get(FoundCount)
recordNumber_cnu = calculation unstored = Get(RecordNumber)
recordSerial_aen = number Serial on creation increment 1

Now for your find problem. As I said in my previous post, you have to direct the user to a special made search layout.
They never have to search on every possible field in an input screen. An input screen is for the data input, a search screen is to search data.
The only way to do that is scripting.
On that layout you can put buttons (linked to scripts) where the user can Add a search request, include or exclude search items, cancel out the search screen and find the data. From there you direct the user to appropriate layouts if there are 0 records, 1 record or several records.
All of this without access to the status bar.
You can't just 'cancel' or remove the buttons on the status bar, just don't give access to that bar.
The only possible time you give access to that bar is when you put the user in preview mode, but even that can be scripted.

For a good searchprocess, you need 4 scripts to manage the search process and 4 scripts to manage the buttons.

As for the navigation through records without statusbar (and no you can't disable the buttons there, you have to hide and lock the status bar for the user)

To show how many records and where they are, use this calc.

recordShow_ctu = calculation text unstored =
"Record " & Get(RecordNumber) & " of "& Get(FoundCount) & " Found... " & Get(TotalRecordCount) & " Record" & Case( Get(TotalRecordCount) > 1;"s") & " Total."

This is a copy from my custom function where I use the functions directly, if you don't have Advanced, substitute the functions with the fields above.

Put this field as a insert Merge field on your layout.
This will give the users the informatioin about which record they or on and which one it is in the found set and which one in the total records.

As for the navigation from record to record, you can use 4 buttons.
1 to go to the first record
1 to go to the last record
1 to go to the previous record
1 to go to the next record

To script this you only need 4 scripts.
Go to record (First - Next - Previous - Last)
In FM 7/8 you can use 1 script for this and use parameters.

You can work further on this by presenting a dimmed button when the user reaches the last record or the first record.
And you can put a button on the layout linked to the script Show all records, to give the user access to all the records in the file.

HTH

 

[gaift]

Thanks for the help, theres just one thing im having trouble with. My supervisor asked that i make a layout that will be in a table view that can show the records in a list (similar to xcel style) that way if they need to see multiple records at one time and need to print it they can do so with that table view, the only problem im having with removing the status bar is that they need to click on continue to get out of the table view back into the previous layout they were in.
I also just realized i cant add a button to the table layout where they can just click to go back to the original layout.

 

[JeanW]

Be sure to make a special 'print' layout, exactly how the printout should be.

Put needed buutons on this layout (like Print and Back) and format those buttons to NOT be printed.
They will act on the layout, but not be printed.

 

[gaift]

is there a way where i can just make the layout a print preview in the body part of the layout and on the header i can just put the buttons to print and to go back to the table view?

 

[JeanW]

Inside your print script you can switch to preview mode, next you make a 'haltpoint' (user has to give OK for printing or not), redirect the user in accordance with the choice (print or not) and go back to the original layout or whatever records you want.

 

[gaift]

so the script would be
Enter preview mode
halt
(here am i supposed to have a conditional statement after i give a dialog that the user can print or not print)
then after the button is pressed i have them redirected back to the records.

 

[gaift]

Sorry again, but if i make a custom dialog asking if they want to print or not with two buttons being yes or no

Can i link those buttons to the conditional statement

Pseudo Code:

If(button clicked = "yes")
print page;
go to browse mode;
Else
go to browse mode;

/* I have them go to browse mode in both cases because
after they print i want them out so they dont get locked in preview mode, and they just go directly back to browse mode if they clicked no so they can modify the size of the columns or modify anything on the page they might want to be excluded and what not.
*/

 

[gaift]

never mind its simpler than i thought, i made it more complicated than i thought.

The scipt just needs to have the Print function
then the user can go to preview mode from there with the preview button
then if the user chooses cancel they will be redircted to browse mode and the layout they were on. if they print they will print the page then redirected to browse mode and the layout they were on.

for(i=0; i<100; i++) {
cout <<"Thanks for the Help JeanW" << "\n";
}

 

[JeanW]

Well...not sorry to say, I was waiting untill You came up with the right answer...and you did.

That-s the wau to learn the program. I hope you will find more and more of those little ways to do things.

Happy discovery and Happy FileMaking.

 

[gaift]

Thanks for the help,

But one thing i wanted to know,

IF the user clicked cancel on the print prompt filemaker
has its own dialog specifically saying "Print has been cancelled. Do you want to continue with this script."

Problem with that is some users may click cancel instead of continue and they will then be locked into the layout, is tehre anyway i can change the dialog? or just have it continue
the script without prompting the user?

 

[JeanW]

Use 'Allow User Abort' as first scriptstep.
It prevents or enables the cancellation of a script with Comm-Period (Mac) or ESC (Win)

The options are On or Off. You use this step any time you don't want users to exit your script prematurely.

By default, Allow User Abort is turned on for the entire script. In order to prevent a user from exiting a script you set it to off.
During development, let it On, to prevent to lock yourself out (or in). The moment your solution goes 'live' to users, turn all the Allow User Abort to Off.

Your next step should be the script step Set Error Capture.
Look in the Help file how to use this scriptstep.
Those two steps will give you, the developer, nearly full control over what a user can do in your application.

Also, all the scriptsteps using a 'dialogbox' has to be at Perform without dialog level.
Trap the error with the Set Error Capture step and guide the user in whatever direction you want.
As I said before, lock the user out of all the possible things where they can 'kill' your app. Don't think they never will. Believe me, they will try every possible key combination, just to see what the result will be...

Basically you can give them access to the status bar in two cases.
When a printed form needs to be reviewed before printing and for displaying a sub-summary report without printing.

 

[JeanW]

After re-reading your first post, there is a way to avoid the Cancel button in the status area, but it still is not such a good idea to show the bar to the user, exept in preview.

Start your script with Allow User Abort Off.
No way to interupt the script now.