What Are Floating Events

Pimlical Android Help

What are Floating Events?

A floating event is a bit like a task and perhaps most easily explained with an example. Suppose you need to get your hair cut next week. You might put in an appointment on Tuesday, thinking you will likely be able to do it that day. But then you get busy and can't get to it. What you would really like is for that appointment to automatically roll over to the next day if you didn't get to it. A floating appointment does just that. If you created the item as a floating event, it would automatically float from day to day until you marked it as complete. When marked as complete, the appointment is then frozen on that day and does not get advanced any more. A checkmark appears in the circle to indicate that the floating event is complete.

Floating events can be put on any future date, but not a past date. The reason for this is that a floating event that has not been marked as complete must be displayed at the very earliest in today's schedule.

You can set a due date on a floating event - for example, you create a floating event to write a report which you want to start on Tuesday of next week and mark it as having a due date of Friday of that week. When displaying that event, Pimlical shows in brackets at the start of the description how many days out from today it is due (so if it was due in ten days, you would see [10] at the start of the description field.

Repeat Floating Events

Floating events can also be made to repeat and serve a very useful function for repetitive items that don't have to be completed on a specific day. For example, you might make that haircut appointment a repeat floating event that repeats every two months. That way, every two months, when the repeat floating event's next instance matches today's date, the repeat event itself is rescheduled two months in advance and a non-repeat floating instance is left in today's schedule. There is also an option to reschedule the repeat floating event from the checkoff date. Example, you don't get around to cutting your hair for three weeks, but don't want to be reminded about that haircut in 5 weeks, but rather 8 weeks from when you got your last haircut. By setting that option in the repeat dialog, the repeat floating event will get rescheduled from the date that you actually completed the task.

The non-repeat floating instance is also referred to as a Reminder because it includes an internal link (TargetUniqueID) to the original event from which it was spawned, and will display the Reminder Icon (an 'R' inisde the float-circle).

Automatic creation of Reminders for Events

If you set an Advance on a regular appointment (you cannot set an advance on a Floating event or Task), Pimlical will automatically create a floating event (referred to as a Reminder) with all the same attributes as the original event (except any repeat specification is ignored), the start date will be set to the date on which the float was created and an internal link (TargetUniqueID) is set to the original appointment that had the advance. If the event is a repeat event, the reminder will be created on the designated date of each instance of the repeat series.. There are preference settings and Action Tags that can modify reminders in a useful fashion (for example, making the reminder Untimed, even though the spawning event was timed (Preference: DefaultIsUntimedAdvances). If the appointment with the advance had an alarm set, you can also suppress alarms on the newly created Reminder (ActionTag: NoAlarmOnReminder).

Remember that Pimlical permits negative values for an advance, the same way that it permits negative values for alarms. If you set an advance of -10, a reminder will be created ten days AFTER the event (make sure you use the NP Action Tag to avoid unexpected removal). This can be useful for setting a followup reminder for an event.

Advancing of Floating Events

Floating events are advanced automatically (or created from a Reminder) by Pimlical at the start of each day, provided that the preference AdvanceFloatingEventsTime is set to a value other than midnight. The actual time set is not relevant - only whether it is set to midnight (which disables this function) or to some other time (which enables it).

Although advances may be created separately on separate platforms, there is no issue in syncing local calendars because the floating event that is created will always have the same, identical uniqueID (the uniqueID of the target is extended with either "_00000000" if the target is a non-repeat, or "_YYYYMMDD" if the target is a repeat event, where YYYYMMDD is the date of the instance for which the advance is being created).

If you are mixing local calendars and Android calendars it is recommended that you put your reminders in your local calendar where Pimlical has control over the uniqueID for the event. If you leave reminders in an Android calendar, Google will re-assign the uniqueID and you may end up with duplicates. You can also workaround that issue by only having a single platform actually perform the floating advance.

If you want to see the effect of advancing floats right away (for example, you just created a future item with a reminder and want to see the reminder in today's schedule), you can force it by going into Menu | Debug | Advance Floats.

Automatic purging and Maintenance for Floating Events

First, reminders (generated by an advance, or by a repeat, floating event) will by default be automatically purged when they finally "catch up" to their target event. You may see the reminder and the target event on that date, but it will be deleted during the Advance of Floating Events (default at 2am). If you don't like that behaviour, make sure the original event has the Action tag NP (No Purge) set, and the advance will be left alone.

If you delete an event for which a reminder has already been created, the reminder will also be automatically deleted. Again, if you don't like that behaviour, make sure the original event has the Action tag NP (No Purge) set, and the advance will be left alone.

When pimlical automatically deletes a reminder, the Audit Trail log file (if enabled by preference: MaintainAuditTrail) is updated with the deletion information.

Errors with Duplicate Reminders, Orphaned Reminders

Due to some odd end conditions (syncing/restoring/reimporting events), you may see a notice (especially if you run Menu | Debug | Check Unique IDs) about duplicate or orphaned reminders for an event. The duplicate event will always have the legend (DUPLICATE) appended to the description field. Normally you would just delete such an event, leaving the original intact.

You may also see a notice about an "orphaned" Reminder - this is a reminder for which the Target Event cannot be found or was deleted (and for some reason the reminder did not get auto-deleted). If the target event was deleted, the reminder is definitely an orphan, but if the event is just completely missing it is referred to as a Possible orphan because there are legitimate cases where the target event might not be found (example: the target event is in an Android calendar which is not currently being displayed, or a sync takes place which creates the orphaned reminder on a platform). If you set the preference MaintainAuditTrail to true, you can look at the Pimlical_{Platform}_AuditTrail.log file as the orphaned events will be identified in that file.

The Menu | Debug | Check Unique IDs routine will (with a subscription) offer to delete all orphaned reminders for which a deleted target event was found, but will not delete a Possible orphaned reminder.

Skipping over Days

There is an Action tag, FloatDays: which can be used to skip over certain days. The argument for this Action tag is a list of the days of the week, either as the names of the days, or, for backwards compatibility, digits which represent days of the week. See the description of the FloatDays Action tag for details on how to use this feature.

You can use this feature to automatically advance floating events only on the weekend days (example, you want a floating event which only appears on Saturday and Sunday when you are available to work on non-work related items).

How do Tasks differ from Floating Events

In most cases, tasks are indistinguishable from Floating Events, but there are some subtle differences that you should be aware of:

Popup commands that adjust the date of an item do not adjust the due date for floating events, but they do adjust the due date for tasks.
Repeats work slightly differently because by default, repeat tasks do not maintain an exceptions list, and only the next instance of the repeat is displayed (you can in fact modify this behavior with preferences to make tasks look more like floats).
By default, the Tasks View is only set to display tasks, but this is only because by default it invokes the Tasks_only filter. There is nothing to stop you as a user creating say a Floats_only Filter and then using that in menu | Tasks View (by setting the preference DefaultTasksViewFilter) to display floating events.
There are often separate preference items for floats and tasks so you can set different attributes for them - for example, the preference ForceTasksToBeUntimed allows you to force the display of all tasks at the top of the view, even if they are timed.

Also, the advance filtering feature has completely separate profiles for floating events versus tasks. By modifying the filters, you can accomplish things like (a) choosing to suppress all tasks in the main calendar views, and only viewing tasks in the Tasks View, or (b) setting up different priority/urgency profiles for Floats vs. Tasks, etc.