[Oberon] ETHO Display structure.

[Bob Walkden]

> From: eas lab [mailto:lab.eas at gmail.com]
[...]
> 
> IMO the Pet* author wrongly names the 'caret' the cursor.
> But I've notice mention of the "pointer" and the "marker".
> For THIS PROJECT, I've considered the <pointer which moves with the
> mouse> as the cursor.  What is the "pointer"?

The pointer is the mouse pointer. It is normally shaped like an arrow. You
use it to point at things. Calling it the pointer is probably more than a
coincidence.

The caret is the mark that indicates where the next typed character will be
inserted in the text. Oberon uses a caret symbol, which derives from
proof-reading. The proof-reader draws a little arrow where something is
missing and has to be inserted.

These things are all types of cursor. They are defined in Reiser's book.

[...]
> 
>         (* Returns the star (F1) marked frame. *)
>         PROCEDURE MarkedFrame (): Display.Frame; look interesting, and
> relevant to my task.

it probably isn't.

> 
> IMO the essentials of this problem is relating
>   mouseXYcursor <---> correspondingChar at Display/Frame/Viewer
> 
> But [in principle] I've got a problem with the different Types:
> Display, Viewers, TextFrames ....etc.
> 

You need to read the documentation. It is well written. It is written far
better than anything you're likely to get from us in a few emails.

> So if it's possible to GetMarkedObjType1, I don't know how to pass that
> to a PROC which does:
>  LocateCharAt(X,Y, ObjType2)
> 
> In OOP principles different Types of objects can 'relate'
> via inheritance.  But this seems not to help here.

That doesn't really mean anything.


> And just by luck AFAIR I found matching Types in TextFrames where Paul
> Reed pointed me to.
> 
> The goal is to be able to roam the cursor around the screen [or perhaps
> (now) only a Viewer] and instead of keying the mouse; key the keybrd -
> with the other hand.
> 

Oberon.Loop repeatedly reads the state of the mouse and sends a 'track'
message to the viewer(s) which cover the x,y coordinates of the mouse. Each
of those viewers has a handler which responds to the message and should
forward the message to the frame which includes the coordinates; the frame's
handler should respond.

In module TextFrames there is a procedure called LocateChar* (F: Frame; x,y:
INTEGER; VAR loc: Location ). In loc.pos it returns the position of the
character at (x,y) - the position within the text that the TextFrame is
responsible for: F.text. 

Now, one of the distinguishing features of Oberon texts is that many
different processes can read them simultaneously, so texts do not maintain
their own position - Readers do that. To get the character itself you need
to open a Reader on the text at the required position: Texts.OpenReader( R,
F.text, F.loc.pos )

Then read it: Texts.Read( R, ch ).

Alternatively you could track the mouse yourself and, if you can identify
which TextFrame (if any) contains the coordinates, you can call a couple of
procedures directly to read the character (if any) at that position.

Note that if you're going to track the mouse and the keyboard then you are
doing what the Oberon loop is designed to do. If you take over these
functions you could probably easily get into a mess, so you may be best
advised to write a supplementary handler for textframes, making sure to
preserve the old handler, call it from your handler, and restore it when
you're done.

[...]

B