[Oberon] Re. Message system fault

[easlab at absamail.co.za]

Sometimes by making more effort to describe the problem to an
outsider, we gain extra insight, or even the solution, ourselves ?

Dan Parnete wrote:
>     On 10.05.06 I have posted a message about "Message queue and 
> Pointer". I talked about a big amount of messages on the queue (due to 
> the number of components moved in the display space) that caused the 
> Pointer events to be wrong interpreted.
> 
>     This time I will expose a similar wrong PointerDown event 
> interpretation of a scrollbar, due to the time spent to render images on 
> a tabular form.

Yes, it is natural that subtle bugs don't get fixed provided users can
work-around or avoid them.  But it's more economical to muster the
critical-mass to fix them early than allow them to linger like the 
N-O ppp problem.

>    To observe this you need to download the BBwClient from 
> ftp://194.243.0.14 and install it. At the login window, first press 
> ctrl-o to open the Kernel Log, then write:
> 

What is a "pointer" in the context of a message queue ?

It's easy to forget that this mail-list has forked to cater for several
[hopefully still related] systems.  My N-O & Linux-oberon don't 
react to ctrl-o, but it is possible to display the Kernel Log.

>    Application: 85.18.123.96/Dan
>    Database: DanDb
>    User: public
>    Password: user
> At the first time a modules upgrade will be done, and then exits. You 
> have to reenter. Then go to Clienti in the menu bar and select the first 
> record in the record's list (Ala Data System srl). The interested form 
> is the bottom one. The first two records have an image attached, and we 
> will use the vertical scrollbar for the demonstration. If you click on 
> the arrowDown button, if you are speed enough, you will obtain the 
> desired effect: one row scroll down. 

Yes, I remember these 'time/speed related effects' while trying to
debug N-O/ppp. OTOH serial-lockup re. ppp has many reports on the 
net, dating back to 1989.

Can you produce 'the fault' by other than your software ?

> If not, if the mouse will transmit  
> two (or more) repeated clicks, an unpredictable number of scroll down 
> will be done (see "ScrollbarChanged pos = x" in the Log), much more then 
> the real number of clicks transmitted. The first event will start an 
> image download from the server. During this time the arrowButton rest 
> pressed, even if you don't thatch anymore the mouse, and continue to 
> register PointerDown events. As soon as the records with image 
> disappear, the arrowButton is released.
> More interesting is the consequence if you press the arrowUp button to 
> scroll up. Due to the continuous downloading, the scrolling could 
> continue for a while.
> 
I'm reminded of the unsolved ppp > dial > ser-port > V24 which also
potentially relates to a [serial] mouse. Or are you using eg a usb-mouse.
My theory is that many of these problems are never solved.
The industry just finds work-arounds, and bluffs themselves that they
understood it and solved it.

> Observations:
> 1. Independent of the reason, the message system has a fault. It is not 
> admissible to register on the queue more Pointer events then those 
> driven by the user.
> 2. To limit the scrolling erroneous effects, the scrollbar must:
>     - call DecPos only if pos > 0
>     - call IncPos only if pos < max
> Applying this restrictions I have eliminated the undesired effect on the 
> WeelMove.

Perhaps if you 'translate' your report to more general/abstract
[independant of your application] terms it would better advance 
the problem towards a solution ?


== Chris Glur.