In article <483b6a115a.harriet@bazleyfamily.co.uk>,
Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

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!

I hate bugs which hide.

It is much easier to debug if you add
time$ = TIME$
at the start, and replace all other TIME$ with time$.
Then you can set time$ to any value for debugging, without messing
with time itself.

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

That looks wrong - it certainly introduces an anomaly when it is the
1st, as calday% is set to the same number as for 2nd.

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,

Agreed!

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.

Agreed again.

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

That is because calday% is wrong.

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!

I think it should be 1 STEP -1, as that corrects calday%.
Then the two calls to PROCset_icon_colour should be changed from +16
to +17 which corrects the colours.
I think!

It would be much easier to use Territory_ConvertTimeToOrdinals !!

Martin

--
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)

On 2 Aug 2022 as I do recall,
Martin wrote:

In article <483b6a115a.harriet@bazleyfamily.co.uk>,
Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

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!

I hate bugs which hide.

It is much easier to debug if you add
time$ = TIME$
at the start, and replace all other TIME$ with time$.
Then you can set time$ to any value for debugging, without messing
with time itself.

That's a much better idea - I had to quit all my Internet stuff to avoid problems with messed-up dates and Messenger expiring things every time I changed TIME$....

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.

I'm also more than a little surprised that no-one has ever run into this particular bug since 1992, when the Calendar app was written!

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:

I think this is probably an exemplar of why it is a Bad Idea to reuse
your variables for other purposes (which I do myself all the time) - it
becomes extremely confusing as to what function the variable is actually performing at any given point in the program.

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

That looks wrong - it certainly introduces an anomaly when it is the
1st, as calday% is set to the same number as for 2nd.

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,

Agreed!

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.

Agreed again.

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

That is because calday% is wrong.

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!

I think it should be 1 STEP -1, as that corrects calday%.
Then the two calls to PROCset_icon_colour should be changed from +16
to +17 which corrects the colours.
I think!

Hmmm. That seems to correct the 1st August problem, but reliably
crashes with an abort on data transfer if I attempt to display August
2021 or May 2022 - presumably because a bad icon number is being passed
to FNstring_addr(window, icon%)

DEF FNstring_addr(window%,icon%)
REM returns address of icon's indirected text string
LOCAL c%
c%=b%+500
!c%=window%
c%!4=icon%
SYS "Wimp_GetIconState",,c%
=c%!28

Edit: yes, it crashes if icon% reaches 55, at which point c%!28 becomes
a rubbish value.
And icon% reaches 55 on months that start on a Sunday... although it
does *not* crash on November 2020. It just displays a completely blank
line for the first week, and starts on the following Sunday. Why?!!!

It would be much easier to use Territory_ConvertTimeToOrdinals !!

I'm not sure it would help that much for the icon position/number
calculation, which is where the program is falling over (and which is
the part where I frankly haven't got my head around the logic).

--
Harriet Bazley == Loyaulte me lie ==

If it's not broken, don't fix it.

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

In article <483b6a115a.harriet@bazleyfamily.co.uk>,
Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

To me, the code doesn't look extremely efficient. For example, the redraw routine will never be called, as the window consists of icons only.

Anyhow, it seems that this small change may work, as far as I've tested it (admittedly, not very far):

date% = VAL(MID$(time$,5,2))
IF date% > 1 THEN
FOR n=date% TO 2 STEP -1
PROCcalday_change(-1)
NEXT n
ENDIF

Paul

--
https://riscos.sprie.nl

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

On 2 Aug 2022 as I do recall,
Paul Sprangers wrote:

To me, the code doesn't look extremely efficient. For example, the redraw routine will never be called, as the window consists of icons only.

There was at some stage in the past a ghostly PROCdraw, to which I have
removed the REMmed out call since the procedure doesn't actually exist
in the program any more....

Anyhow, it seems that this small change may work, as far as I've tested it (admittedly, not very far):

date% = VAL(MID$(time$,5,2))
IF date% > 1 THEN
FOR n=date% TO 2 STEP -1
PROCcalday_change(-1)
NEXT n
ENDIF

I committed the cardinal sin of not saving a copy of the original before starting my tinkering about, but I *think* I managed to undo everything
before inserting this replacement, and it does seem to work, thanks - in
that it doesn't obviously crash, anyway, and doesn't generate months
with blank lines, although I didn't double-check to make sure that it
does put all the days in the correct columns.

It makes sense as a way of isolating the specific case that is causing
the problem, e.g. the date is 01 (as opposed to trying to work out the principle behind the algorithm used to position the dates and bug-fix
that from first principles!)

--
Harriet Bazley == Loyaulte me lie ==

Time is nature's way of making sure that everything doesn't happen at once.

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

In article <f702c4115a.harriet@bazleyfamily.co.uk>,
Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

I committed the cardinal sin of not saving a copy of the original before starting my tinkering about,

Haha, that sounds very familiar. F8 is a good friend, to some extend. But
even then I far too often managed to mangle source codes (especially my
own) beyond repair.

Paul

--
https://riscos.sprie.nl

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

In article <f702c4115a.harriet@bazleyfamily.co.uk>,
Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

On 2 Aug 2022 as I do recall,
Paul Sprangers wrote:

Anyhow, it seems that this small change may work, as far as I've
tested it (admittedly, not very far):

date% = VAL(MID$(time$,5,2))
IF date% > 1 THEN
FOR n=date% TO 2 STEP -1
PROCcalday_change(-1)
NEXT n
ENDIF

Having done a bit more tinkering, I would agree that Paul's suggestion
(and no other changes) fixes the bugs as reported, though I arrived a
a slightly different solution...

date% = VAL(MID$(time$,5,2)) :REM from today's date down to 1st
WHILE date% > 1
PROCcalday_change(-1) :REM subtract 1 from calday%
date% -= 1
ENDWHILE

I also noticed that while the window was open, the processor was being
consumed by 60k+ Null Polls/sec ... easily solved by changing
SYS "Wimp_Poll",,b% TO r%
to
SYS "Wimp_Poll",1,b% TO r%

I would assign the arrays days$(), monthb$(), monthd$() and leapyrs()
by eg:
days$() = "","Sun","Mon","Tue","Wed","Thu","Fri","Sat"
rather than RESTORE & READ loops, but that is being picky!

Martin

--
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)

