[Oberon] Re. Message system fault
easlab at absamail.co.za
easlab at absamail.co.za
Tue Jul 18 03:46:03 CEST 2006
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://22.214.171.124 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: 126.96.36.199/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.
> 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
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.
More information about the Oberon