On Sat, May 29, 2010 at 10:25 PM, Sahananda (Jon) Wolfers
<sahana...@windhorse.biz> wrote:

> I can't think of any other way around this problem than
> through the loophole you are proposing to close.

Well, I can think of a number of ways, as could Rony. <grin>

Here is a concrete example, it runs on both 3.2.0 ooDialog and with
the latest version of ooDialog with the "loophole" closed.

Read past the code to see the ouput.

/* Simple Dialog with an edit line to
 * execute SQL on main thread
 */

  dlg = .SimpleDialog~new

  if dlg~initCode = 0 then do
    dlg~constDir[IDC_EDIT_ONE] = 200
    dlg~constDir[IDC_PB_PUSHME] = 201

    dlg~create(30, 30, 240, 70, -
               "Simple Entry Control Dialog", -
               "VISIBLE")

    say 'Main program executing on thread:'  -
         --.DlgUtil~test(.true)

    dlg~executeAsync("SHOWTOP")

    dlg~start(PalmScheduleChecks)
    dlg~pollForMessages
    dlg~endAsyncExecution
  end

-- End of entry point.

::requires "OODWin32.cls"

::class SimpleDialog subclass UserDialog -
                     inherit AdvancedControls -
                     MessageExtensions

::attribute haveMessage unguarded
::attribute message

::method defineDialog
  expose haveMessage

  self~autoDetect = 0

  styles = "AUTOSCROLLH KEEPSELECTION"
  self~addEntryLine(IDC_EDIT_ONE, , 10, 10, 100, -
                    12, styles)

  self~addButton(IDC_PB_PUSHME, 10, 40, 35, 15,  -
                 "Push Me", pushed, "DEFAULT GROUP")
  self~addButton(IDOK, 75, 40, 35, 15, "OK")

  haveMessage = .false
  self~message = ""

::method initDialog
  expose editControl

  editControl = self~getEditControl(IDC_EDIT_ONE)
  say 'initDialog() executing on thread:' -
  --.DlgUtil~test(.true)

::method pushed
  expose editControl
  parse value editControl~selected with start end
  say 'selection start:' start 'end:' end
  say

::method pollForMessages unguarded
  expose haveMessage editControl

  do while \ self~finished
    guard on when haveMessage

    if  self~finished then leave

    say 'Executing a SQL statement on thread:' -
    --.DlgUtil~test(.true)
    editControl~setText(self~message)
    haveMessage = .false

    guard off
  end

::method PalmScheduleChecks   unguarded
  expose haveMessage

  sqlThings = .array~of("Update table", "Query user data", -
                        "Compact database", "Re-index")
  counter = 0

  do forever
    if self~finished then leave
    j = SysSleep(1)

    counter += 1
    if counter == 3 then do
      msgNum = random(1, 4)

      say 'PalmScheduleChecks() checking Palm from thread:' -
      --.DlgUtil~test(.true)

      self~message = sqlThings[msgNum]
      if self~finished then leave

      haveMessage = .true

      counter = 0
    end
  end

::method ok unguarded
  expose haveMessage

  self~ok:super
  haveMessage = .true

::method cancel unguarded
  expose haveMessage

  self~cancel:super
  haveMessage = .true


Note that in the above code I have .DlgUtil~test(.false) commented
out.  That is so it will run on 3.2.0.  That method invocation prints
out the current thread ID, but it is just something I have implemented
in trunk.

Running on 4.1.0 trunk, using .DlgUtil~test, here is some output:

C:\work.ooRexx\other\feature.requests\jon.palm>rexx -v
Open Object Rexx Version 4.1.0 - Internal Test Version
Build date: May 30 2010
Addressing Mode: 64

Copyright (c) IBM Corporation 1995, 2004.
Copyright (c) RexxLA 2005-2009.
All Rights Reserved.
This program and the accompanying materials
are made available under the terms of the Common Public License v1.0
which accompanies this distribution.
http://www.oorexx.org/license.html

C:\work.ooRexx\other\feature.requests\jon.palm>

C:\work.ooRexx\other\feature.requests\jon.palm>sqlRun.rex
Main program executing on thread: 2584
initDialog() executing on thread: 2584
PalmScheduleChecks() checking Palm from thread: 3660
Executing a SQL statement on thread: 2584
PalmScheduleChecks() checking Palm from thread: 3660
Executing a SQL statement on thread: 2584
PalmScheduleChecks() checking Palm from thread: 3660
Executing a SQL statement on thread: 2584
PalmScheduleChecks() checking Palm from thread: 3660
Executing a SQL statement on thread: 2584
PalmScheduleChecks() checking Palm from thread: 3660
Executing a SQL statement on thread: 2584
PalmScheduleChecks() checking Palm from thread: 3660
Executing a SQL statement on thread: 2584

C:\work.ooRexx\other\feature.requests\jon.palm>

As you can see, PalmScheduleChecks() is running on thread 3660 and the
SQL statements would be executed on thread 2584, which is the main
thread.

Here is the same program running on ooDialog 3.2.0, you have to take
it on faith that the threads are different:

Z:\other\feature.requests\jon.palm>rexx -v
Open Object Rexx Interpreter Version 3.2.0
Build date: Oct 30 2007
Copyright (c) IBM Corporation 1995, 2004.
Copyright (c) RexxLA 2005-2007.
All Rights Reserved.
This program and the accompanying materials
are made available under the terms of the Common Public License v1.0
which accompanies this distribution.
http://www.oorexx.org/license.html
Z:\other\feature.requests\jon.palm>

Z:\other\feature.requests\jon.palm>sqlRun.rex
Main program executing on thread:
initDialog() executing on thread:
PalmScheduleChecks() checking Palm from thread:
Executing a SQL statement on thread:
PalmScheduleChecks() checking Palm from thread:
Executing a SQL statement on thread:
PalmScheduleChecks() checking Palm from thread:
Executing a SQL statement on thread:
PalmScheduleChecks() checking Palm from thread:
Executing a SQL statement on thread:
PalmScheduleChecks() checking Palm from thread:
Executing a SQL statement on thread:
PalmScheduleChecks() checking Palm from thread:
Executing a SQL statement on thread:
PalmScheduleChecks() checking Palm from thread:
Executing a SQL statement on thread:
PalmScheduleChecks() checking Palm from thread:
Executing a SQL statement on thread:
PalmScheduleChecks() checking Palm from thread:
Executing a SQL statement on thread:
PalmScheduleChecks() checking Palm from thread:
Executing a SQL statement on thread:

Z:\other\feature.requests\jon.palm>

Another way to implement it would be to, on the Palm thread, put the
messages in a queue and pull the message from the queue on the main
thread.

All in all, there are a number of ways to do what you want, that don't
involve relying on an undocumented implementation detail.  <grin>

--
Mark Miesfeld

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

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

Reply via email to