Rexx & GUIs

I have read in several places that a proper GUI interface for Rexx is not
possible because Rexx doesn't support callback mechanisms, yet
Dave Morrill achieved it with DrDialog.
Can anyone please explain what "callback mechanisms" are?

Bob Martin wrote:
> I have read in several places that a proper GUI interface for Rexx is not
> possible because Rexx doesn't support callback mechanisms, yet
> Dave Morrill achieved it with DrDialog.
> Can anyone please explain what "callback mechanisms" are?

GUI programs are 'event driven'--i.e. when you hit a button, the program
goes and does something. The way this works is that when the main
program starts, it does all its setup and so forth and then enters a
message-handling loop, where it basically sits until the program exits.
(Some of the following is mildly OS/2 specific, because that's the
only system I've written down-on-the-metal GUI programs for.)

Part of the setup is to register callbacks, i.e. functions that get
called by the windowing system when an event occurs. Messages sort of
bubble up from the windowing system, which calls your code by way of a
callback--which is basically just a function pointer that you supply.
For instance, each window is a member of a window class. Each window
class has a message-handling routine which you supply when you register
the class.

The message loop blocks on a WinGetMsg call until a message arrives,
e.g. because of a timer, keypress, mouse movement, or something like
that. Then the message is passed to WinDispatchMsg, which looks at the
window ID given in the message, finds the callback function pointer to
the corresponding window procedure, and calls the window procedure with
the message as a parameter--at which point your code takes over and
handles the message. When the window procedure returns, the windowing
system takes over again.

In order to do this, you need some sort of function pointer mechanism
somewhere. In vanilla REXX, you could do this by having the window
procedures be separate files, or by having a big SELECT statement that
did different things depending on the message contents. (In C, window
procedures are typically giant switch statements.)

Some GUI builders, e.g. LabWindows, hide the giant switch statement from
you, and you just register function pointers that handle each individual
case, e.g. "mouse button 2 clicked on the main window". Those are also
callbacks. Other places where callbacks are used are signal handlers
(even REXX has those).

Cheers,

Phil Hobbs

Phil Hobbs wrote:

> Bob Martin wrote:
>
>> I have read in several places that a proper GUI interface for Rexx is not
>> possible because Rexx doesn't support callback mechanisms, yet Dave
>> Morrill achieved it with DrDialog. Can anyone please explain what
>> "callback mechanisms" are?
>
>
> GUI programs are 'event driven'--i.e. when you hit a button, the program
> goes and does something. The way this works is that when the main
> program starts, it does all its setup and so forth and then enters a
> message-handling loop, where it basically sits until the program exits.
> (Some of the following is mildly OS/2 specific, because that's the
> only system I've written down-on-the-metal GUI programs for.)
>
> Part of the setup is to register callbacks, i.e. functions that get
> called by the windowing system when an event occurs. Messages sort of
> bubble up from the windowing system, which calls your code by way of a
> callback--which is basically just a function pointer that you supply.
> For instance, each window is a member of a window class. Each window
> class has a message-handling routine which you supply when you register
> the class.
>
> The message loop blocks on a WinGetMsg call until a message arrives,
> e.g. because of a timer, keypress, mouse movement, or something like
> that. Then the message is passed to WinDispatchMsg, which looks at the
> window ID given in the message, finds the callback function pointer to
> the corresponding window procedure, and calls the window procedure with
> the message as a parameter--at which point your code takes over and
> handles the message. When the window procedure returns, the windowing
> system takes over again.
>
> In order to do this, you need some sort of function pointer mechanism
> somewhere. In vanilla REXX, you could do this by having the window
> procedures be separate files, or by having a big SELECT statement that
> did different things depending on the message contents. (In C, window
> procedures are typically giant switch statements.)
>
> Some GUI builders, e.g. LabWindows, hide the giant switch statement from
> you, and you just register function pointers that handle each individual
> case, e.g. "mouse button 2 clicked on the main window". Those are also
> callbacks. Other places where callbacks are used are signal handlers
> (even REXX has those).

This is done in quite a few GUI builders and is I think a perfectly fine
way (to me preferred in terms of reducing programming complexity).


> Cheers,
>
> Phil Hobbs
>
>
>
>


--

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

Gary Scott wrote:

>
> This is done in quite a few GUI builders and is I think a perfectly fine
> way (to me preferred in terms of reducing programming complexity).
>

I don't have any big issue with it...but I don't think it's any simpler
than just having a convention that all the cases of the switch statement
be function calls rather than inline code.

Nasty big window procedures with 10k LOC are horrible, for sure, but on
the other hand keeping all the function calls in one module makes it
easier to see what's going on, IMO. Horses for courses.

Cheers,

Phil Hobbs

On Jul 13, 7:16*pm, Bob Martin <bob.mar...@excite.com> wrote:
> I have read in several places that a proper GUI interface for Rexx is not
> possible because Rexx doesn't support callback mechanisms, yet
> Dave Morrill achieved it with DrDialog. *
> Can anyone please explain what "callback mechanisms" are?

I think your statement needs some clarification.

A callback mechanism is not defined for the Rexx SAA API, and most
Rexx interpreters do not provide a callback mechanism.

Regina does have an API function; RexxCallback() which enables a fully
functional and cross-platform GUI, Rexx/DW to register callbacks into
a Rexx program. ie a label in a Rexx program is called when an event
in the GUI is triggered.

Cheers, Mark

in 2544 20080713 221410 markh <rexx@users.sourceforge.net> wrote:
>On Jul 13, 7:16=A0pm, Bob Martin <bob.mar...@excite.com> wrote:
>> I have read in several places that a proper GUI interface for Rexx is not
>> possible because Rexx doesn't support callback mechanisms, yet
>> Dave Morrill achieved it with DrDialog. =A0
>> Can anyone please explain what "callback mechanisms" are?
>
>I think your statement needs some clarification.
>
>A callback mechanism is not defined for the Rexx SAA API, and most
>Rexx interpreters do not provide a callback mechanism.
>
>Regina does have an API function; RexxCallback() which enables a fully
>functional and cross-platform GUI, Rexx/DW to register callbacks into
>a Rexx program. ie a label in a Rexx program is called when an event
>in the GUI is triggered.
>
>Cheers, Mark

I'm only familiar with the IBM flavours of Rexx (been using it since 79/80)
and could not reconcile the frequently-made assertion that a proper GUI
was not possible with Dave Morrill's DrDialog, which I have used since it was
first available.
I suppose DrD must have built a stub which included this giant switch statement
and hooked up the user code to the various controls.
I'm slowly transferring from OS/2 to Linux and my biggest stumbling block at
the moment is the 12-15 DrDialog programs.

In <RJjek.25845$E41.19847@text.news.virginmedia.com >, on 07/13/2008
at 09:16 AM, Bob Martin <bob.martin@excite.com> said:

>I have read in several places that a proper GUI interface for Rexx is not
>possible because Rexx doesn't support callback mechanisms,

That's bogus on several grounds. First, the fact that PM and windoze use
callback does not mean that it is required for a proper GUI interface.
Second, there *are* GUI packages for REXX; none, AFAIK, cross platform.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org

Bob Martin wrote:

> I'm only familiar with the IBM flavours of Rexx (been using it since 79/80)
> and could not reconcile the frequently-made assertion that a proper GUI
> was not possible with Dave Morrill's DrDialog, which I have used since it was
> first available.
> I suppose DrD must have built a stub which included this giant switch statement
> and hooked up the user code to the various controls.
> I'm slowly transferring from OS/2 to Linux and my biggest stumbling block at
> the moment is the 12-15 DrDialog programs.

Could you run a virtualized copy of OS/2 and leave them the way they are?

Cheers,

Phil Hobbs

Phil Hobbs wrote:
> Could you run a virtualized copy of OS/2

Good idea. Virtualized OS/2 is the direction we went in:

Ubuntu / Parallels / OS/2 eComStation (eCS) Preloaded Computers
http://www.lueckdatasystems.com/OS2_...ation_Computer

--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/

On Jul 14, 3:41*am, Shmuel (Seymour J.) Metz
<spamt...@library.lspace.org.invalid> wrote:
> That's bogus on several grounds. First, the fact that PM and windoze use
> callback does not mean that it is required for a proper GUI interface.
> Second, there *are* GUI packages for REXX; none, AFAIK, cross platform.

Unless you use BSF4REXX, I'm certain Rony would say, with very good
reason.