Questions about Gadgets programming in Linux Native Oberon 2.3.7 
Author Message
 Questions about Gadgets programming in Linux Native Oberon 2.3.7

Hello

I am doing my Honours year project in Oberon, and have basically completed
it. I just have two questions that I would like to have clarified.

Firstly, I need to be able to check whether a view to a document already
exists before I attempt opening a new one. I only want one view of a
document at a time. This has to happen programmatically, ie. something like
        IF ~IsOpen("Sort.Mod") THEN Documents.Open("Sort.Mod")

Is there a way of checking, and if there is, how do you do it?

Secondly, I need to be able to determine the Display Frame a text is shown
in. I need this to be able to use Compiler.Locate programmatically (ie. no
user clicking), and the CaretMsg protocol requires a frame to send the
message to. If there is some way of getting around this part of the message,
that would also help.



Sun, 28 Mar 2004 20:11:29 GMT  
 Questions about Gadgets programming in Linux Native Oberon 2.3.7

Quote:

> Hello

> I am doing my Honours year project in Oberon, and have basically completed
> it. I just have two questions that I would like to have clarified.

Would you like also to share what you've accomplished?

Quote:
> Firstly, I need to be able to check whether a view to a document already
> exists before I attempt opening a new one. I only want one view of a
> document at a time. This has to happen programmatically, ie. something like
>         IF ~IsOpen("Sort.Mod") THEN Documents.Open("Sort.Mod")
> Is there a way of checking, and if there is, how do you do it?

I'm sorry but I think this isn't possible in a straight forward, clean way,
i.e. without messing around with addresses and without patching the system.

I thought about implementing an alternativ Texts.Open which would attach to
an already opened text if it existed. I would have used this as the standard
way in Edit.Open because I find it annoying after piling seven layers of
views in one track to open an old version of a document, changing it,
saving it and destroying this version after closing the viewers and getting
back to the modified but still not saved version of the very same document.

If you're willing to patch your system - let me know.

Quote:
> Secondly, I need to be able to determine the Display Frame a text is shown
> in. I need this to be able to use Compiler.Locate programmatically (ie. no
> user clicking), and the CaretMsg protocol requires a frame to send the
> message to. If there is some way of getting around this part of the message,
> that would also help.

Unfortunately, this is also impossible but there is *no way* to solve that
problem because there might simply no frame around. Texts.Text is a
selfcontained data structure which can be handled and manipulated perfectly
without any frame, and in fact is often dealt with "off screen". Moreover
there is a one to many relationship between texts and frames; the frames
are kept in sync with the state of the text model by the calls of the
notifier established in the text.

It could be however that there is a different approach to accomplish what
you want to do. To be able to help we need more information.
Basically a good idea is to include information about the host OS you are
using, which HW platform (is it StrongARM?) and which version of the ObSys
specifically.

--
moc dot slupofni at norebo - please revert the sequence

Carpe Diem!



Mon, 29 Mar 2004 00:37:49 GMT  
 Questions about Gadgets programming in Linux Native Oberon 2.3.7

Quote:
> Would you like also to share what you've accomplished?

Sure, basically the whole idea is to make the Trap output more accessible
for the first year students who are just starting out with programming. We
asked some of the senior students what they thought of the Trap output, and
most replied that they had always just ignored everything after the first
three lines. Of importance is the PC value, the module name and the
procedure name. Further than that, noone really used it.

The idea of the project is to take this output, and do a little bit of
editing and tweaking, so make it more user-friendly. Each Module.Procedure
header with its full variable dump is placed inside a gadget, and is hidden
from view, significantly cleaning up the output. Only when you click on the
Gadget does it display all the information. I have implemented an Iconizer
gadget with a Button on the front face and a TextNote on the back face. The
front face's caption is the Module.Procedure name of the current "stack
frame" (if you can call it that). The back face contains the variable dump
in that "stack frame". Also, when you click on the Button, the PC value is
fed to Compiler.Compile, the source code position determined, the relevant
source file opened, and the caret moved to the right position (basically an
automated, one-click Edit.Locate).

