Director's Calendar - weird bug

[Harriet Bazley]

Yesterday (i.e. before midnight on Monday) the !Calendar app inside
Director was telling me that it was Sun 1st August. Now it has rolled
over to correct itself to Tuesday 2nd August... while I was in the
middle of trying to debug it, so we shall never know what was going on!

--
Harriet Bazley == Loyaulte me lie ==

Profanity is the one language all programmers know best.

[Harriet Bazley]

On 2 Aug 2022 as I do recall,

Harriet Bazley wrote:

> Yesterday (i.e. before midnight on Monday) the !Calendar app inside
> Director

!Director.Apps.!Calendar

> was telling me that it was Sun 1st August. Now it has rolled over to
> correct itself to Tuesday 2nd August... while I was in the middle of
> trying to debug it, so we shall never know what was going on!
>

There is definitely a bug in this app affecting *every* first day of the
month, which will always get displayed in the wrong column, as can be
demonstrated by forcibly setting the value of TIME$ just before it gets
checked. Put it back to 1st August, or 1st June, or 1st July, and they
all go wrong in the same manner.

It is too late at night and I can't get my head around why exactly the
program is doing what it is doing: the calculation is
(VAL(MID$(TIME$,5,2))+16+calday%) when calculating the icon handle to
highlight in red for 'today', where the icon numbers start at 18 for the
first Sunday in a month, and where calday% starts off as the index into
an array of day names where Sunday is 1, and is then cycled downwards
according to the date value to form an arbitrary offset pointer:

FOR n=VAL(MID$(TIME$,5,2)) TO 2 STEP -1
PROCcalday_change(-1)
NEXT n

DEF PROCcalday_change(nd)
calday%=calday%+nd
IF calday%<1 calday%=7
IF calday%>7 calday%=1
ENDPROC

I would *assume* that the problem is that PROCcalday_change gets called
the same number of times whether VAL(MID$(TIME$,5,2)) is 01 or 02, since
the FOR loop isn't being allowed to go below 2, but I don't see why that
causes the value of calday% to (apparently) be one integer smaller than
it ought to be if TIME$ contains 01.

The routine that is printing the numbers from 1 to (no_of_days_in_month)
puts day 1 in the wrong column when the value of calday% is wrong, too:

FOR n=1 TO monthd(calmonth%)
PROCset_icon_string(calendar%,(16+calday%+n),STR$(n))
NEXT n


But if I experimentally alter the FOR loop to go to 1 STEP -1 that makes
everything go haywire, so there is clearly a good reason for this odd
constraint!

--
Harriet Bazley == Loyaulte me lie ==

The attacker must vanquish; the defender need only survive.

[Martin]

In article <483b6a115...@bazleyfamily.co.uk>,
Harriet Bazley <har...@bazleyfamily.co.uk> wrote:

[Snip]

Cross-posted to csa.programmer ... where I have replied.

--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.