DayBackOnline

Your Own Event Layouts

DayBackOnline.YourOwnEventLayouts History

Hide minor edits - Show changes to output

July 03, 2015, at 08:25 PM by 142.4.217.187 -
Changed line 3 from:
While DayBack for FileMaker can [[DayBackForFileMaker.YourOwnEventLayouts | use a FileMaker layout]] instead of an event popover, you won't be able to do that in DayBack Online.
to:
While DayBack for FileMaker can [[DayBackForFileMaker.YourOwnEventLayouts | use a FileMaker layout]] instead of an event popover, you won't be able to do that in DayBack Online since the app is running inside your browser and has no access to render your layouts.
June 30, 2015, at 01:29 AM by 142.4.217.188 -
Changed lines 3-37 from:
You can configure DayBack to use your own layout instead of the popover. Alternately, you can preview your event in a webviewer popover and then jump to your own layout using a custom action when you need more detail.

This video describes how to set up both options. Setting up the "custom actions" described in the video is detailed here: [[Custom Actions]].

https://www.youtube.com/watch?v=nxi8abtlBn0

(:youtube nxi8abtlBn0 width=500:)

!! What if I already have layouts for my events table: do I have to use yours?

No. You can certainly use your own. Just reference your layout in any [[custom actions | custom action]] scripts that need to land on your layout (our example script, "Go To Event Record from Webviewer" uses our "Action - View Event" layout but can certainly use yours.

You'd also select your layout in the script "Load Source Settings at Startup --- Describe Your Sources Here ---" after the comment "Which layout should we use to display event details for this source?". Be sure to run the upon opening script after editing that Source Settings script.

!! What if the layout I want to use is in my own file?

That's actually pretty easy to handle. You'll still edit the script "Load Source Settings at Startup --- Describe Your Sources Here ---" to tell DayBack that you'd like to use a FileMaker layout for one of your sources (watch the movie above or edit that script after the comment "Should we show event details using a FileMaker layout? Boolean - True or False").

Then you'll edit the script "Show Event Details From WebViewer" adding the four lines shown below to call a script in ''your'' file, passing in the ID of the event you clicked on as the script parameter $eventID.

%center% %newwin width=440% [[https://www.seedcode.com/rootimages/stikipad/dayback/showevents.png | https://www.seedcode.com/rootimages/stikipad/dayback/showevents.png]]

Note that the lines shown above are shown in the "edit" branch of the "Show Event Details From WebViewer" script; you could add the same kind of branch to the "create" section right above it.

!! How do I show event changes immediately on the calendar?

If you choose to use your own layout rather than DayBack popovers you may want to manage when event changes show up on the calendar. This is ultimately handed by the script "Refresh Calendar Event (Data ; {EventID ; RenderID ; QueryID ; Operation ; ForceRefresh} )". This script takes event data and an event ID and updates the  event display on the calendar. This script should be run after the event window is closed so it is executed from the context of the calendar layout. For an example we use the script "Close Event Window & Refresh Calendar" on our "To Do Details" layout to update the event on closing the window. We recommend copying the "Close & Refresh Calendar" button off of that layout and using it on your layouts as it calls that script and is a great starting point.

!! Update the calendar view after deleting a filemaker record?

If you would like to update the calendar view when deleting a record the easiest way is to add a script step to the "On Event Record Load" script. This script is called on a layout script trigger "OnRecordLoad" and is run whenever an event record loads (this includes when an event is deleted) in our included event detail layouts. Simply add a Perform Script "Refresh Calendar" script step inside the if statement as shown in the image below.

%center% %newwin width=440%  [[https://www.seedcode.com/rootimages/stikipad/dayback/refresh-after-delete.png | https://www.seedcode.com/rootimages/stikipad/dayback/refresh-after-delete.png]]

We add the exit script step after we call the refresh script because the rest is unnecessary if we run that script first.
to:
While DayBack for FileMaker can [[DayBackForFileMaker.YourOwnEventLayouts | use a FileMaker layout]] instead of an event popover, you won't be able to do that in DayBack Online.

You can, however, create [[custom actions]] that open an event in FileMaker Pro, Go, or WebDirect depending on the kind of URL you enter. More here: [[Custom Actions]].
March 09, 2015, at 08:28 PM by 142.4.217.187 -
Added lines 6-7:

https://www.youtube.com/watch?v=nxi8abtlBn0
February 25, 2015, at 09:49 PM by 142.4.217.188 -
Changed line 33 from:
%center% %width=440% https://www.seedcode.com/rootimages/stikipad/dayback/refresh-after-delete.png
to:
%center% %newwin width=440%  [[https://www.seedcode.com/rootimages/stikipad/dayback/refresh-after-delete.png | https://www.seedcode.com/rootimages/stikipad/dayback/refresh-after-delete.png]]
February 25, 2015, at 09:48 PM by 142.4.217.188 -
Changed line 21 from:
%newwin% %width=440% [[https://www.seedcode.com/rootimages/stikipad/dayback/showevents.png | https://www.seedcode.com/rootimages/stikipad/dayback/showevents.png]]
to:
%center% %newwin width=440% [[https://www.seedcode.com/rootimages/stikipad/dayback/showevents.png | https://www.seedcode.com/rootimages/stikipad/dayback/showevents.png]]
February 25, 2015, at 09:46 PM by 142.4.217.188 -
Changed line 21 from:
%newwin% %center width=400px% [[https://www.seedcode.com/rootimages/stikipad/dayback/showevents.png | https://www.seedcode.com/rootimages/stikipad/dayback/showevents.png]]
to:
%newwin% %width=440% [[https://www.seedcode.com/rootimages/stikipad/dayback/showevents.png | https://www.seedcode.com/rootimages/stikipad/dayback/showevents.png]]
February 25, 2015, at 09:45 PM by 142.4.217.188 -
Changed line 21 from:
%newwin% %center width=400% [[https://www.seedcode.com/rootimages/stikipad/dayback/showevents.png | https://www.seedcode.com/rootimages/stikipad/dayback/showevents.png]]
to:
%newwin% %center width=400px% [[https://www.seedcode.com/rootimages/stikipad/dayback/showevents.png | https://www.seedcode.com/rootimages/stikipad/dayback/showevents.png]]
February 25, 2015, at 09:45 PM by 142.4.217.188 -
Added lines 14-23:

!! What if the layout I want to use is in my own file?

That's actually pretty easy to handle. You'll still edit the script "Load Source Settings at Startup --- Describe Your Sources Here ---" to tell DayBack that you'd like to use a FileMaker layout for one of your sources (watch the movie above or edit that script after the comment "Should we show event details using a FileMaker layout? Boolean - True or False").

Then you'll edit the script "Show Event Details From WebViewer" adding the four lines shown below to call a script in ''your'' file, passing in the ID of the event you clicked on as the script parameter $eventID.

%newwin% %center width=400% [[https://www.seedcode.com/rootimages/stikipad/dayback/showevents.png | https://www.seedcode.com/rootimages/stikipad/dayback/showevents.png]]

Note that the lines shown above are shown in the "edit" branch of the "Show Event Details From WebViewer" script; you could add the same kind of branch to the "create" section right above it.
February 24, 2015, at 11:32 PM by 142.4.217.187 -
Added lines 18-19:

!! Update the calendar view after deleting a filemaker record?
February 24, 2015, at 11:31 PM by 142.4.217.187 -
Changed line 19 from:
If you would like to update the calendar view when deleting a record the easiest way is to add a script step to the "On Event Record Load" script. This script is called on a layout script trigger "OnRecordLoad" and is run whenever an event record loads (this includes when an event is deleted) in our included event detail layouts. Simply add a Perform Script "Refresh Webviewer" script step inside the if statement as shown in the image below.
to:
If you would like to update the calendar view when deleting a record the easiest way is to add a script step to the "On Event Record Load" script. This script is called on a layout script trigger "OnRecordLoad" and is run whenever an event record loads (this includes when an event is deleted) in our included event detail layouts. Simply add a Perform Script "Refresh Calendar" script step inside the if statement as shown in the image below.
February 24, 2015, at 11:31 PM by 142.4.217.187 -
Changed lines 19-23 from:
If you would like to update the calendar view when deleting a record the easiest way is to add a script step to the "On Event Record Load" script. This script is called on a layout script trigger "OnRecordLoad" and is run whenever an event record loads (this includes when an event is deleted) in our included event detail layouts. Simply add a Perform Script "Refresh Webviewer" script step inside the if statement as shown in the image below.
to:
If you would like to update the calendar view when deleting a record the easiest way is to add a script step to the "On Event Record Load" script. This script is called on a layout script trigger "OnRecordLoad" and is run whenever an event record loads (this includes when an event is deleted) in our included event detail layouts. Simply add a Perform Script "Refresh Webviewer" script step inside the if statement as shown in the image below.

%center% %width=440% https://www.seedcode.com/rootimages/stikipad/dayback/refresh-after-delete.png

We add the exit script step after we call the refresh script because the rest is unnecessary if we run that script first
.
February 24, 2015, at 11:30 PM by 142.4.217.188 -
Changed lines 19-29 from:
To remove an event from the calendar view just pass a few parameter values into the script "Refresh Calendar Event (Data ; {EventID ; RenderID ; QueryID ; Operation ; ForceRefresh} )".

So an example of a parameter for that script might look like:

#
("sc_Data" ; "") &
#("sc_EventID" ; $sc_EventID
) &
#("sc_Operation" ; "delete")

I would suggest duplicating the "Close Event Window &
Refresh Calendar" script and adding a delete record before the close window script step for your delete button. Then changing the "Data" parameter when calling "Refresh Calendar Event (Data ; {EventID ; RenderID ; QueryID ; Operation ; ForceRefresh} )" to what is shown above. Then remove the "If" statement that wraps that script step as we don't need to check for record modification when deleting. These changes will change the script to delete the record, close the window, and then update the calendar view to reflect the deleted event.

Make sure to remove or change any on record load script triggers that might interfere with the script as that trigger will run when deleting a record
.
to:
If you would like to update the calendar view when deleting a record the easiest way is to add a script step to the "On Event Record Load" script. This script is called on a layout script trigger "OnRecordLoad" and is run whenever an event record loads (this includes when an event is deleted) in our included event detail layouts. Simply add a Perform Script "Refresh Webviewer" script step inside the if statement as shown in the image below.
February 24, 2015, at 10:31 PM by 142.4.217.188 -
Changed lines 17-19 from:
If you choose to use your own layout rather than DayBack popovers you may want to manage when event changes show up on the calendar. This is ultimately handed by the script "Refresh Calendar Event (Data ; {EventID ; QueryID ; ForceRefresh} )". This script takes event data and an event ID and updates the  event display on the calendar. This script should be run after the event window is closed so it is executed from the context of the calendar layout. For an example we use the script "Close Event Window & Refresh Calendar" on our "To Do Details" layout to update the event on closing the window. We recommend copying the "Close & Refresh Calendar" button off of that layout and using it on your layouts as it calls that script and is a great starting point.

To remove an event from the calendar view just pass a boolean false statement into the data
parameter for "Refresh Calendar Event (Data ; {EventID ; QueryID ; ForceRefresh} )". So that would be either False or 0. I would suggest duplicating the "Close Event Window & Refresh Calendar" script and adding a delete record before the close window script step for your delete button. Then changing the "Data" parameter when calling "Refresh Calendar Event (Data ; {EventID ; QueryID ; ForceRefresh} )" to a false value. Then remove the "If" statement that wraps that script step as we don't need to check for record modification when deleting. These changes will change the script to delete the record, close the window, and then update the calendar view to reflect the deleted event.
to:
If you choose to use your own layout rather than DayBack popovers you may want to manage when event changes show up on the calendar. This is ultimately handed by the script "Refresh Calendar Event (Data ; {EventID ; RenderID ; QueryID ; Operation ; ForceRefresh} )". This script takes event data and an event ID and updates the  event display on the calendar. This script should be run after the event window is closed so it is executed from the context of the calendar layout. For an example we use the script "Close Event Window & Refresh Calendar" on our "To Do Details" layout to update the event on closing the window. We recommend copying the "Close & Refresh Calendar" button off of that layout and using it on your layouts as it calls that script and is a great starting point.

To remove an event from the calendar view just pass a few
parameter values into the script "Refresh Calendar Event (Data ; {EventID ; RenderID ; QueryID ; Operation ; ForceRefresh} )".

So an example of a parameter for that script might look like:

#(
"sc_Data" ; "") &
#("sc_EventID" ; $sc_EventID) &
#("sc_Operation" ; "delete")

I would suggest duplicating the "Close Event Window & Refresh Calendar
" script and adding a delete record before the close window script step for your delete button. Then changing the "Data" parameter when calling "Refresh Calendar Event (Data ; {EventID ; RenderID ; QueryID ; Operation ; ForceRefresh} )" to what is shown above. Then remove the "If" statement that wraps that script step as we don't need to check for record modification when deleting. These changes will change the script to delete the record, close the window, and then update the calendar view to reflect the deleted event.
December 11, 2014, at 12:24 AM by 98.203.211.206 -
Changed lines 19-21 from:
To remove an event from the calendar view just pass a boolean false statement into the data parameter for "Refresh Calendar Event (Data ; {EventID ; QueryID ; ForceRefresh} )". So that would be either False or 0. I would suggest duplicating the "Close Event Window & Refresh Calendar" script and adding a delete record before the close window script step for your delete button. Then changing the "Data" parameter when calling "Refresh Calendar Event (Data ; {EventID ; QueryID ; ForceRefresh} )" to a false value. Then remove the "If" statement that wraps that script step as we don't need to check for record modification when deleting. These changes will change the script to delete the record, close the window, and then update the calendar view to reflect the deleted event.
to:
To remove an event from the calendar view just pass a boolean false statement into the data parameter for "Refresh Calendar Event (Data ; {EventID ; QueryID ; ForceRefresh} )". So that would be either False or 0. I would suggest duplicating the "Close Event Window & Refresh Calendar" script and adding a delete record before the close window script step for your delete button. Then changing the "Data" parameter when calling "Refresh Calendar Event (Data ; {EventID ; QueryID ; ForceRefresh} )" to a false value. Then remove the "If" statement that wraps that script step as we don't need to check for record modification when deleting. These changes will change the script to delete the record, close the window, and then update the calendar view to reflect the deleted event.

Make sure to remove or change any on record load script triggers that might interfere with the script as that trigger will run when deleting a record
.
December 11, 2014, at 12:19 AM by 98.203.211.206 -
Changed line 19 from:
To remove an event from the calendar view just pass a boolean false statement into the data parameter for "Refresh Calendar Event (Data ; {EventID ; QueryID ; ForceRefresh} )". So that would be either False or 0. I would suggest duplicating the "Close Event Window & Refresh Calendar" script and adding a delete record before the close window script step for your delete button. Then changing the "Data" parameter when calling "Refresh Calendar Event (Data ; {EventID ; QueryID ; ForceRefresh} )" to a false value. This edit would delete the record, close the window, and then update the calendar view to reflect the deleted event.
to:
To remove an event from the calendar view just pass a boolean false statement into the data parameter for "Refresh Calendar Event (Data ; {EventID ; QueryID ; ForceRefresh} )". So that would be either False or 0. I would suggest duplicating the "Close Event Window & Refresh Calendar" script and adding a delete record before the close window script step for your delete button. Then changing the "Data" parameter when calling "Refresh Calendar Event (Data ; {EventID ; QueryID ; ForceRefresh} )" to a false value. Then remove the "If" statement that wraps that script step as we don't need to check for record modification when deleting. These changes will change the script to delete the record, close the window, and then update the calendar view to reflect the deleted event.
December 11, 2014, at 12:00 AM by 98.203.211.206 -
Changed lines 15-17 from:
If you choose to use your own layout rather than DayBack popovers you may want to manage when event changes show up on the calendar. There is a script called "Refresh Calendar Event (Data ; {EventID ; QueryID ; ForceRefresh} )". This script takes event data and an event ID and updates the  event display on the calendar. This script should be run after the event window is closed. For an example we use the script "Close Event Window & Refresh Calendar" on our ToDo Detail layout to update the event on closing the window. We recommend copying the close button off of that layout and using it on your layouts.

To remove an
event from the calendar view just pass a boolean false statement into the data parameter for "Refresh Calendar Event (Data ; {EventID ; QueryID ; ForceRefresh} )". So that would be either False or 0. I would suggest duplicating the "Close Event Window & Refresh Calendar" script and adding a delete record before the close window script step for your delete button.
to:
!! How do I show event changes immediately on the calendar?

If
you choose to use your own layout rather than DayBack popovers you may want to manage when event changes show up on the calendar. This is ultimately handed by the script "Refresh Calendar Event (Data ; {EventID ; QueryID ; ForceRefresh} )". This script takes event data and an event ID and updates the  event display on the calendar. This script should be run after the event window is closed so it is executed from the context of the calendar layout. For an example we use the script "Close Event Window & Refresh Calendar" on our "To Do Details" layout to update the event on closing the window. We recommend copying the "Close & Refresh Calendar" button off of that layout and using it on your layouts as it calls that script and is a great starting point.

To remove an event from
the calendar view just pass a boolean false statement into the data parameter for "Refresh Calendar Event (Data ; {EventID ; QueryID ; ForceRefresh} )". So that would be either False or 0. I would suggest duplicating the "Close Event Window & Refresh Calendar" script and adding a delete record before the close window script step for your delete button. Then changing the "Data" parameter when calling "Refresh Calendar Event (Data ; {EventID ; QueryID ; ForceRefresh} )" to a false value. This edit would delete the record, close the window, and then update the calendar view to reflect the deleted event.
December 10, 2014, at 11:46 PM by 98.203.211.206 -
Changed lines 13-17 from:
You'd also select your layout in the script "Load Source Settings at Startup --- Describe Your Sources Here ---" after the comment "Which layout should we use to display event details for this source?". Be sure to run the upon opening script after editing that Source Settings script.
to:
You'd also select your layout in the script "Load Source Settings at Startup --- Describe Your Sources Here ---" after the comment "Which layout should we use to display event details for this source?". Be sure to run the upon opening script after editing that Source Settings script.

If you choose to use your own layout rather than DayBack popovers you may want to manage when event changes show up on the calendar. There is a script called "Refresh Calendar Event (Data ; {EventID ; QueryID ; ForceRefresh} )". This script takes event data and an event ID and updates the  event display on the calendar. This script should be run after the event window is closed. For an example we use the script "Close Event Window & Refresh Calendar" on our ToDo Detail layout to update the event on closing the window. We recommend copying the close button off of that layout and using it on your layouts.

To remove an event from the calendar view just pass a boolean false statement into the data parameter for "Refresh Calendar Event (Data ; {EventID ; QueryID ; ForceRefresh} )". So that would be either False or 0. I would suggest duplicating the "Close Event Window & Refresh Calendar" script and adding a delete record before the close window script step for your delete button.
Changed line 11 from:
No. You can certainly use your own. Just reference your layout in any [[custom action]] scripts that need to land on your layout (our example script, "Go To Event Record from Webviewer" uses our "Action - View Event" layout but can certainly use yours.
to:
No. You can certainly use your own. Just reference your layout in any [[custom actions | custom action]] scripts that need to land on your layout (our example script, "Go To Event Record from Webviewer" uses our "Action - View Event" layout but can certainly use yours.
Changed lines 11-27 from:
No. You can certainly use your own. There are just a few things to keep in mind.

'''Event List'''

-> There are a few script steps that reference this layout (such as when you wish to see repeating events as a list) so rename
''your'' event list layout to "Event List" before importing the scripts in your [[integration]]. After the scripts are in you can rename your layout back to whatever you'd named it before.

'''Event Details'''

-> The event details layout is
the one we go to when clicking on an event in the calendar and when making a new one from within the calendar. Thus a lot more scripts point to this layout.

->This is a mini window (a small window) so you can still see calendar events behind it while you're editing the event: we also kept it small because we bring up several of these small windows when you click on a conflicting event.

-> So, you may want to keep our Event Details layout even if you already have one, since it can be convenient to have a small, quick reference version of the event. What many people do is add a button to our Event Details layout (which is fully customizable, by the way) which jumps to their larger Event Details layout...

!! Making New Records

In order for you to arrive at your own layout when you ''create'' an event on the calendar, edit the script "Create Edit Delete Event ( SourceNo ) { Operation , Hide, DateStart , DateEnd , TimeStart ... }" and find the comment "--------- Create -------". A few steps after that you'll see a go to layout command: change that to your layout and you'll be all set.
to:
No. You can certainly use your own. Just reference your layout in any [[custom action]] scripts that need to land on your layout (our example script, "Go To Event Record from Webviewer" uses our "Action - View Event" layout but can certainly use yours.

You
'd also select your layout in the script "Load Source Settings at Startup --- Describe Your Sources Here ---" after the comment "Which layout should we use to display event details for this source?". Be sure to run the upon opening script after editing that Source Settings script.
Deleted lines 23-28:

!! Can I jump right from the Event Details layout to my own event layout?

Yes, we've built a script for this already. Simply add a new button to the Event Details layout and call the script "Jump to Event in My Layout ( EventID )" using your Event ID as the script parameter (just send the ID itself, not "EventID..." ).  Then edit this script to use ''your'' event ID field and the layout of your choice to display event details.

This is very similar to the script we use to [[JumpToMyContact | jump to your contact's layout]].
Changed lines 1-2 from:
%color=red% >> How to use your own event layouts a) instead of a popover, b) as a supplement to a popover with Custom Actions.
to:
!! Using Your Own Layouts Instead of Webview Popovers

You can configure DayBack to use your own layout instead of the
popover. Alternately, you can preview your event in a webviewer popover and then jump to your own layout using a custom action when you need more detail.

This video describes how to set up both options. Setting up the "custom actions" described in the video is detailed here: [[Custom Actions]].

(:youtube nxi8abtlBn0 width=500:)
Added lines 1-3:
%color=red% >> How to use your own event layouts a) instead of a popover, b) as a supplement to a popover with Custom Actions.

July 21, 2010, at 10:08 PM by 76.22.123.157 -
Changed lines 23-24 from:
'''Making New Records'''
to:
!! Making New Records
July 21, 2010, at 10:08 PM by 76.22.123.157 -
Added lines 22-25:

'''Making New Records'''

In order for you to arrive at your own layout when you ''create'' an event on the calendar, edit the script "Create Edit Delete Event ( SourceNo ) { Operation , Hide, DateStart , DateEnd , TimeStart ... }" and find the comment "--------- Create -------". A few steps after that you'll see a go to layout command: change that to your layout and you'll be all set.
December 31, 2009, at 06:52 AM by 76.22.123.157 -
Changed lines 19-21 from:
Yes, we've built a script for this already. Simply add a new button to the Event Details layout and call the script "Jump to Event in My Layout ( EventID )" using your Event ID as the script parameter (just send the ID itself, not "EventID..." ).  Then edit this script to use ''your'' event ID field and the layout of your choice to display event details.
to:
Yes, we've built a script for this already. Simply add a new button to the Event Details layout and call the script "Jump to Event in My Layout ( EventID )" using your Event ID as the script parameter (just send the ID itself, not "EventID..." ).  Then edit this script to use ''your'' event ID field and the layout of your choice to display event details.

This is very similar to the script we use to [[JumpToMyContact | jump to your contact's layout]]
.
December 29, 2009, at 07:42 PM by 76.22.123.157 -
Changed lines 12-13 from:
This is a mini window (a small window) so you can still see calendar events behind it while you're editing the event: we also kept it small because we bring up several of these small windows when you click on a conflicting event.
to:

->
This is a mini window (a small window) so you can still see calendar events behind it while you're editing the event: we also kept it small because we bring up several of these small windows when you click on a conflicting event.
December 29, 2009, at 07:42 PM by 76.22.123.157 -
Changed lines 7-8 from:
There are a few script steps that reference this layout (such as when you wish to see repeating events as a list) so rename ''your'' event list layout to "Event List" before importing the scripts in your [[integration]]. After the scripts are in you can rename your layout back to whatever you'd named it before.
to:
-> There are a few script steps that reference this layout (such as when you wish to see repeating events as a list) so rename ''your'' event list layout to "Event List" before importing the scripts in your [[integration]]. After the scripts are in you can rename your layout back to whatever you'd named it before.
Changed lines 11-14 from:
The event details layout is the one we go to when clicking on an event in the calendar and when making a new one from within the calendar. This is a mini window (a small window) so you can still see calendar events behind it while you're editing the event: we also kept it small because we bring up several of these small windows when you click on a conflicting event.

So,
you may want to keep our Event Details layout even if you already have one, since it can be convenient to have a small, quick reference version of the event. What many people do is add a button to our Event Details layout (which is fully customizable, by the way) which jumps to their larger Event Details layout...
to:
-> The event details layout is the one we go to when clicking on an event in the calendar and when making a new one from within the calendar. Thus a lot more scripts point to this layout.
This is a mini window (a small window) so
you can still see calendar events behind it while you're editing the event: we also kept it small because we bring up several of these small windows when you click on a conflicting event.

->
So, you may want to keep our Event Details layout even if you already have one, since it can be convenient to have a small, quick reference version of the event. What many people do is add a button to our Event Details layout (which is fully customizable, by the way) which jumps to their larger Event Details layout...
December 29, 2009, at 07:40 PM by 76.22.123.157 -
Changed lines 7-8 from:
There are a few script steps that reference this layout (such as when you wish to see repeating events as a list) so rename ''your'' event list layout to "Event List"
to:
There are a few script steps that reference this layout (such as when you wish to see repeating events as a list) so rename ''your'' event list layout to "Event List" before importing the scripts in your [[integration]]. After the scripts are in you can rename your layout back to whatever you'd named it before.
Changed lines 11-17 from:
fgasga
to:
The event details layout is the one we go to when clicking on an event in the calendar and when making a new one from within the calendar. This is a mini window (a small window) so you can still see calendar events behind it while you're editing the event: we also kept it small because we bring up several of these small windows when you click on a conflicting event.

So, you may want to keep our Event Details layout even if you already have one, since it can be convenient to have a small, quick reference version of the event. What many people do is add a button to our Event Details layout (which is fully customizable, by the way) which jumps to their larger Event Details layout...

!! Can I jump right from the Event Details layout to my own event layout?

Yes, we've built a script for this already. Simply add a new button to the Event Details layout and call the script "Jump to Event in My Layout ( EventID )" using your Event ID as the script parameter (just send the ID itself, not "EventID..." ).  Then edit this script to use ''your'' event ID field and the layout of your choice to display event details.
December 29, 2009, at 07:27 PM by 76.22.123.157 -
Added lines 1-11:
!! What if I already have layouts for my events table: do I have to use yours?

No. You can certainly use your own. There are just a few things to keep in mind.

'''Event List'''

There are a few script steps that reference this layout (such as when you wish to see repeating events as a list) so rename ''your'' event list layout to "Event List"

'''Event Details'''

fgasga
(855) SEEDCODE
[email protected]
Follow us: