Expected DayValues

Navigation:  GridTemplates > Scanned Templates > The Templates Explorer > Template Properties >

Expected DayValues

Previous pageReturn to chapter overviewNext page

When you scan a GridTemplate, Q++Studio tries to guess the dates contained in each page of your grid. Q++Studio guesses that a DayValue occurs on a given page, if it finds either a [d] or [dd] token of a given DayValue on that page. To override that guess, use DayValue Marker tokens.

 

The expected DayValues for daily and weekly grids are relatively intuitive. The expected DayValues for monthly grids depends on whether it is continuous, backtrack every month or backtrack every page. No attempt is made to verify DayValues found in grid whose structure was set to yearly.

 

If Q++Studio thinks it has found an inconsistency between the DayValues it expects and the DayValues found in the scanned GridTemplate, it will generate the design-time message DayValue of aNumber on page of name.qxp.

 

Daily

 

For daily GridTemplates, Q++Studio expects to find DayValues in the range of 1 to N, where N is the number of days in the Grid. A token [8d] found in a in a "7 days on 6 pages" grid would therefore trigger a warning message. However Q++Studio does not go into details of how DayValues are spread across the pages of a daily grid. A token of [6d] on page 2 of the above grid, although unlikely, would not trigger a message.

 

Weekly

 

For weekly GridTemplates, Q++Studio expects to find DayValues in the range of 1 to 7*N, where N is the number of weeks in the grid. A token [15d] found in a in a "2 weeks on 2 pages" grid would therefore trigger a warning message. However, as in the above daily case, Q++Studio does not go into details of how DayValues are spread across the pages of a weekly grid. A token of [14d] on page 1 of the above grid, although unlikely, would not trigger this message.

 

Monthly

 

Continuous

 

The verification, of DayValues for monthly continuous grids, is prudent.

 

A message will only be triggered if a DayValue occurs that is larger than 42 times the total number of months in the grid. A token [169d] would therefore trigger a message in a "4 months on 2 pages" grid. However, a token of [84d] on page 1 of the same grid will not trigger this message, even though, in the case of a continuous monthly, the DayValue of 84 on that first page is not only unlikely, but unheard of.

 

Backtrack every month

 

In a grid of this structure, each month "lives" in a block of 42 possible DayValues (month 1 is from 1-42, month 2 from 43-84, etc…).

 

If the grid is not splittable, Q++Studio simply verifies that none of the DayValues exceeds the maximum expected DayValue (42 times the total number of months in the grid).

 

If the grid is splittable, Q++Studio will verify that DayValues fall within blocks of 42 per month, and that these block are evenly spread across the grid's pages. For example, in a "4 months on 2 pages" grid, Q++Studio would expect to find DayValues in the range 1-84 on page 1, and in the range 85-168 on page 2.

 

The messages issued are only warnings to allow for the fact that someone may always create a complex enough grid which breaks the expected DayValues rules.

 

Backtrack every page

 

In a grid of this structure, each page acts as a continuous grid, but the "clocks are reset" at the beginning of each new page, using a DayValue of 42 times the number of months contained in the preceding pages.

 

So we know that the minimum DayValue on each page should be :

 

 (42 * (PageNumber – 1) * MonthsPerPage) + 1

 

For example in a "4 months on 2 pages" the MonthsPerPage is 2, and so the minimum DayValue on page 1 is 1, and on page 2 is 85.

 

The maximum DayValue is harder to figure out since, within each page, the DayValues follow a continuous pattern.

 

Clearly the maximum DayValue must be, at most, 42 times the number of months per page times the number of pages (which is exactly 1 less than the minimum DayValue of the following page).

 

But this overestimates the maximum DayValue, particularly for grids with many months per page. For example, if you work it out with pencil and paper, you will see that you need at most 28 weeks to contain 6 full months. This works out to a maximum DayValue of 196, which is far less than 252 (6 times 42).

 

To estimate the maximum DayValue allowed for a Monthly Bactrack Every Page grid, use the minimum and maximum number of weeks needed to cover a given number of months table found in the appendices.

 

Yearly

 

In a grid of this structure, the cases in which a Template's structure is set to yearly, usually involve a grid with only one DayValue per page, in the case of a title page, or simply 12 (or even 24 or 26) MiniCalendars to display a year or more in MiniCalendars, and because there is only one DayValue of 1 per page, you need to override the initial guess, which is incorrect, as discussed here.


Topic 108443 updated on 08-Mar-2019.
Topic URL: https://www.qppstudio.net/webhelp_xv4/index.html?expecteddayvalues.htm