Oberon/F dialogs 
Author Message
 Oberon/F dialogs

In Oberon/F, I want to execute the statement

StdCmds.OpenAuxDialog ("FileName", "WindowTitle")

in the middle of a procedure where FileName is
the name of a file that contains a form I designed
to link with an interactor.  Unfortunately, although
the dialog is displayed, the program immediately
continues executing not giving the user a chance to
interact with the dialog.  Is it possible to accomplish
this with "command programming" techniques, or must I
resort to the lower-level "view programming"?  In either
case, can someone point me in the right direction?

Thanks.

Stan Warford
Pepperdine University



Wed, 14 Jan 1998 03:00:00 GMT  
 Oberon/F dialogs

Quote:

> In Oberon/F, I want to execute the statement

> StdCmds.OpenAuxDialog ("FileName", "WindowTitle")

> in the middle of a procedure where FileName is
> the name of a file that contains a form I designed
> to link with an interactor.  Unfortunately, although
> the dialog is displayed, the program immediately
> continues executing not giving the user a chance to
> interact with the dialog.  Is it possible to accomplish
> this with "command programming" techniques, or must I
> resort to the lower-level "view programming"?  In either
> case, can someone point me in the right direction?

> Thanks.

Oberon/F does things in a little more event-driven fashion: You don't have to wait for data to come to you, Oberon/F will send it to you. Here is how it works: Simply create a button inside the from, get its properties and enter the procedure (can be type-bound to a global variable as well) you would like to be called when someone presses the button and pick up the data from the interactor there.
Hope that helps.

Axel

- Show quoted text -

Quote:

> Stan Warford
> Pepperdine University




Fri, 16 Jan 1998 03:00:00 GMT  
 Oberon/F dialogs

Quote:
Axel writes:


> > In Oberon/F, I want to execute the statement

> > StdCmds.OpenAuxDialog ("FileName", "WindowTitle")

> > in the middle of a procedure where FileName is
> > the name of a file that contains a form I designed
> > to link with an interactor.  Unfortunately, although
> > the dialog is displayed, the program immediately
> > continues executing not giving the user a chance to
> > interact with the dialog.  Is it possible to accomplish
> > this with "command programming" techniques, or must I
> > resort to the lower-level "view programming"?  In either
> > case, can someone point me in the right direction?

> > Thanks.

> Oberon/F does things in a little more event-driven fashion: You
> don't have to wait for data to come to you, Oberon/F will send
> it to you. Here is how it works: Simply create a button inside
> the form, get its properties and enter the procedure (can be
> type-bound to a global variable as well) you would like to be
> called when someone presses the button and pick up the data from
> the interactor there.
> Hope that helps.

> Axel

I don't think it does.  I _have_ buttons bound to procedures in
the form, but the problem is that the program (i.e. one long
command) continues on to termination before I can interact with the
dialog.  As I have been thinking about this, it occurs to me that
what I want to do is similar to a command-line prompt.  Perhaps
the GUI-based Oberon/F framework does not lend itself to this kind
of behavior.  In every example using the Forms subsystem, the
command terminates leaving the form active.  I want the command
suspended, leaving the form active, to be resumed when I am
finished with the form.  (I tried opening the form as a tool
window instead of aux, but with the same behavior.)

My question remains, do I have to resort to lower-level "view
programming" to get this kind of modal behavior?

Stan Warford
Pepperdine University



Sat, 17 Jan 1998 03:00:00 GMT  
 Oberon/F dialogs

Quote:

> Axel writes:


>> > In Oberon/F, I want to execute the statement

>> > StdCmds.OpenAuxDialog ("FileName", "WindowTitle")

[snip]

> I don't think it does.  I _have_ buttons bound to procedures in
> the form, but the problem is that the program (i.e. one long
> command) continues on to termination before I can interact with the
> dialog.  As I have been thinking about this, it occurs to me that
> what I want to do is similar to a command-line prompt.  Perhaps
> the GUI-based Oberon/F framework does not lend itself to this kind
> of behavior.  In every example using the Forms subsystem, the
> command terminates leaving the form active.  I want the command
> suspended, leaving the form active, to be resumed when I am
> finished with the form.  (I tried opening the form as a tool
> window instead of aux, but with the same behavior.)

