OpenEuphoria

Re: An Experiment

• Posted by Irv <irv at ELLIJAY.COM> Aug 18, 1998
• 781 views

Ralf Nieuwenhuijsen (also) wrote:
>
...
> Yet, a GUI is also a crucial tool, that you will need for any program.
> Robert should consider adding standard GUI include file, thats easy to use,
> and a lot less OOP-ish. (a message box, open window, make window, make
> button, and have an event () routine tell you what key was pressed, what
> mouse action occured, or what button was pressed. (you first declare an
> event) .. a sort of wait_event () routine, avoiding all the 'complex-to-use'
> OO-approuches.

Ralf: I don't think a non-OOP approach to a GUI will be any more simple.
Consider this: if the "objects" on a screen do not "know" what to do
when they are clicked on, then the programmer will have to write
a lot of statements to handle the clicks. For example,
let's use a name and address entry screen with some non-oop code:

WINDOW = makeWindow(size and stuff here)
CLOSEBTN = makeButton(WINDOW,"Close")-- assuming automatic positioning
here
NAME = makeEditControl(WINDOW,"")
etc...
onClick[WINDOW] do Focus(Window)
onClick[TITLEBAR] do Drag(Window)
onClick[CLOSEBTN] do Close(Window)
onClick[NAME] do Edit(NAME)
onClick[ADDR] do ...
onClick[CITY] do ...
onClick[STATE] do...
onClick[SaveButton] do...

Next we write some onKey() handler code.....arrgh!
Note that all these *must* be declared, as a minimum. Otherwise, you'll
just
have a nice looking screen that does nothing.

Also consider that in each of these lines the programmer is only telling
the program  to do what should come naturally. If you click on a close
button,
what else should it do but close the window? Likewise, an edit field
just
naturally wants to bw edited.

I think a set of pre-defined objects (all the standard ones for a GUI)
should
be added to Euphoria as an include. Everything should be callable with
one
line of code (all possible defaults in place).
(Not like writing to the Win API.  No *&#$*@# handles, please!)
And by all means not forcing an OOP approach on the rest of the
programmer's code.

The main difficulty I see - difficult only because I am not very good at
planning things - is an easy method of getting data into and out of
controls.
Even tricker, a method of "linking" two controls so they respond to each
other.
Maybe someone can contribute those things?

Regards,

Irv