Re: [Oorexx-devel] Question relating to native API and ooDialog

[Sahananda (J. W. <sah...@wi...>]

The more I think about this the less happy I become.

Rony's solution would also mean that all RDBMS interaction would have to go
through the daemon as it sits on the thread where the connections work, and
so that is not the main thread the interpreter uses.

I don't really understand how RxFuncAdd works.  Could one invoke a function
package multiple times from different threads.  Would that work?  Or perhaps
only where the package is thread safe (a term I have heard, but don't really
understand)?

Anyway, thank you both for your responses.

Jon

On 31 May 2010 12:19, Sahananda (Jon) Wolfers <sah...@wi...>wrote:

> Hi Mark,
>
> I've done a bit of experimenting and I'm sorry - I spoke too soon.  It
> would require a complete bottom up rework to make the executeasynch method
> work for me, as the dialog then runs in a seperate thread from the main body
> of code.
>
> This is not your problem, but I will explain.
>
> I have a library of common routines which establishes the environment for
> my scripts, establishes the connection with the RDBMS and makes use of that
> connection to provide various services.
>
> I then have a number of scripts, all of them dialogs which ::require that
> library.
>
> These dialogs are started with execute and make use of the established
> connection to the database.
>
> Only in one case, do I need while the dialog is active, for it to watch for
> files appearing and act on them when they do, so I run asynchronous methods
> within that dialog to initiate a regular watch for files & then kick off the
> processing of those files when they appear.
>
> Using execute to launch the dialogs, the dialog is run in (or is it on) the
> same thread that the connection was established with in the required common
> library.
>
> If I was to switch to executeasync I could then manage to make the
> connection for that one problem case, but would lose the connection for the
> many other interactions with the rdbms.
>
> What I would ideally like is the ability to interact with the database, no
> matter what thread I am running on, and perhaps Davids work will provide
> this.
>
> Until then, I think the simplest way for me to go would be to provide a
> daemon as Rony suggests and let it handle the interaction, but it is sad to
> need that extra layer of complexity.
>
> thanks,
>
> Jon
>
>
>
> On 31 May 2010 11:04, Sahananda (Jon) Wolfers <sah...@wi...>wrote:
>
>> Hi Mark,
>>
>> first of all, thank you to you and Rony for your examples and
>> workarounds.
>>
>> I had just returned from a month away to a mountain of emails and was in a
>> sort of despatch them quickly without thinking about them enough mode.
>>
>> Both methods look really good.  I tend to code down grooves and I have
>> used executeasynch in my code, but tended to think of it as only useful for
>> splash screen type dialogs.  You have opened up my mind a little and now
>> that I see it it is obvious.  As usual, you have put a lot of work into the
>> example, for which I thank you.
>>
>> As far as backwards compatibility goes, it looks to me like I did
>> something rather unorthadox here, and had I coded it sensibly it would work
>> on 4.0.0.  I'm not sure now who received advice from me on this, but I guess
>> the same thing stands there, they have used the mechanism in a way that was
>> not intended.  It seems to me the onus is on us to rework our code to comply
>> with intended usage of the tools.
>>
>> thank you for your help,
>>
>> Jon
>>
>>
>>
>> On 30 May 2010 17:23, Mark Miesfeld <mie...@gm...> wrote:
>>
>>> On Sat, May 29, 2010 at 10:25 PM, Sahananda (Jon) Wolfers
>>> <sah...@wi...> wrote:
>>> >
>>> > I can't offer you much on this, but you ask
>>> >
>>> > On 28 May 2010 17:24, Mark Miesfeld <mie...@gm...> 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
>>> Oor...@li...
>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>>
>>
>>
>