To do all of this, I have made changes to Exceptions.Mod, Oberon.Mod,
Texts.Mod and Compiler.Mod.

Quote:
> I'm sorry but I think this isn't possible in a straight forward, clean
way,
> i.e. without messing around with addresses and without patching the

system.
I'm not quite sure what you mean.

Quote:
> I thought about implementing an alternativ Texts.Open which would attach
to
> an already opened text if it existed. I would have used this as the
standard
> way in Edit.Open because I find it annoying after piling seven layers of
> views in one track to open an old version of a document, changing it,
> saving it and destroying this version after closing the viewers and
getting
> back to the modified but still not saved version of the very same
document.

> If you're willing to patch your system - let me know.

Yes, quite willing.

Quote:
> > Secondly, I need to be able to determine the Display Frame a text is
shown
> > in. I need this to be able to use Compiler.Locate programmatically (ie.
no
> > user clicking), and the CaretMsg protocol requires a frame to send the
> > message to. If there is some way of getting around this part of the
message,
> > that would also help.

> Unfortunately, this is also impossible but there is *no way* to solve that
> problem because there might simply no frame around. Texts.Text is a
> selfcontained data structure which can be handled and manipulated
perfectly
> without any frame, and in fact is often dealt with "off screen". Moreover
> there is a one to many relationship between texts and frames; the frames
> are kept in sync with the state of the text model by the calls of the
> notifier established in the text.

In my implementation, the text WILL always be shown, and thus will always
have a frame. So, if I KNOW there's a frame, can I get to it?

Quote:
> It could be however that there is a different approach to accomplish what
> you want to do. To be able to help we need more information.

Yes, sorry.

Quote:
> Basically a good idea is to include information about the host OS you are
> using, which HW platform (is it StrongARM?) and which version of the ObSys
> specifically.

RedHat Linux 6.2 and Linux Mandrake 8.0 on i586 machines, Linux Native
Oberon 2.3.7

The readme gives "ETH Oberon System release 2.3.7 for Linux x86"

I really appreciate the help =) Thanks



Mon, 29 Mar 2004 15:17:34 GMT  
 Questions about Gadgets programming in Linux Native Oberon 2.3.7
Sorry about the bogus name ... I posted the previous message from another
workstation without checking the connection settings.


Quote:


> > Would you like also to share what you've accomplished?
> Sure, basically the whole idea is to make the Trap output more accessible
> for the first year students who are just starting out with programming. We
> asked some of the senior students what they thought of the Trap output,
and
> most replied that they had always just ignored everything after the first
> three lines. Of importance is the PC value, the module name and the
> procedure name. Further than that, noone really used it.

> The idea of the project is to take this output, and do a little bit of
> editing and tweaking, so make it more user-friendly. Each Module.Procedure
> header with its full variable dump is placed inside a gadget, and is
hidden
> from view, significantly cleaning up the output. Only when you click on
the
> Gadget does it display all the information. I have implemented an Iconizer
> gadget with a Button on the front face and a TextNote on the back face.
The
> front face's caption is the Module.Procedure name of the current "stack
> frame" (if you can call it that). The back face contains the variable dump
> in that "stack frame". Also, when you click on the Button, the PC value is
> fed to Compiler.Compile, the source code position determined, the relevant
> source file opened, and the caret moved to the right position (basically
an
> automated, one-click Edit.Locate).

> To do all of this, I have made changes to Exceptions.Mod, Oberon.Mod,
> Texts.Mod and Compiler.Mod.

> > I'm sorry but I think this isn't possible in a straight forward, clean
> way,
> > i.e. without messing around with addresses and without patching the
> system.
> I'm not quite sure what you mean.

> > I thought about implementing an alternativ Texts.Open which would attach
> to
> > an already opened text if it existed. I would have used this as the
> standard
> > way in Edit.Open because I find it annoying after piling seven layers of
> > views in one track to open an old version of a document, changing it,
> > saving it and destroying this version after closing the viewers and
> getting
> > back to the modified but still not saved version of the very same
> document.

> > If you're willing to patch your system - let me know.
> Yes, quite willing.

> > > Secondly, I need to be able to determine the Display Frame a text is
> shown
> > > in. I need this to be able to use Compiler.Locate programmatically
(ie.
> no
> > > user clicking), and the CaretMsg protocol requires a frame to send the
> > > message to. If there is some way of getting around this part of the
> message,
> > > that would also help.

> > Unfortunately, this is also impossible but there is *no way* to solve
that
> > problem because there might simply no frame around. Texts.Text is a
> > selfcontained data structure which can be handled and manipulated
> perfectly
> > without any frame, and in fact is often dealt with "off screen".
Moreover
> > there is a one to many relationship between texts and frames; the frames
> > are kept in sync with the state of the text model by the calls of the
> > notifier established in the text.
> In my implementation, the text WILL always be shown, and thus will always
> have a frame. So, if I KNOW there's a frame, can I get to it?

> > It could be however that there is a different approach to accomplish
what
> > you want to do. To be able to help we need more information.
> Yes, sorry.

> > Basically a good idea is to include information about the host OS you
are
> > using, which HW platform (is it StrongARM?) and which version of the
ObSys
> > specifically.
> RedHat Linux 6.2 and Linux Mandrake 8.0 on i586 machines, Linux Native
> Oberon 2.3.7

> The readme gives "ETH Oberon System release 2.3.7 for Linux x86"

> I really appreciate the help =) Thanks



Mon, 29 Mar 2004 17:47:23 GMT  
 Questions about Gadgets programming in Linux Native Oberon 2.3.7

Quote:

> Firstly, I need to be able to check whether a view to a document already
> exists before I attempt opening a new one. I only want one view of a
> document at a time. This has to happen programmatically, ie. something like
>         IF ~IsOpen("Sort.Mod") THEN Documents.Open("Sort.Mod")

> Is there a way of checking, and if there is, how do you do it?

> Secondly, I need to be able to determine the Display Frame a text is shown
> in. I need this to be able to use Compiler.Locate programmatically (ie. no
> user clicking), and the CaretMsg protocol requires a frame to send the
> message to. If there is some way of getting around this part of the message,
> that would also help.

Perhaps this could help you.  The following ETH Oberon program
enumerates all visible frames in the display space.  Viewers covered
by System.Grow are not found, as the "under" link of a track is not
exported from module Viewers.

MODULE TestFrames;  (* pjm *)

IMPORT Display, Fonts, Texts, Viewers, Oberon;

CONST
  MaxLevel = 4;

VAR
  w: Texts.Writer;

PROCEDURE WriteLabel(s: ARRAY OF CHAR;  level: LONGINT);
VAR i: LONGINT;
BEGIN
  FOR i := 1 TO 2*level DO Texts.Write(w, " ") END;
  Texts.WriteString(w, s);
  FOR i := 2*level+1 TO 2*MaxLevel DO Texts.Write(w, " ") END
END WriteLabel;

PROCEDURE ShowFrame(u: Display.Frame;  level: LONGINT);
BEGIN
  WHILE u # NIL DO
    WriteLabel("Frame ", level);
    Texts.WriteInt(w, u.X, 6);  Texts.WriteInt(w, u.Y, 6);
    Texts.WriteInt(w, u.W, 6);  Texts.WriteInt(w, u.H, 6);
    Texts.WriteLn(w);
    ShowFrame(u.dsc, level+1);
    u := u.next
  END
END ShowFrame;

PROCEDURE Show*;
VAR text: Texts.Text;  fill, bot, alt, max, v: Display.Frame;  x: INTEGER;
BEGIN
  NEW(text);  Texts.Open(text, "");
  WriteLabel("LEVEL ", 0);
  Texts.WriteString(w, "     X");  Texts.WriteString(w, "     Y");
  Texts.WriteString(w, "     W");  Texts.WriteString(w, "     H");
  Texts.WriteLn(w);
  x := 0;
  REPEAT
    Viewers.Locate(x, 0, fill, bot, alt, max);
    v := fill;
    REPEAT
      v := v.next;
      WriteLabel("Viewer", 0);
      Texts.WriteInt(w, v.X, 6);  Texts.WriteInt(w, v.Y, 6);
      Texts.WriteInt(w, v.W, 6);  Texts.WriteInt(w, v.H, 6);
      IF v = fill THEN Texts.WriteString(w, " (filler)") END;
      Texts.WriteLn(w);
      ShowFrame(v.dsc, 1);
    UNTIL v = fill;
    Texts.WriteLn(w);
    INC(x, fill.W)
  UNTIL x = MAX(INTEGER);
  Texts.Append(text, w.buf);
  Oberon.OpenText("", text, 400, 400)
END Show;

BEGIN
  Texts.OpenWriter(w);
  Texts.SetFont(w, Fonts.This("Courier10.Scn.Fnt"))
END TestFrames.

TestFrames.Show

-- Pieter

--
Pieter Muller, Computer Systems Institute, ETH Zurich
Native Oberon OS: http://www.oberon.ethz.ch/native/



Mon, 29 Mar 2004 21:30:18 GMT  
 Questions about Gadgets programming in Linux Native Oberon 2.3.7

Quote:



> > Would you like also to share what you've accomplished?
> Sure, basically the whole idea is to make the Trap output more accessible
> for the first year students who are just starting out with programming. We
> asked some of the senior students what they thought of the Trap output, and
> most replied that they had always just ignored everything after the first
> three lines. Of importance is the PC value, the module name and the
> procedure name. Further than that, noone really used it.

> The idea of the project is to take this output, and do a little bit of
> editing and tweaking, so make it more user-friendly. Each Module.Procedure
> header with its full variable dump is placed inside a gadget, and is hidden
> from view, significantly cleaning up the output. Only when you click on the
> Gadget does it display all the information. I have implemented an Iconizer
> gadget with a Button on the front face and a TextNote on the back face. The
> front face's caption is the Module.Procedure name of the current "stack
> frame" (if you can call it that). The back face contains the variable dump
> in that "stack frame". Also, when you click on the Button, the PC value is
> fed to Compiler.Compile, the source code position determined, the relevant
> source file opened, and the caret moved to the right position (basically an
> automated, one-click Edit.Locate).

Sounds great.

I recently had to look more closely to the Trap Viewer and found that the
value of a LONGINT VAR parameter was different from the value of the
variable supplied as the parameter. Do you have any idea how this can happen?

Quote:
> To do all of this, I have made changes to Exceptions.Mod, Oberon.Mod,
> Texts.Mod and Compiler.Mod.

> > I'm sorry but I think this isn't possible in a straight forward, clean way,
> > i.e. without messing around with addresses and without patching the system.
> I'm not quite sure what you mean.

If you use SYSTEM.ADR to obtain some information or if you change the base
modules you'll be able to get the information you want. Without, I don't see
a chance. But since you already changed some of the base modules you could
continue that way and modify Files.Mod also.

Quote:
> > I thought about implementing an alternativ Texts.Open which would attach to
> > an already opened text if it existed. I would have used this as the standard
> > way in Edit.Open because I find it annoying after piling seven layers of
> > views in one track to open an old version of a document, changing it,
> > saving it and destroying this version after closing the viewers and getting
> > back to the modified but still not saved version of the very same document.

> > If you're willing to patch your system - let me know.
> Yes, quite willing.

:-)

I suggest to keep a list of open texts in Texts.Mod which is maintained
during the calls of Open, Close, New. I don't see how to handle the case
when a user changes the name of a document without storing it.

Quote:
> > > Secondly, I need to be able to determine the Display Frame a text is shown
> > > in. I need this to be able to use Compiler.Locate programmatically (ie. no
> > > user clicking), and the CaretMsg protocol requires a frame to send the
> > > message to. If there is some way of getting around this part of the message,
> > > that would also help.

> > Unfortunately, this is also impossible but there is *no way* to solve that
> > problem because there might simply no frame around. Texts.Text is a
> > selfcontained data structure which can be handled and manipulated perfectly
> > without any frame, and in fact is often dealt with "off screen". Moreover
> > there is a one to many relationship between texts and frames; the frames
> > are kept in sync with the state of the text model by the calls of the
> > notifier established in the text.
> In my implementation, the text WILL always be shown, and thus will always
> have a frame. So, if I KNOW there's a frame, can I get to it?

Yup. Basically you have to broadcast a SearchMsg that will return all frames
containing the text. Is it okay to have a list of frames instead of one as result?

Quote:
> > It could be however that there is a different approach to accomplish what
> > you want to do. To be able to help we need more information.
> Yes, sorry.

> > Basically a good idea is to include information about the host OS you are
> > using, which HW platform (is it StrongARM?) and which version of the ObSys
> > specifically.
> RedHat Linux 6.2 and Linux Mandrake 8.0 on i586 machines, Linux Native
> Oberon 2.3.7

Quite helpful, i.e. you're using the binary compatible version of NO under Linux.

Quote:
> The readme gives "ETH Oberon System release 2.3.7 for Linux x86"

> I really appreciate the help =) Thanks

Although you might be sure that in most cases the text will be owned by a frame:
I'm curious in what situation you need to get to the frame. It still seems to me
that there should be a different approach.

--
moc dot slupofni at norebo - please revert the sequence

Carpe Diem!



Mon, 29 Mar 2004 21:56:50 GMT  
 Questions about Gadgets programming in Linux Native Oberon 2.3.7

Quote:

> Sorry about the bogus name ... I posted the previous message from another
> workstation without checking the connection settings.

[SNIP]

No problem the answer is still the same ;-)

Please have a look at my reply to "John Smith".

--
moc dot slupofni at norebo - please revert the sequence

Carpe Diem!



Mon, 29 Mar 2004 21:58:31 GMT  
 Questions about Gadgets programming in Linux Native Oberon 2.3.7


Quote:



> > > Would you like also to share what you've accomplished?
> > Sure, basically the whole idea is to make the Trap output more
accessible
> I recently had to look more closely to the Trap Viewer and found that the
> value of a LONGINT VAR parameter was different from the value of the
> variable supplied as the parameter. Do you have any idea how this can

happen?

Hmm ... not too sure ... it could be that in Exceptions.Mod some word
boundaries are violated and the wrong words retrieved from memory, ie.
bottom half of one word and top half of next word returned to give LONGINT
... just a guess though.

Quote:
> I suggest to keep a list of open texts in Texts.Mod which is maintained
> during the calls of Open, Close, New. I don't see how to handle the case
> when a user changes the name of a document without storing it.

Hmmm ... actually I'm thinking your solution below will work here too.

Quote:
> Yup. Basically you have to broadcast a SearchMsg that will return all
frames
> containing the text. Is it okay to have a list of frames instead of one as

result?
If I get back a list of frames that contain the Text, then I can see if it
is open or not =) List = NIL means no open Text. A list of Frames is better
than nothing =) The first best one will have to do =)

So with one fell swoop, I can determine if the Text is open, AND I get its
Frame.

I take it this SearchMsg is already defined? Anything special about the
variables I have to know?

Quote:
> Although you might be sure that in most cases the text will be owned by a
frame:
> I'm curious in what situation you need to get to the frame. It still seems
to me
> that there should be a different approach.

So do I, but the CaretMsg requires it ... I haven't looked at ways of
circumventing that, because I have very little knowledge of that area.

I'll go try the SearchMsg and get back to you.

Thanks =)
Charl



Tue, 30 Mar 2004 14:51:27 GMT  
 Questions about Gadgets programming in Linux Native Oberon 2.3.7

[SNIP]

Quote:
> > I recently had to look more closely to the Trap Viewer and found that the
> > value of a LONGINT VAR parameter was different from the value of the
> > variable supplied as the parameter. Do you have any idea how this can
> happen?

> Hmm ... not too sure ... it could be that in Exceptions.Mod some word
> boundaries are violated and the wrong words retrieved from memory, ie.
> bottom half of one word and top half of next word returned to give LONGINT
> ... just a guess though.

I'll investigate that althouth the value wasn't kind of random but was the
value the variable had initially when supplied to the procedure.

Quote:
> > I suggest to keep a list of open texts in Texts.Mod which is maintained
> > during the calls of Open, Close, New. I don't see how to handle the case
> > when a user changes the name of a document without storing it.

> Hmmm ... actually I'm thinking your solution below will work here too.

Congratulation!

Quote:
> > Yup. Basically you have to broadcast a SearchMsg that will return all frames
> > containing the text. Is it okay to have a list of frames instead of one as result?
> If I get back a list of frames that contain the Text, then I can see if it
> is open or not =) List = NIL means no open Text. A list of Frames is better
> than nothing =) The first best one will have to do =)

> So with one fell swoop, I can determine if the Text is open, AND I get its
> Frame.

Yup.

Quote:
> I take it this SearchMsg is already defined? Anything special about the
> variables I have to know?

Unfortunately, this Message isn't defined yet and this is the catch: you
have to re-implement all handlers for Text. To be sure that the solution
will work still when others will have written handlers I suggest to add
this message to Texts. A Texts.Reopen procedure will broadcast this
message and attach to an eventually already open text.

I assume you need this for re-using a viewer which contains the source of
the module compiled with the PC's location. But what happens if the user
already manually opened the source twice?

Another problem: what if the source of the already open viewer has been
changed? Although this could be the case with a stored and still not opened
version of the source also I would refrain from re-using an opened source.
Instead I would check if the source's timestamp is older than that of the
code and if so open it in a newly created viewer and locate the caret at
the PC's equivalent position where the trap might have been happened.

Quote:
> > Although you might be sure that in most cases the text will be owned by a frame:
> > I'm curious in what situation you need to get to the frame. It still seems to me
> > that there should be a different approach.
> So do I, but the CaretMsg requires it ... I haven't looked at ways of
> circumventing that, because I have very little knowledge of that area.

To set the caret you will undoubtly need a frame.

Quote:
> I'll go try the SearchMsg and get back to you.

> Thanks =)
> Charl

Good luck!

--
moc dot slupofni at norebo - please revert the sequence

Carpe Diem!



Tue, 30 Mar 2004 17:50:56 GMT  
 Questions about Gadgets programming in Linux Native Oberon 2.3.7


Quote:

> I recently had to look more closely to the Trap Viewer and found that the
> value of a LONGINT VAR parameter was different from the value of the
> variable supplied as the parameter. Do you have any idea how this can happen?

That shouldn't happen! If you found that behaviour in one of the UnixOberon ports
I feel responsable. Can you reproduce that error in a (preferably small) module?
I would like to fix it.

-- Guenter



Tue, 30 Mar 2004 20:06:11 GMT  
 Questions about Gadgets programming in Linux Native Oberon 2.3.7

Quote:



> > Would you like also to share what you've accomplished?
> Sure, basically the whole idea is to make the Trap output more accessible
> for the first year students who are just starting out with programming. We

Just a short user feedback:
What I miss in the trap viewer is the expansion of records and the
dereferencing of pointer variables. It is an uncommodity to edit
modules, adding Out statements, compiling, edit modules to erase the Out
statements, compile again.
I like the structure of the trap viewer, but it might get pretty
inflated if everything would be expanded/dereferenced. Probably some
user interaction might be necessary.

-------------------------------------------------
Frank Hrebabetzky       Tel./Fax: +55 / 48 / 235 1106

Brasil



Tue, 30 Mar 2004 18:18:33 GMT  
 Questions about Gadgets programming in Linux Native Oberon 2.3.7

Quote:




> > I recently had to look more closely to the Trap Viewer and found that the
> > value of a LONGINT VAR parameter was different from the value of the
> > variable supplied as the parameter. Do you have any idea how this can happen?

> That shouldn't happen! If you found that behaviour in one of the UnixOberon ports
> I feel responsable. Can you reproduce that error in a (preferably small) module?
> I would like to fix it.

> -- Guenter

Now, I think your code is working flawlessly.

It's in the old ETH V4 Linux version and, yes, I can reproduce it in a
very small environment and very easily. I also saved a copy of the trap
viewer in my problem documentation document.

I'm using your version more and more to understand how the
Gadgets system is working and have a lot of questions but
found only one or two bugs. I'll let you know.

--
moc dot slupofni at norebo - please revert the sequence

Carpe Diem!



Wed, 31 Mar 2004 07:15:34 GMT  
 Questions about Gadgets programming in Linux Native Oberon 2.3.7

Quote:




> > > Would you like also to share what you've accomplished?
> > Sure, basically the whole idea is to make the Trap output more accessible
> > for the first year students who are just starting out with programming. We

> Just a short user feedback:
> What I miss in the trap viewer is the expansion of records and the
> dereferencing of pointer variables. It is an uncommodity to edit
> modules, adding Out statements, compiling, edit modules to erase the Out
> statements, compile again.
> I like the structure of the trap viewer, but it might get pretty
> inflated if everything would be expanded/dereferenced. Probably some
> user interaction might be necessary.

> -------------------------------------------------
> Frank Hrebabetzky       Tel./Fax: +55 / 48 / 235 1106

> Brasil

I also would like to see structured typed variables and
pointers in the trap viewer ;-)

--
moc dot slupofni at norebo - please revert the sequence

Carpe Diem!



Wed, 31 Mar 2004 07:16:42 GMT  
 Questions about Gadgets programming in Linux Native Oberon 2.3.7
The re-open problem is aggravated by the possibility to hide
documents in a desktop's Finder: hidden documents don't receive
messages - I checked that. These documents will be very unlikely
to find without maintaining a list of open texts which of course
introduces a problem for GC as texts may be not in use any longer
but haven't been explicitly closed. Therefore it seems to be the
correct way to use a broadcast but to extend the system to also
send messages to hidden documents.

A more technical approach would be to write a low level routine
that examins all pointers with appropriate types like the GC.
This approach has the advantage that it works independently of
programming mistakes like forgetting to implement a response
to the SearchMsg.

--
moc dot slupofni at norebo - please revert the sequence

Carpe Diem!



Thu, 01 Apr 2004 06:30:44 GMT  
 Questions about Gadgets programming in Linux Native Oberon 2.3.7
I got it all working =) Below is the main bits. IsTextOpen enumerates the
frames, and FindFrame checks whether a found frame is a Document and whether
the Document's name matches the file I'm looking for. Then in OpenAndPoint,
this frame is used to get the text with a LinkMsg.

(*--------------------------------------------------------------------------
-----------------------*)

PROCEDURE CompileAndOutput* (name : TS.str64; pc : LONGINT; VAR pos :
LONGINT);

VAR error : BOOLEAN; t, temp : Texts.Text; r : Texts.Reader; opt : ARRAY 32
OF CHAR;

BEGIN
 opt := "f"; NEW(t); Texts.Open(t, name); Texts.OpenReader(r,t,0);
 OPS.Init; NEW(temp); Texts.Open(temp, "");
 Compiler.Module(r, name, opt, pc, temp, error);
 pos := OPM.breakpos;
 temp := NIL;
