The following is a description of behavior I dont understand in Oberon/F
under Windows. I'm bringing this up not because the specific behavior I'll
describe bothers me, but because I'm hoping that discussing it might
clarify the concept of 'Focus' in Oberon/F.
(btw: the following is true of v1.2beta2 under Windows 3.11)
When there is a TextView embedded within another TextView and the 'child'
view can be scrolled in, pressing the 'control' key while the view is in
focus, changes the ScrollBar to reflect my position in the 'child' TextView
rather than the 'parent' view.
So far this is normal and documented behavior (again, under Windows).
Now, make sure the focus in the window the parent and
child views are in is on the 'child' view and then select (ie:move the focus)
any other window. What I dont understand is why when now
pressing the 'control' key the scrollbar position in the window which contains
the embedded view changes. I dont understand is why the 'child' view is
receiving a message of the pressing of the control key at all.
>From the documentation (which I quote below) I understand that the
framework maintains (ie: 'knows about') a focus window, not a focus view,
and that keyboard input etc... is sent to the root view of that window.
Why then are messages about keyboard activity being sent to a non-focus window.
The views in the different windows are unrelated (as far as I know) with
regards to 'message-broadcast-domain'.
Can anyone explain what I am misunderstanding?
-- Just after I wrote all this I noticed to my surprise that this behavior occurs even when when the focus is moved to a non-Oberon/F window.This might mean that the concept of "Focus" is actually platform dependent and that it is Windows itself that is sending the messages directly to the embedded Oberon/F Window.
This explanation makes sense to me, so I'm sending this out for whatever 'educational' value it has.
Regards, Guy.
Some relevant documentation sections:
In the documentation for Views it reads: "For every user interaction, e.g. the press of a key, a view must be defined which should handle this interaction, i.e. a so-called focus. Oberon doesn't know which view is the current focus. Oberon only provides a strategy which decides which window is focus. Since a window may contain a hierarchy of views, a view which has received an interaction message - a controller message - must decide on its own whether it is the focus itself, or whether it contains another view which might be focus instead. In the former case, it handles the messages itself, in the latter case, it forwards the message to this view."
In the views tutorial it reads: "The focus is where keyboard input is sent to, where the current selection or caret are displayed (if there are any such marks), and where upon some menu commands operate. ... Root views are always focused if the document window is focus."