> My question remains, do I have to resort to lower-level "view
> programming" to get this kind of modal behavior?

> Stan Warford
> Pepperdine University


You need to split your long command at the point you load the form.
Move the rest of the code from the long command to the procedure
bound to the OK button on the form.  The result is one command that
initializes and loads the form, and another the does the action of
the form when the OK button is pressed.  This lets Oberon/F be
"mode-less" -- the user can do other things between the time
the form is loaded and the OK button is pressed, such as run other
commands.

Cheers,
Ian Rae



Sat, 17 Jan 1998 03:00:00 GMT  
 Oberon/F dialogs

Quote:


> [snip]

> > I don't think it does.  I _have_ buttons bound to procedures in
> > the form, but the problem is that the program (i.e. one long
> > command) continues on to termination before I can interact with the
> > dialog.  As I have been thinking about this, it occurs to me that
> > what I want to do is similar to a command-line prompt.  Perhaps
> > the GUI-based Oberon/F framework does not lend itself to this kind
> > of behavior.  In every example using the Forms subsystem, the
> > command terminates leaving the form active.  I want the command
> > suspended, leaving the form active, to be resumed when I am
> > finished with the form.  (I tried opening the form as a tool
> > window instead of aux, but with the same behavior.)

> > My question remains, do I have to resort to lower-level "view
> > programming" to get this kind of modal behavior?

> > Stan Warford
> > Pepperdine University

> You need to split your long command at the point you load the form.
> Move the rest of the code from the long command to the procedure
> bound to the OK button on the form.  The result is one command that
> initializes and loads the form, and another the does the action of
> the form when the OK button is pressed.  This lets Oberon/F be
> "mode-less" -- the user can do other things between the time
> the form is loaded and the OK button is pressed, such as run other
> commands.

Thanks for the suggestion, but ...

I considered that option, but it is not a viable one.  I am deeply
nested in the command with an internal state that would need to be
saved (many activated procedures with a big run-time stack).  Besides
the complexity of such an undertaking it would make no logical sense,
either from the programmer's or the user's point of view to do such
a thing.  It would be confusing to the user.  I simply need a modal
form.  How do I do it in Oberon/F?

Stan Warford
Pepperdine University



Sat, 17 Jan 1998 03:00:00 GMT  
 Oberon/F dialogs

Quote:

> Thanks for the suggestion, but ...

> I considered that option, but it is not a viable one.  I am deeply
> nested in the command with an internal state that would need to be
> saved (many activated procedures with a big run-time stack).  Besides
> the complexity of such an undertaking it would make no logical sense,
> either from the programmer's or the user's point of view to do such
> a thing.  It would be confusing to the user.  I simply need a modal
> form.  How do I do it in Oberon/F?

I don't know.  It's interesting that Oberon/F implements the File Open dialog
with a single procedure call.  This runs a modal dialog, but its not clear
whether this is done in Oberon or by calling the appropriate Windows/Mac
modal dialog.  So maybe its not possible??

Kludge: If the Mac has an equivalent to the Windows API call MessageBox(), you
could ask the user a three-state question modally
  "Do you want xxx? Yes/No/Cancel"

It sounds like your well into the project so (grin) you probably don't want to
hear the following suggestion, but here goes...

Without knowing the details, it sounds a bit strange that your command with the
big internal state doesn't have all its input data available when it starts.  
GUIs "normally" arrange things so the data is either explicitly (eg. selected
text) or implicitly (eg. default colour) defined before the action commences.
Could your dialog be moved to the front of the command, or into
a separate preferences area?

Ian Rae



Sun, 18 Jan 1998 03:00:00 GMT  
 Oberon/F dialogs

Quote:

> In Oberon/F, I want to execute the statement

> StdCmds.OpenAuxDialog ("FileName", "WindowTitle")

