On Sat, May 29, 2010 at 10:25 PM, Sahananda (Jon) Wolfers <sahana...@windhorse.biz> wrote: > > I can't offer you much on this, but you ask > > On 28 May 2010 17:24, Mark Miesfeld <miesf...@gmail.com> wrote: >> > ... >> >> 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.
Well, that's disheartening. My post wasn't really about the event handler methods running on a different thread than the main thread, it never occurred to me that people would write programs relying on that. (My other post has an example program that doesn't rely on it.) The post is really about the behavior when there was a syntax condition, or other condition raised in the event handler method. In 3.2.0, this would normally print out the condition information and cause the ooDialog program to end. Whereas in my current ooDialog, in trunk, it would print out the condition information and the dialog would continue to execute. What I was worried about was the difference in the program ending versus continuing to run. What's disheartening is that I've spent a lot of time and effort struggling to maintain backwards compatibility in ooDialog with what I want to do / to implement in an improved ooDialog. It seems that, that just isn't feasible. I'll probably post under a different subject heading to explore that further. -- Mark Miesfeld ------------------------------------------------------------------------------ _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
