DayBackForFileMaker

Event Variables

DayBackForFileMaker.EventVariables History

Hide minor edits - Show changes to output

Changed lines 15-19 from:
When working with a particular source in the calendar we load the facts of that source to global variables (those variables beginning $$). If you need to know the name of a particular variable, you have two options:

-> If you have FileMaker Advanced, run
the script "Dev ON" and then refresh the calendar. This script stops us from clearing all the calendar variables in use, so you can see your SQL queries, our $$sc_iCal variables, and all the variables used for event field mapping. (This is great for general [[debugging]] as well.)

-> If you don't have FileMaker Advanced, the script "Clear Source Variables" lists all the variables we use= here
.
to:
When working with a particular source in the calendar we load the facts of that source to global variables (those variables beginning $$). If you need to know the name of a particular variable, check out the script "Clear Source Variables". That lists all the variables in use.
May 20, 2012, at 02:42 AM by 50.132.84.245 -
Changed lines 17-20 from:
-> If you have FileMaker Advanced, run the script "Dev ON" and then refresh the calendar. This script stops us from clearing all the calendar variables in use, so you can see your SQL queries, our $$sc_iCal variables, and all the variables used for event field mapping. (This is great for general [[debugging]] as well.

-> If you don't have FileMaker Advanced, the script "Clear Source Variables" lists all the variables used here.
to:
-> If you have FileMaker Advanced, run the script "Dev ON" and then refresh the calendar. This script stops us from clearing all the calendar variables in use, so you can see your SQL queries, our $$sc_iCal variables, and all the variables used for event field mapping. (This is great for general [[debugging]] as well.)

-> If you don't have FileMaker Advanced, the script "Clear Source Variables" lists all the variables we use= here.
April 16, 2012, at 04:29 PM by 166.137.8.133 -
Changed lines 9-10 from:
If you're only using one source for your events, that's all there is to it. If you're using multiple sources, you may need to test which source is active so you know which field to set, etc. The active source is recorded within most scripts as $sc_SourceNo.
to:
If you're only using one source for your events, that's all there is to it. If you're using multiple sources, you may need to test which source is active so you know which field to set, etc. The active source is recorded as $$sc_SourceNoLoaded.
April 16, 2012, at 08:59 AM by 78.86.120.203 -
Changed lines 5-6 from:
However, once you have integrated the calendar into your own file, you don't really need to keep up the abstraction. For example, if you have a field called "Priority" in your events table and want to make sure that when you create a new event this field is always set to "1", you can just use a regular SetField script step... you don't need to use SetFieldByName as you no longer need the calendar to be portable.
to:
However, once you have integrated the calendar into your own file, you don't really need to keep up the abstraction. For example, if you have a field called "Priority" in your events table and want to make sure that when you create a new event this field is always set to "1", you can just use a regular SetField script step... you don't need to use SetFieldByName as you no longer need the calendar to be portable. 
Added lines 9-10:
If you're only using one source for your events, that's all there is to it. If you're using multiple sources, you may need to test which source is active so you know which field to set, etc. The active source is recorded within most scripts as $sc_SourceNo.
Changed lines 19-21 from:
-> If you don't have FileMaker Advanced, the script "Clear Source Variables" lists all the variables used here. In addition, the script "Load Source Settings at Startup..." loads a few variables about the table occurrence name of the selected source like $$sc_SourceTableOccurenceName.
to:
-> If you don't have FileMaker Advanced, the script "Clear Source Variables" lists all the variables used here.

In addition, the script "Load Source Settings at Startup..." loads a few variables about the table occurrence name of the selected source like $$sc_SourceTableOccurenceName. These are broken out by repetition so the table occurrence name for source no. 2 is $$sc_SourceTableOccurenceName[2].
April 16, 2012, at 08:54 AM by 78.86.120.203 -
Changed lines 15-17 from:
-> If you have FileMaker Advanced, run the script "Dev ON" and then refresh the calendar. This script stops us from clearing all the calendar variables in use, so you can see your SQL queries, our $$sc_iCal variables, and all the variables used for event field mapping.
to:
-> If you have FileMaker Advanced, run the script "Dev ON" and then refresh the calendar. This script stops us from clearing all the calendar variables in use, so you can see your SQL queries, our $$sc_iCal variables, and all the variables used for event field mapping. (This is great for general [[debugging]] as well.

-> If you don't have FileMaker Advanced, the script "Clear Source Variables" lists all the variables used here. In addition, the script "Load Source Settings at Startup..." loads a few variables about the table occurrence name of the selected source like $$sc_SourceTableOccurenceName.
April 16, 2012, at 08:37 AM by 78.86.121.102 -
Added lines 1-15:
!! A note on abstraction

As part of making the calendar portable, most scripts are "abstracted" so that they use the fields mapped on your "Source No X" layouts. This makes it easy for you to point the calendar at your own data tables without having to edit every field reference in every script.

However, once you have integrated the calendar into your own file, you don't really need to keep up the abstraction. For example, if you have a field called "Priority" in your events table and want to make sure that when you create a new event this field is always set to "1", you can just use a regular SetField script step... you don't need to use SetFieldByName as you no longer need the calendar to be portable.

(OK, you'd probably do this priority thing with an auto-enter calc, but you get the idea.)

That said, if you want to follow along and use variables, the following notes will help you keep track of what the variable names are.

!! What variables are available when editing events?

When working with a particular source in the calendar we load the facts of that source to global variables (those variables beginning $$). If you need to know the name of a particular variable, you have two options:

-> If you have FileMaker Advanced, run the script "Dev ON" and then refresh the calendar. This script stops us from clearing all the calendar variables in use, so you can see your SQL queries, our $$sc_iCal variables, and all the variables used for event field mapping.
(855) SEEDCODE
[email protected]
Follow us: