Mark,
An API for this makes a lot os sense. I'll take a look at adding one this
week. All of the pieces are there already, so this should not be
difficult. I realized last night that there's probably a problem with
command return codes introduced with this change also. The Rexx syntax
error is no longer getting passed back.
Rick
On Saturday, March 17, 2012, Mark Miesfeld <[email protected]> wrote:
> Committed revision 7686.
>
> I put in a temporary fix using some of my code from ooDialog. It is
meant to be just that, a temporary fix.
>
> It is Windows only, and rexx.exe only. I figure we can discuss what a
final solution should be here on the list. In the mean time, I can build
from trunk and still have things work.
>
> One solution might be to add an API to the ThreadContext stubs that
printed out to the console the normal error messages and trace back. The
code could then look something like:
>
>
> result = pgmThrdInst->CallProgram(program_name, rxargs);
> if ( pgmThrdInst->CheckCondition() )
> {
> pgmThrdInst->DisplayCondition();
> }
>
> That is essentially what the code I added does, but I'm not sure if I
include everything the interpreter does. Having an API seems like it would
be easier for users of the native API, rather than make every developer
roll their own.
>
> The other solution, if the code I added is adequate, would be to put it
in a common module that could be compiled in to the unix rexx and the
Windows rexxpaws. Not really needed for rexxhide since there is no console
to print the messages to any way.
>
> --
> Mark Miesfeld
>
> On Sat, Mar 17, 2012 at 3:12 PM, Mark Miesfeld <[email protected]> wrote:
>>
>> Well, I see that the problem does come from using
RexxCreateInterpreter() instead of RexxStart().
>>
>> And I don't see a quick easy solution.
>>
>> --
>> Mark Miesfeld
>>
>> On Sat, Mar 17, 2012 at 2:34 PM, Mark Miesfeld <[email protected]>
wrote:
>>>
>>> Hi Rick,
>>>
>>> (I was going to open a bug so you could look at this later, but then
towards the end, I realized what might be the problem, so I just took the
bug text and pasted it in here.)
>>>
>>> Can you take a look at this when you're back home and have some time.
Raised conditions are no longer being printed to the console. Take a
simple example:
>>>
>>> say 'in Rexx'
>>> rock~put()
>>>
>>> Normally you would expect:
>>>
>>> C:\work.ooRexx>qt.rex
>>> in Rexx
>>> 4 *-* rock~put()
>>> Error 97 running C:\work.ooRexx\qt.rex line 4: Object method not fo
>>> und
>>> Error 97.1: Object "ROCK" does not understand message "PUT"
>>>
>>> But in trunk you get:
>>>
>>> C:\work.ooRexx>qt.rex
>>> in Rexx
>>>
>>> C:\work.ooRexx>
>>>
>>> I looked at it in the debugger and I can see the condition object
getting filled in with all the correct information. And in a more complex
example I can see the condition being propagated up. But nothing prints.
>>>
>>> While writing this, I realized - is this a result of using
RexxCreateInterpreter() instead of RexxStart()? Probably.
>>>
>>> Is there an easy way to get the normal error messages printed to the
console?
>>>
>>> --
>>> Mark Miesfeld
>
>
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