> in the middle of a procedure where FileName is
> the name of a file that contains a form I designed
> to link with an interactor.  Unfortunately, although
> the dialog is displayed, the program immediately
> continues executing not giving the user a chance to
> interact with the dialog.  Is it possible to accomplish
> this with "command programming" techniques, or must I
> resort to the lower-level "view programming"?  In either
> case, can someone point me in the right direction?

I believe that to get a modal dialog, you will have to resort to
calling the Mac Dialog Manager yourself - losing much of the
benefit of Oberon/F's visual form designer. Oberon/F doesn't seem
 to have builtin support for modal dialogs.

Mayson G. Lancaster



Mon, 19 Jan 1998 03:00:00 GMT  
 Oberon/F dialogs

Quote:

> I believe that to get a modal dialog, you will have to resort to
> calling the Mac Dialog Manager yourself - losing much of the
> benefit of Oberon/F's visual form designer. Oberon/F doesn't seem
> to have builtin support for modal dialogs.

That is the sad conclusion I have come to as well.  :(
It's too bad, because the main reason I embarked on this
project was to convert my program from a command line interface
to a GUI that would run under both MacOS and MS Windows with
platform-independent code.  The Dialog module provides a GetOK
modal dialog and modal dialogs for file locations, but nowhere
in Oberon/F can you design your own modal dialogs.  (Can you
in other Oberon systems?)

Quote:
>From a developer's point of view, I would like to use the visual

form designer to create my dialog, and then use a command similar
to

StdCmds.OpenAuxDialog ("File path", "Window name")

perhaps with the syntax

StdCmds.OpenModalDialog ("File path")

since modal dialogs do not have window names.  My need for a
modal dialog reminds me of a comment I once heard about recursion.
"You don't need it often, but when you do need it you need it
badly."  I am basically stuck at this point without the ability
to design my own modal dialog.

Stan Warford
Pepperdine University



Mon, 19 Jan 1998 03:00:00 GMT  
 Oberon/F dialogs

Quote:

> It sounds like your well into the project so (grin) you probably
> don't want to hear the following suggestion, but here goes...

> Without knowing the details, it sounds a bit strange that your
> command with the big internal state doesn't have all its input
> data available when it starts.  GUIs "normally" arrange things
> so the data is either explicitly (eg. selected text) or implicitly
> (eg. default colour) defined before the action commences.
> Could your dialog be moved to the front of the command, or into
> a separate preferences area?

The problem is that the input (even whether any further input will
be required at all) depends on the computation, and cannot be
predicted in advance.  Admitedly, such situations are rare--all
of my other dialogs are modeless.  But modal dialogs are sometimes
necessary, and it seems like the Oberon/F development environment
should provide the ability to design them.

Stan Warford
Pepperdine University



Mon, 19 Jan 1998 03:00:00 GMT  
 Oberon/F dialogs

Quote:


> > I believe that to get a modal dialog, you will have to resort to
[yak yak]
> modal dialog and modal dialogs for file locations, but nowhere
> in Oberon/F can you design your own modal dialogs.  (Can you
> in other Oberon systems?)

After seeing all those messages about Oberon/F and modal dialogs,
I am wondering if any of you read about the basic concepts of
System Oberon. E.g., in Project Oberon, chapter 2 (Basic Concepts):

   Modes are in our view the hallmark of user-unfriendly systems.

This is directly against modal dialogs.

Then, in Oberon, texts can be in an editor, or function as a menu.
In The Oberon System, chapter 1.2 (Oberon User Interface):

   The modality of texts has been abolished. What looks like
   menus in the title bars of the viewers is text too, no
   different from the editable text of the main viewer area.

I understand that some people get e{*filter*}d about creating old
style Windows programs with the new Oberon language using
Oberon/F. But by sticking to the old style windows you will
keep all those problems associated. Anyone has the right to
use whatever language for whatever you like. But I would be
sad to see this newsgroup turn into some kind of Windows
programming support group.

I am interested in discussions about Oberon, not about Windows,
Mac or other arcane stuff, for which there are plenty other
newsgroups.

The only Windows topic I am vaguely interested about is e.g., if someone
could give a reasonable argument why modal stuff is better
than the Oberon way.

Thank you for letting me put in my two cents.

-------------------------------------------------------------------


-------------------------------------------------------------------



Tue, 20 Jan 1998 03:00:00 GMT  
 Oberon/F dialogs

Quote:


>> > I believe that to get a modal dialog, you will have to resort to
> [yak yak]
>> modal dialog and modal dialogs for file locations, but nowhere
>> in Oberon/F can you design your own modal dialogs.  (Can you
>> in other Oberon systems?)

> ...
>    Modes are in our view the hallmark of user-unfriendly systems.
> ...

>    The modality of texts has been abolished. What looks like
>    menus in the title bars of the viewers is text too, no
>    different from the editable text of the main viewer area.

This is all very true, but I think, that the problem is, that Oberon does'n
support parallel processes (maybe Oberon/F does?). Imagine a command that
can't get all it's input at it's start because the input depends on the
computation, as the autor of the first posting described.
The command will have to open a Tool/Viewer/Dialog and wait for the input to
be entered. But since Tools/Viewers/Dialogs are managed by the system
(Oberon.Loop) the command has to be a parallel process to the system.
In standard Oberon, the only way to achieve this, is to split the command into
units wich can be installed as a task. But this was exactly what the Autor of
the first posting wanted to avoid.

Hovewer, if Oberon/F does not support parallel processes, this is the only
solution, apart from modal Dialogs.

I don't know of any genreal method to split a command into task units, but
imagine an easy case:

MODULE ParallelCommand;

IMPORT Oberon,Processes;

VAR task,calculation: Processes.Task;

PROCEDURE Calc;
VAR a,b,c: REAL;
 ... local variables
BEGIN
  ... get input
  LOOP
    ... calculate part of output
    Processes.Pass(task);
  END
  ... write output

  Oberon.RemoveTask(Oberon.CurTask));
  Processes.Pass(task);
