Hi Oliver,
pardon me if I'm telling you something you already know.
It is probably not helpful to think of this as an inout parameter.
What is happening is that p in your example or r in Marks refers to an
object-instance. That object-instance has a life from the time that it is
instantiated until, no longer needed it is cleared away by the garbage
collection.
When you pass the object-instance to another object or method or routine,
which uses USE ARG to receive it, you are passing a reference, not a value
(which is what gets passed with PARSE ARG). So now, you have a variable
within the called routine which points to the object-instance, but the
variable in the caller routine still points to it too. They both point to
the self-same object-instance.
The called routine could pass control back with a reply statement, and then
you would have a concurrency situation, where both bits of code could
simultaneously send messages to the same object instance.
As it happens, in this case, there is no concurrency, so the calling code
sits and waits until the called code is finished, and then carries on.
I hope that that serves to clarify rather than confuse.
Jon
On 10 January 2012 17:40, Oliver Sims <[email protected]>wrote:
> **
> Mark,
> You said (and I had to laugh): According to who is the "usual" way? Then
> I thought, well, I can't think of any existing function or method in
> ooRexx where the returned value is to be found in a method parameter. But
> that may well indicate my incomplete knowledge of ooRexx - if so, please
> do let me know where inout params are used. I guess I've always thought
> that, with ooRexx, if you want to distinguish between a returned value
> and a return code, you have to arrange to return two things - which you
> can't - so then you cheat and return say a directory with two entries.
> Acutally having an inout parameter makes sense for that situation - which
> is exactly the situation for the MapWindowPoints (and presumably some
> other ooDialog APIs).
>
> For the Guide, if there are no examples of inout params in ooRex as
> shipped, I'll need to describe inouts as an ooDialog feature to handle
> situations where one needs to distinguish between values returned and
> return codes - which happens of course when one is hiding the programmer
> from an underlying piece of middleware that you can't change.
>
> Atb,
> Oliver
>
> ------------------------------
> *From:* Mark Miesfeld [mailto:[email protected]]
> *Sent:* 10 January 2012 14:59
> *To:* Open Object Rexx Developer Mailing List
> *Subject:* Re: [Oorexx-devel] ooDialog - inout param in
> method'mapWindowPoints'?
>
> On Tue, Jan 10, 2012 at 5:48 AM, Oliver Sims <
> [email protected]> wrote:
>
>> In Mark's userDlg.rex drag-drop sample program, there's a method
>> "mapWindowPoints".
>> The code is:
>>
>> say 'Mouse position before map:' p
>> self~mapWindowPoints(self~DlgB~hwnd, p)
>> say 'p after map:' p
>>
>> The parameter p is changed by the method implementation.
>>
>> The parameter 'p' is what Corba IDL calls an "inout" parameter - it serves
>> to provide data to the method and the method also uses it to return data
>> to
>> the caller. This is the first time I've seen this in Object Rexx. So I
>> wondered if it's intended to keep this behavior, or to change it so that
>> it
>> returns data in the usual way?
>>
>>
>
> It's intended to be this way. "returns data in the usual way" seems a
> little bit of a questionable statement to me. According to who is the
> "usual" way? <grin>
>
> This type of method, transforming some object, is common in the new
> methods I've introduced in ooDialog.
>
> In places where it is used, and mapWindowPoints() is a good example, the
> existing values of the object are not needed, it is the transformed values
> that are needed. There is no need to have 2 separate objects. In
> addition, it allows the method to return a success indicator for methods
> where the data returned does not have an obvious failure value. In this
> case it returns false on failure.
>
> --
> Mark Miesfeld
>
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> Oorexx-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
