DayValue Marker Tokens are optional day tokens used to unambiguously specify which DayValues fall on which pages of a GridTemplate.

 

To specify that a page contains the DayValue X, simply place the token [X*] anywhere on that page.

 

•On pages which contain no DayValue marker tokens, the presence of [d] or [dd] tokens is used to guess which DayValues belong to which pages.

•You do not need to add DayValue marker tokens for every day of the pages; simply place one for the minimum DayValue and one for the maximum DayValue (as is done in example1, below).

•You do not need to set DayValue Marker tokens for every page; only for pages where the DayValues contained could be ambiguous.

 

DayValue Marker Tokens never appear in the output file, and they are ignored after scanning, although the textbox that contains them is not deleted.

 

Example 1: there are no [d] or [dd] tokens on a page

 

Example 1, on the right, is a weekly where all the tokens are on the left page, the right page being a page of notes which does not contain any [d] or [dd] tokens.

 

Since Q++Studio uses the presence of either of the [d] or [dd] tokens, when scanning, to guess which DayValues fall on which pages, at run-time the starting date for that page will be undefined. A symptom of this is the appearance of the label "no dates on this page" on some of the script preview pages.

 

This will potentially cause the following problems:

 

•As the left page seems to contain a full week, DayValues 1 to 7, the generation of the grid of example 1, for a number of full weeks, might stop on the left page, instead of displaying both pages, unless the do not split grid option is used.

•If you try to insert another grid into the grid of example 1, then that inserted grid might not appear, depending on the value of the insert first page property, as DayValues 1 to 7 are seen on the left page, but having used the do not split grid option to avoid the preceding problem, no insertion attempt is made until the second page, which does not contain any of the desired insertion dates.

 

To avoid this problem, in example 1, we placed both a [1*] and a [7*] marker tokens, on the right page, so that the right page is seen as containing all the dates from DayValue 1 to 7, meaning that any insertion date in that week will be seen as belonging to that right page (as well as to the left page.

 

Example 2: there are [d] tokens of DayValue not corresponding to the page dates

 

Example 2, on the right, is a 7 days on 6 pages grid, where page 1 contains an overview (Übersicht, in German) of the coming week, and the following pages 2-3-4-5 contains DayValues 1-2-3-4-5, respectively, with DayValues 6 and 7 grouped on page 6 of the grid.

 

The problem, here, in contrast to example 1, is not a dearth of tokens [d] and [dd], but the presence of [2d] to [7d] tokens on page 1, leading the system to incorrectly guess that page 1 contains all the days of the week, when it fact it is just an overview page.

 

This will potentially cause the following problems, similar to those of example 1, though the causes are opposite:

 

•As page 1 seems to contain the full week, DayValues 1 to 7, the generation of the grid of example 2, for a number of full weeks, might stop on page 1, instead of all 6 pages.

•Similarly, if you try to insert another grid into the grid of example 2, then that inserted grid will most likely always be inserted before or after page 1, as DayValues 1 to 7 are seen to all be on page 1, regardless of the actual insertion date, which might be on any of the pages 2 to 6, instead.

 

To avoid this problem, in example 2, we placed a single [1*] marker token on page 1, so that DayValue 1 is seen as being located on pages 1 and 2, and the other DayValues on pages 2 to 6.

 

---

Topic 105056, last updated on 01-Aug-2020