Hi Mark, I can't offer you much on this, but you ask
On 28 May 2010 17:24, Mark Miesfeld <[email protected]> wrote: > Mostly directed to Rick because he probably has the most insight for this. > > ... > 2.) This is not necessarily a bad thing, but it is different > behavior. Is it sufficiently different to be a problem? > > and I would say that if I understand it correctly then it would definitely cause me a problem. The old behaviour, although it feels wrong, has been a bit of a godsend to me. Rexx\SQL can only work in the thread in which the library has been loaded. Therefore, where I want to access it in an oodialog method, I go through a rather hideous kludge of passing control to a method 'in' the original thread by programmaticaly editing a hidden edit control with a connecteditnotify watching it. Control & reports are two categries in a categorydialog subclass > *::method InitCategories > self~ConnectEditNotify(59,'UPDATE','PalmImportInv') > ... > ::method InitReports > -- this needs to go at the end of the last init method or we have trouble > with > -- guarded attribute in > OODIALOG > self~start(PalmScheduleChecks) /* set auto alert for palm inv > files */ > -- <do not place code here>-- > ... > ::method Control > self~addEntryLine( 59,'trigger',10, 10,175, 9,'hidden') > ... > ::method PalmScheduleChecks UnGuarded > trigger = self~getEditControl(59,1) > > /* regularly check for imports pending > ----------------------------------- */ > do forever > > do i=1 to 4 > if .st.state='quitting' then leave > call syssleep 0.5 /* sleep for 0.5 > secs */ > end /* DO */ > if .st.state='quitting' then leave > -- palmScheduleChecks is run in a seperate thread so RexxSQL wont work > -- in methods called from here. To get around this we use a hidden > -- entry line, which when changed triggers the import routines by way > -- of a connectEditNotify which means they run in the main thread > if .st.state='open' then trigger~setTitle(time()) --> > self~PalmImportInv > > end /* DO */ > > * I am fairly sure that I have passed this technique on to one or more people on the RexxLA list who have run up against the same difficulty with RexxSQL. I know that David is working on a RexxSQL replacement, which may behave differently. I can't think of any other way around this problem than through the loophole you are proposing to close. thanks, Jon
------------------------------------------------------------------------------
_______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
