Re: [Oorexx-devel] Native API, call context, method context, ...
On Wed, Sep 2, 2009 at 2:59 PM, Rick McGuire wrote:
> Well, I'll answer the question you're actually asking, but then I'll
> give you a better option.
>
> One of the new additions to 4.0 was a sendWith() method, so you can use
>
> .FileNameDialog~sendWith("GET", arg(1, 'A'))
>
> will give ou what you want.
>
> However, there's another option. I suspect many of the untility
> routines you've written actually require a RexxThreadContext rather
> than a RexxMethodContext. Both the method context and the call
> context have an embedded thread context pointer. If your utility
> toutines don't require any of the methods that are unique to a method
> context, then you can pass the RexxThreadContext pointer instead to
> have common routines.
Aha. Great for both answers.
I should have known the second answer because I had asked a question
about why you used the RexxThreadContext pointer in some of the OLE
native functions before. It was for a different reason, but should
have been enough to give me a hint if I had been thinking.
--
Mark Miesfeld
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Native API, call context, method context, ...
Mark Miesfeld wrote: > Probably only Rick that can help on this, maybe someone else has some ideas. > > In ooDialog there are some documented external functions that need to > stay, because well they were documented. > > So, I started out to convert them to typed routines as part of my > effort to use .Pointer for things like window handles, etc. But, I > have a whole lot of infrastructure code that is expecting > RexxMethodContext *, instead of RexxCallContext *. > AFAIK, both context have a field "threadContext" which you can therefore retrieve and use (directly or as an argument), such that your routines can be commonly used. HTH, ---rony -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Native API, call context, method context, ...
Well, I'll answer the question you're actually asking, but then I'll
give you a better option.
One of the new additions to 4.0 was a sendWith() method, so you can use
.FileNameDialog~sendWith("GET", arg(1, 'A'))
will give ou what you want.
However, there's another option. I suspect many of the untility
routines you've written actually require a RexxThreadContext rather
than a RexxMethodContext. Both the method context and the call
context have an embedded thread context pointer. If your utility
toutines don't require any of the methods that are unique to a method
context, then you can pass the RexxThreadContext pointer instead to
have common routines.
Rick
On Wed, Sep 2, 2009 at 5:48 PM, Mark Miesfeld wrote:
> Probably only Rick that can help on this, maybe someone else has some ideas.
>
> In ooDialog there are some documented external functions that need to
> stay, because well they were documented.
>
> So, I started out to convert them to typed routines as part of my
> effort to use .Pointer for things like window handles, etc. But, I
> have a whole lot of infrastructure code that is expecting
> RexxMethodContext *, instead of RexxCallContext *.
>
> Rather than write a bunch of duplicate infrastructure code that that
> takes a call context pointer, I thought I would implement some of the
> public routines as a class method of a class and then in the routine
> just delagate to the class. Something like this:
>
> ::class 'FileNameDialog' public
> ::method get class external "LIBRARY oodialog fnDlg_get_cls"
> ...
> ::routine fileNameDialog public
> return .FileNameDialog~get(arg(1, 'A'))
>
> Well, Rick will probably see right away that that wouldn't work. I
> had to actually do it to see the problem. The fileNameDialog()
> routine has about 8 optional arguments and I thought sending the
> argument array to the ~get() method would give me the arguments.
>
> It doesn't of course, I just get one argument, an array.
>
> There are a number of fixes of course, I can just implement it as a
> typed routine and try to keep the duplicate code to a minimum.
>
> But, I'm wondering if there is any way in Rexx to get the argument
> array and send it on to the FileNameDialog~get()?
>
> Also, Rick has a RFE: Add CALL support to FORWARD I'm curious about
> that, but don't think it would help here anyway. I don't think it is
> support to forward from a routine to a method, or is it?
>
> --
> Mark Miesfeld
>
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Native API, call context, method context, ...
Probably only Rick that can help on this, maybe someone else has some ideas. In ooDialog there are some documented external functions that need to stay, because well they were documented. So, I started out to convert them to typed routines as part of my effort to use .Pointer for things like window handles, etc. But, I have a whole lot of infrastructure code that is expecting RexxMethodContext *, instead of RexxCallContext *. Rather than write a bunch of duplicate infrastructure code that that takes a call context pointer, I thought I would implement some of the public routines as a class method of a class and then in the routine just delagate to the class. Something like this: ::class 'FileNameDialog' public ::method get class external "LIBRARY oodialog fnDlg_get_cls" ... ::routine fileNameDialog public return .FileNameDialog~get(arg(1, 'A')) Well, Rick will probably see right away that that wouldn't work. I had to actually do it to see the problem. The fileNameDialog() routine has about 8 optional arguments and I thought sending the argument array to the ~get() method would give me the arguments. It doesn't of course, I just get one argument, an array. There are a number of fixes of course, I can just implement it as a typed routine and try to keep the duplicate code to a minimum. But, I'm wondering if there is any way in Rexx to get the argument array and send it on to the FileNameDialog~get()? Also, Rick has a RFE: Add CALL support to FORWARD I'm curious about that, but don't think it would help here anyway. I don't think it is support to forward from a routine to a method, or is it? -- Mark Miesfeld -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
