1) No, no easy way. Basically you can set the name (or number) of the current layout into a global field EVERY time you leave a layout. Then your back button would use that. This means ALL navigation must be scripted; which it seems that it is.

Another possibility is to put buttons on only certain layouts, which have an obvious connection to another. This is usually what I do; because I don't want to deal with the above. My arrows in the portals are an example.

Your solution has a "menu" based navigation, in that clicking the icon returns you to the "menu" page, then you start off again. Another alternative is the "tab" based navigation, with a fairly uniform group of tabs on most layouts. Works fairly well on most solutions; but is more work; and a different layout look entirely.

Ideally you might have all of these systems. But that's a lot of work.

2) Is this on a Mac? It is more difficult when you're running plain FileMaker. Server can do this properly. But in either case you'd need to do something to save dated backups. Generally people use Server to do a backup, then have a dedicated backup program backup those files to another disk. But NEVER let a backup program touch the live files.

In your case, with plain FileMaker you would need someone on the host machine to run the Copy As script. It has to be the host computer (which has to ALWAYS open first anyway).

[it could I suppose be scheduled with an app like Cronnix, which can call an AppleScript, to tell FileMaker to run the script.]

FileMaker would Copy As to a fixed location, then a Perform AppleScript step could move/rename the file. Needless to say, you don't really want this to happen while people are working much on the file.

Easiest is to run the script, with the Perform AppleScript to move/rename afterwards on opening. It's not hard to set the date into a global, then check to see when it was last done. People would have to wait until it was finished. But with a small file like this it wouldn't take long.

3) Do you know whether you're in an Adar I & II year? If so, how?

In any case, you can add requests, use "exact" Finds with "==", to deal with it. But if you knew which kind of year you wouldn't need all 3 choices in the value list; just "Adar", let the script add what's needed. Otherwise does someone know which Adar they want?

Ideally you might have all of these systems. But that's a lot of work.

That sounds like way more than I want to bite off. If it was easy, (I thought I might be missing something basic) I would want to add it. but basically, you might end up at the Individuals List from a variety of ways. They will just have to click around. This is still SO much better than what they currently have in place.

In your case, with plain FileMaker you would need someone on the host machine to run the Copy As script. It has to be the host computer (which has to ALWAYS open first anyway).

FileMaker would Copy As to a fixed location, then a Perform AppleScript step could move/rename the file. Needless to say, you don't really want this to happen while people are working much on the file.

Easiest is to run the script, with the Perform AppleScript to move/rename afterwards on opening. It's not hard to set the date into a global, then check to see when it was last done. People would have to wait until it was finished. But with a small file like this it wouldn't take long.

Ultimately, this will run on a small group of networked Macs (3-4). I currently have the on close script set to run only when the User is Office (the main computer where the file will reside.) It simply prompts a Save As dialog. I may try to add in the Applescript, but I know even less about Applescript than I do about Filemaker.

3) Do you know whether you're in an Adar I & II year? If so, how?

Me, personally, I don't know. But it could easily be looked up for the next 20 years or so.

In any case, you can add requests, use "exact" Finds with "==", to deal with it. But if you knew which kind of year you wouldn't need all 3 choices in the value list; just "Adar", let the script add what's needed. Otherwise does someone know which Adar they want?

This makes a lot of sense. I have to think through how I would get it to do that. Something like:

If _gMonth = Adar

If get (current year) = Adar only

set _gMonth = Adar

Else

set _gMonth (what here? ==AdarI?)

(how to I get it to add the Adar yahrzeits here? - expand find ==Adar?)

do all script stuff

set _gMonth, Adar II

do all script stuff

End If

End If

I am assuming a put another little table in to check if it is an Adar only or Adar I/II (Leap) kind of year?

The following years are leap years: 05, 08, 11, 14, 16, 19, 22, 24. (I looked it up using Hebcal.com) If I remember correctly it is a 13 year cycle with 7 leap years. (What can I say...) Leap years have the Adar I/II. Regular years just have Adar.

There are entire books written on the Jewish Calendar...

The AppleScript is fairly simple. I'd be glad to do it.

It seems to me a simple calculation could tell you whether it was a leap year; for quite a while.

"==Adar"

would be an exact find for only "Adar"

So you'd look at _gMonth with a Case ( ) calculation, then build the Find request accordingly. To find Adar and Adar I, you could use 2 requests with exact criteria; or you could just find "Adar", to get them all, then omit "Adar II".

My husband is kicking me off of my computer to transfer all the data to my new Powerbook. (He does not trust me to do this operation by myself. - He is not willing to risk that I might lose this database and then he would lose me for another 2 weeks.) I may go through withdrawl.

I am eager to get working on the Adar problem. I will let you know when (realistic) I run into problems. It is still fuzzy. And now I have to look up the Case function!