END Calc;

PROCEDURE Task;
BEGIN
  Processes.Pass(calculation)
END Task;

PROCEDURE Do*;
VAR t: Oberon.Task;
BEGIN NEW(t); t.proc := Task;
  task := Processes.This();
  calculation := Processes.New(Calc,2000 (* stack size *));
  Oberon.InstallTask(t);
END Do;

END ParallelProcess;

This could be translated into

MODULE SplitParallelCommand;

IMPORT Oberon;

TYPE Task = POINTER TO TaskDesc;
  TaskDesc = RECORD (Oberon.TaskDesc)
    a,b,c: REAL;
    ... local variables
  END;

PROCEDURE Calc;
BEGIN
 ... calculate part of the output
 (local vars are located in Oberon.CurTask)

 IF finished THEN
   ... write output
   Oberon.RemoveTask(Oberon.CurTask)
 END
END Calc;

PROCEDURE Do*;
VAR t: Task;
BEGIN NEW(t) t.proc := Calc;
 ... get input
 Oberon.InstallTask(t)
END Do;

END SplitParallelCommand;

Normaly, Calc is much more complicated, Processes.Pass may be nested into IF's
or even into local procedures.
The only solution is to move the information about the internal STATE of the
process from the CONTROL FLOW to local variables.

hope this helps somewhat :(

Simon Egli



Fri, 23 Jan 1998 03:00:00 GMT  
 Oberon/F dialogs

Quote:


> |>  But since Tools/Viewers/Dialogs are managed by the system
> |> (Oberon.Loop) the command has to be a parallel process to the system.

> No, it doesn't. It's possible to make the processing non-modal
> without requiring a parallel process.

Ok, I didn't mean to say It is impossible.

Quote:
> The key is to stop thinking in terms of procedures and start
> thinking in terms of objects and methods. Define a data
> structure which contains the current state of the computation,
> with methods which carry out the various processing steps.

If you install a task under Oberon it is indeed an object with
a procedure variable as method. The task may well hold any data structure you
like. But still the atomic unit of action is the procedure/method.
And not all of the state of the computation is located in the
data structures, some of it is also contained in the control flow.
The problem remains to reduce the control flow, so that all information
about the state of the computation can be expressed in variables.
you'll still have to split your long running command into small units.

Simon Egli

The key is not to introduce new terminology for old beets :)



