On Mon, May 31, 2010 at 8:30 AM, Rick McGuire <object.r...@gmail.com> wrote:

> What is the mail thread doing while this is happening?  Is it possible
> to save the condition data that triggered the failure and pass a
> message to the main thread that causes it to reraise the failure
> condition?

Ah, that's a good idea.  I've taken out the polling loop altogether.
The main thread, after starting the underlying Windows dialog, is
doing what I think of as a 'guard on' wait.

::method run unguarded private
   expose finished
   guard on when finished

and that's the end of the method.  When the finished attribute goes
true, the method ends and returns to execute():

::method execute unguarded
   expose dlgData.
   use strict arg sh = "NORMAL", icon = 0, sleepTime = 1, modeless = .false

   icon = self~resolveIconId(icon)
   if self~startIt(icon, modeless) \= 0 then do
   ... -- set up stuff

      self~run

      if self~initCode = 1 then do
   ... -- clean up stuff
  end

I could rework the semantics there and do something like:

  guard on when messagePending
  if self~finished then return
  if conditionPending then self~processsPendingCondition
 ...

I actually have two scenarios here.

1.) On the Windows message processing loop, (where I have a thread
context,) where the Windows message accepts a reply, or for any new
event connections I've added:  I use SendMessage() to directly invoke
the Rexx method, (which means of course I get the return from the Rexx
method.)

Here, after the return I use CheckCondition().  If there is a
condition, I print to the console the condition information is the
same format as the interpreter normally does.  At this point, I could,
or could not, terminate the dialog where the condition was raised.

I could use your idea to instead reraise the condition on the main
thread, which would more closely follow the existing behavior when a
condition is raised.

2.) On the Windows message processing loop where the Windows message
ignores any reply and the event connection is one that has been
present in the past:  I basically do a startWith() for the Rexx event
handling method.

I do this because some of the programs I have laying around that
people have sent me, and a few of the existing ooDialog sample
programs, hang if I directly invoke the Rexx event handling method.
They hang because they don't quickly return.  By using startWith() the
Window processing loop quickly continues.

In this scenario, if the Rexx method cause some type of condition, the
information is printed and the program continues.  Here is where I
don't / didn't see an easy way mimic the old behavior of the program
normally ending.

I mean I can think of some things, but they seem too convoluted.
Like, I could save the message reply from startWith() put it in some
collection and periodically check if it finished without raising a
condition.  Reraise the condition, if there was one.

--
Mark Miesfeld

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

_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Reply via email to