I’m working on an idea to use it in the whole DB. Date Range search.

By now it makes the work, but the question is, Am I doing it too complicated?

One Table:

- Searches

Two fields:

- StartDate: date (global).

- EndDate; date (global) .

Two scripts:

First:

- DateRange

Set Field [ Searches::StartDate ; "" ]

Set Field [ Searches::EndDate ; "" ]

Beep

Show Custom Dialog [ Title: "Date Range"; Message: "Please set dates"; Default Button: “Accept”, Commit: “Yes” ; Input #1: Searches::StartDate , "Start Date"; Input #2: Searches::EndDate , "End Date" ]

Set Variable [ $StartDate ; Value:Searches::StartDate ]

Set Variable [ $EndDate ; Value:Searches::EndDate ]

Set Variable [ $$DateRange ; Value:$StartDate & "..." & $EndDate ]

Second:

- Search between dates:

Perform Script [ “DateRange” ]

Show Custom Dialog [ Title: "Type of date selection"; Message: "Select the TYPE OF DATE you want to search"; Default Button: “DOB”, Commit: “Yes” ; Button 2: “DOCreation” , Commit: “Yes” ]

If [ Get ( LastMessageChoice ) = 1 ]

Perform Find [ Specified Find Requests: Find Records ; Criteria: TABLEOFMYDATA::DOB : “$$DateRange” ]

[ Restore ]

Else If [ Get ( LastMessageChoice ) = 2 ]

Perform Find [ Specified Find Requests: Find Records ; Criteria: TABLEOFMYDATA::DOCreation : “$$DateRange” ]

[ Restore ]

End If

Set Variable [ $$DateRange ; Value:"" ]

Any advice?

Some things that come to mind:

You could do without the dialog; put the fields on a layout, with two buttons “Search DOB” and “Search DOC”.

Unless you want to re-use the date setting part in other scripts, you might as well put everything in one script and use only one Custom Dialog. (Also I think that every input- or action-oriented dialog (as opposed to alerts and messages) should have a Cancel button; users are notorious for changing their minds.)

Why map purpose-built global fields to variables when you don't do any further processing? You could calculate the global variable from the date fields themselves. (Strictly speaking, you wouldn't even need that one, but keeping the calculation logic outside of Perform Find's ”black box“ makes it clearer.)

Lastly, there is no error checking in the second script: empty global fields, start date > end date, no records found …

One more thing: Naming a table Searches implies that it will store Searches (or Finds, depending). If it serves merely as a table for globals, maybe better call it so.

eos makes some good points. I would add, are you asking how to make it simpler for you, or simpler for your users? And, does simpler = better?

For example, you could "simply" train users how to do a date range search in FileMaker.

Starting by the end:

Fitch, by now I am my own user, lol.

eos: first thanks for your ideas.

1. I buy that one, I think I'll use buttons and let the script parameter make the rest.

2. I want to use it as a search in the entire DB. Cancel button: you are right again, I also buy that one. A way to desist is always welcome.

I don't know exactly what you mean in your fourth paragraph, I think my knowledge doesn't go that far.

I'll try to "find" another name for the table.

Thank you guys.