On 3 Aug 2022 as I do recall,
Martin wrote:


[snip]

I also noticed that while the window was open, the processor was being consumed by 60k+ Null Polls/sec ... easily solved by changing
SYS "Wimp_Poll",,b% TO r%
to
SYS "Wimp_Poll",1,b% TO r%

Worth doing. I just wish we could get these improvements back into the original distribution!

I would assign the arrays days$(), monthb$(), monthd$() and leapyrs()
by eg:
days$() = "","Sun","Mon","Tue","Wed","Thu","Fri","Sat"
rather than RESTORE & READ loops, but that is being picky!

I suspect that would have required a newer version of BASIC than
available when the program was written.

(I didn't know you could do that....)

--
Harriet Bazley == Loyaulte me lie ==

Power tends to corrupt and absolute power corrupts absolutely

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

In article <b9282f125a.harriet@bazleyfamily.co.uk>,
Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

On 3 Aug 2022 as I do recall,
Martin wrote:

[snip]

I also noticed that while the window was open, the processor was
being consumed by 60k+ Null Polls/sec ... easily solved by
changing

SYS "Wimp_Poll",,b% TO r%
to
SYS "Wimp_Poll",1,b% TO r%

Worth doing. I just wish we could get these improvements back
into the original distribution!

I fear any support has vanished a long time ago :-((

I would assign the arrays days$(), monthb$(), monthd$() and
leapyrs() by eg:
days$() = "","Sun","Mon","Tue","Wed","Thu","Fri","Sat"
rather than RESTORE & READ loops, but that is being picky!

I suspect that would have required a newer version of BASIC than
available when the program was written.
(I didn't know you could do that....)

Nope - it is in my BASIC guide dated 1988!

--
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)

In article <b9282f125a.harriet@bazleyfamily.co.uk>,
Harriet Bazley <harriet@bazleyfamily.co.uk>

days$() = "","Sun","Mon","Tue","Wed","Thu","Fri","Sat"

(I didn't know you could do that....)

(I didn't know that either...)

Paul

--
https://riscos.sprie.nl

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

On 3 Aug 2022 as I do recall,
Martin wrote:

In article <b9282f125a.harriet@bazleyfamily.co.uk>,
Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

On 3 Aug 2022 as I do recall,
Martin wrote:

I also noticed that while the window was open, the processor was
being consumed by 60k+ Null Polls/sec ... easily solved by
changing

SYS "Wimp_Poll",,b% TO r%
to
SYS "Wimp_Poll",1,b% TO r%

Worth doing. I just wish we could get these improvements back
into the original distribution!

I fear any support has vanished a long time ago :-((

At some point since 2015, apparently....

--
Harriet Bazley == Loyaulte me lie ==

It is impossible to enjoy idling thoroughly unless one has plenty of work to do

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