END CompileAndOutput;

(*--------------------------------------------------------------------------
-----------------------*)

PROCEDURE FindFrame(u : Display.Frame; name : TS.str64; VAR found : BOOLEAN;
VAR f : Display.Frame);

BEGIN
 WHILE (u # NIL) & ~found DO
  IF u IS Documents.Document THEN
   IF u(Documents.Document).name = name THEN
    found := TRUE; f := u.dsc
   END;
  END;
  IF ~found THEN
   FindFrame(u.dsc, name, found, f);
   u := u.next;
  END;
 END;
END FindFrame;

(*--------------------------------------------------------------------------
-----------------------*)

PROCEDURE IsTextOpen(name : TS.str64; VAR found : BOOLEAN; VAR f :
Display.Frame);

VAR fill, bot, alt, max, v : Display.Frame; x : INTEGER;

BEGIN
 x := 0;
 found := FALSE;
 REPEAT
  Viewers.Locate(x, 0, fill, bot, alt, max);
  v := fill;
  REPEAT
   v := v.next;
   FindFrame(v.dsc, name, found, f);
  UNTIL (v = fill) OR found;
  INC (x, fill.W);
 UNTIL (x = MAX(INTEGER)) OR found;
END IsTextOpen;

(*--------------------------------------------------------------------------
-----------------------*)

PROCEDURE OpenAndPoint*;

VAR S : Texts.Scanner; name : TS.str64; pc, pos : LONGINT; T : Texts.Text;
 M: Oberon.CaretMsg; f : Display.Frame; found : BOOLEAN; L :
Objects.LinkMsg;

BEGIN
 Texts.OpenScanner(S, Oberon.Par.text, Oberon.Par.pos); Texts.Scan(S);
 COPY(S.s, name); Texts.Scan(S); pc := S.i;
 IsTextOpen(name, found, f);
 IF ~found THEN
  Texts.New; T := Objects.NewObj(Texts.Text); Texts.Open(T, name);
  IF T.len > 0 THEN
   Oberon.OpenText(name, T, Display.Width DIV 8*5 - 20, 300);
   IsTextOpen(name, found, f)
  END
 END;
 IF found THEN
  CompileAndOutput(name, pc, pos);
  L.id := Objects.get; L.name := "Model"; L.obj := NIL; L.res := -1;
f.handle(f, L);
  M.id := Oberon.set; M.F := f; M.car := f; M.text := L.obj(Texts.Text);
M.pos := pos; Display.Broadcast(M)
 END
END OpenAndPoint;

Quote:


> Perhaps this could help you.  The following ETH Oberon program
> enumerates all visible frames in the display space.  Viewers covered
> by System.Grow are not found, as the "under" link of a track is not
> exported from module Viewers.

> MODULE TestFrames;  (* pjm *)

> BEGIN
>   Texts.OpenWriter(w);
>   Texts.SetFont(w, Fonts.This("Courier10.Scn.Fnt"))
> END TestFrames.

> TestFrames.Show

This really helped, thanks =)

ciao
Charl



Fri, 02 Apr 2004 13:51:05 GMT  
 
 [ 15 post ] 

 Relevant Pages 

1. Questions about Oberon-3 & Gadgets

2. Native Oberon System-3 on Linux GGI

3. networking in linux native oberon

4. Installation of Native Oberon under Linux

5. question regarding native oberon in the coming era of legacy free computers

6. Oberon System 3 / Native Oberon projects

7. inquiry about Visual Oberon/PC Native Oberon System 3

8. Native Oberon: Getting DOS based installation out of Oberon-0

9. Oberon-2 in Native Oberon System 3

10. POLL: Interest in PC Oberon (Native Oberon)

11. JavaBeans vs Oberon Gadgets

12. gadgets for SPARC oberon ?

 

 
Powered by phpBB® Forum Software