Sat, 24 Jan 1998 03:00:00 GMT  
 Oberon/F dialogs

|>  But since Tools/Viewers/Dialogs are managed by the system
|> (Oberon.Loop) the command has to be a parallel process to the system.

No, it doesn't. It's possible to make the processing non-modal
without requiring a parallel process.

The key is to stop thinking in terms of procedures and start
thinking in terms of objects and methods. Define a data
structure which contains the current state of the computation,
with methods which carry out the various processing steps.
Define a viewer which shows the user the current state and
provides the means for the various processing options to
be initiated.

Not only will the result be non-modal, the user will be
able to have multiple instances of it active at once
if desired. And other features such as being able to
save the intermediate state, copy information between
instances, etc. could be added more easily if thought
useful.

|> Simon Egli

Greg



Sat, 24 Jan 1998 03:00:00 GMT  
 Oberon/F dialogs

Quote:

>of my other dialogs are modeless.  But modal dialogs are sometimes
>necessary, and it seems like the Oberon/F development environment
>should provide the ability to design them.

Your experience as an early user of Oberon/F is worth following -- "Oberon
meets reality".  It sounds like it's faring pretty well, but is still missing
a few things for getting developers out of tight spots.  Modal dialogs are
not the preferred option, but their existence would allow an initial port
of your code to Oberon/F be done quickly -- a better version could be
developed later.

Possible implementation for modal dialogs:

1. Frame.Input() is a procedure that polls for mouse events.  It could be
 used in a loop to prevent execution from proceeding until a mouse
 click occured in a certain area that had the appearance of a button.  
 The view would have to emulate widgets with logic in the loop -- eg. check
 for clicks in the up/down "buttons" of an emulated spin box.  
 The result would be a simplistic modal dialog box with a mouse-only
 interface.

 Pseudo-code:
  <open the "modal dialog box" view>
   REPEAT
        f.Input(x,y,m,isDown);
        <..add logic for handling widgets here..>
        UNTIL <isDown AND (x,y) within the OK "button">
  END

2. The Mac Toolbox should have a function that temporarily yields control
   to the O/S, allowing other apps/windows to continue processing events.
   Yield() is the equivalent Windows function.

   A normal Oberon/F form could be made modal by declaring a global variable
   which it sets true upon termination.  The procedure that invokes the
   form would loop indefinitely until the variable becomes true.

   Pseudo-code:
        modalFinished := false;
        StdCmds.OpenAuxDialog (...);
        WHILE ~modalFinished DO
          <yield to o/s>
        END;

Neither solution is pretty...

Ian Rae



Sat, 24 Jan 1998 03:00:00 GMT  
 Oberon/F dialogs

|>   WHILE ~modalFinished DO
|>     <yield to o/s>
|>   END;

That wouldn't work - it's not just a matter of yielding
to the OS. You need an event loop that reads events,
filters out those not related to the dialogue window
concerned, and passes the remainder to Oberon/F's
event dispatching mechanism. There must be a procedure
in there somewhere that does the latter, if it can
be found, and if it's in a module for which a symbol
file is provided...

|>
|> Neither solution is pretty...
|>                                                  
|> Ian Rae
|>



Mon, 26 Jan 1998 03:00:00 GMT  
 
 [ 17 post ]  Go to page: [1] [2]

 Relevant Pages 

1. ANNOUNCE: tk_filesel v0.99, Tk4.1+ Motif-ish FS dialog

2. Oberon V4 Dialogs Package

3. Oberon/F modal dialogs

4. Oberon/F modal dialogs

5. Oberon.Dialogs

6. Directory Dialog/File Dialog

7. Second Try - Call modal dialog from modal dialog

8. Call modal dialog from modal dialog?

9. Frage Oberon 3 / Question Oberon 3

10. CD-Oberon - Oberon/F

11. CD-Oberon Oberon 3 Printer Problem

12. Oberon System 3 / Native Oberon projects

 

 
Powered by phpBB® Forum Software