• Director's Calendar - weird bug

    From Harriet Bazley@21:1/5 to All on Tue Aug 2 01:26:01 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Harriet Bazley@21:1/5 to Harriet Bazley on Tue Aug 2 02:25:13 2022
    XPost: comp.sys.acorn.programmer

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin@21:1/5 to All on Tue Aug 2 12:02:35 2022
    In article <[email protected]>,
    Harriet Bazley <[email protected]> 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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)