Thanks.

BTW, they are really blowing me away on the Hebrew calendar. (In Brain Food.) I feel like I have an army of experts helping me out. This really is a great place. Can I move in?

You seem fairly capable; but heck, if he wants to do it....

I have the AppleScript to rename the backup; just waiting on your next version. It's getting difficult to keep all the updates synced; some features are in one, some, but not those, in a later.

BTW, you need to keep those container fields the right size; don't squish 'em; 1 pixel on a side bigger than the original layout object (this is a bug in 7, may be fixed; used to be exact size would work). I use the Crop option myself. Small icons look best just as they are.

This is what a Case would look like to "mark" a leap year; it's a simple one. I added a Let() to shorten it. You would put this in the script, to fork to a different action. If it's a calculation field, it needs to be "do not store."

Let (

date = Get(CurrentDate);

Case (

Year(date) = 2005 or Year(date) = 2008 or Year(date) = 2011 or Year(date) = 2014 or Year(date) = 2016 or Year(date) = 2019 or Year(date) = 2022 or Year(date) = 2024;

1;

"")

)

One thing to know about Case: it stops at the first true result. So you can "stack" the answers.

Coming right up.

I added a record or two for you this time.

I just got my computer back. I am capable, but sometimes you just have to let the man be manly. For him, upgrading computers is a man job. What can I say...

I have to go to work (real work - where they actually pay me) this morning. I am going to take my computer with me and try to get satrted on this, so I eagerly await your response.

SynDB.fp7.zip

OK, I've put all the features from all the versions together in this one. So, if you've been working on another, please either transfer your new work to this one, or transfer ALL the features to yours. But please don't post a partial file.

I came up with a new idea for the Yarhzeit month problem. You need 2 different value lists, 2 choice layouts for the month. The script checks whether it's a Leap year, then goes to the right list.

Then the Find part of the script adds what's needed to find the right Adar (if any).

There's a 3rd "all" list, for data entry. Though even that could toggle, if you knew the year.

My AppleScript rename-the-backup script is installed. But it only kicks in if the file name is "Synagogue.fp7" It doesn't if there's a version name on the file (which I put 9, so I could tell what's what; I had 3 files).

I set the backup file name to be "Synagogue_bak.fp7" That name is something that can't be scripted, neither can it be passed directly to AppleScript. So one has to decide on a fixed name if you expect AppleScript to find the darn thing. If it does find it, it would rename it to "Synagogue_bak_12_30.fp7" today.

If there's already one of that name it won't do it, but will tell you so. It could alternatively delete the existing one first. But it will still backup; it just won't do the renaming. This is something to decide and fine-tune I guess.

There are 2 extra fields on the "main" layout, the backup file filepath (calculation) and the current month & day calculation. The have white text, and non-enterable; but they have to be there, so AppleScript can easily read them.

I changed your conditions for backup. CurrentUserName is not very good, as it belongs to the computer, and can be easily changed. I used PrivilegeSetName. It's more reliable. It checks whether it's the host computer with Get(MultiuserState).

[There's also a field in the definitions, so that it could zip the backup, using a "do shell script" step; that seemed like overkill, but I left it for general interest.]

Synagogue9.zip

Okay, so, while you did all that, I was proud of myself for fixing my little label printing problem (it was only printing 9 labels per column instead of 10). That would illustrate the difference between "beginner" and "advanced" users!

I will definately go with putting my data/changes into your database! It is going to take a while for me to sort through and understand everything that you have done. I will probably tweek the delete family/mark yahrzeit script as there is at least one other thing I want it to check (if there is a "location," we will keep it.)

I also think I figured out a more elegant way to move a child from one family to another for when they grow up and become their own member. - make new family record, change Fid of Indiv. record through a custom dialog box, change status. (Right now, I make the user go through this whole rigamaroll involving TextEdit.)

I will also try to add the hebrew date calculator that -Queue- and comment have been working on so furiously.

I guess you won't hear from me for a while, as I sort through all of this, but don't think that I am not working on it!

Thank you, thank you, thank you.

Jessica

I have been pouring over the file you uploaded. I noticed that on the Delete Family Mark Y script, the first command is "Commit Records/Requests [No dialog].

I am wondering what the rational is behind that. Is that a step that I should be adding to the beginning of a lot of my scripts?

The Commit Records/Requests step is equivalent to clicking out of the record. It commits any changes that may have been made on existing records and establishes new records as part of the file. It is also sometimes necessary to use when setting key fields for relationships. Overall, it's a good step to start with and put after vital Set Field steps to ensure that your script performs as it should.

I often add a test for an error after the step, which means that the record cannot be committed due to invalid information being input, such as text in a date field, etc.