Re: [Oorexx-devel] CMakeList.txt with rexx.img moved to the lib-directory (Re: A ...

2019-01-11 Thread Enrico Sorichetti via Oorexx-devel
Please do not do that …

The code used to retrieve the rexx.img location 

Is EXACTLY The same used to retrieve the rxapi location 

While where to put rexx.img can be debated to death
 
Rxapi is certainly an executable and it will be in the  bin-directory

And consistency of the terminology  and coding , in this particular case should 
have the priority

Thank You

E


> On 11 Jan 2019, at 08:45, Rony  wrote:
> 
>> moving rexx.img to the lib-directory at install time).

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel


Re: [Oorexx-devel] Rethinking error messages.

2019-01-11 Thread Rony G. Flatscher
Applied your commits and re-built MacOS and Linux standalone versions and my 
preliminary tests show
that this is working perfectly, *great job*!

---rony

P.S.: Cf. eg. 
.

On 09.01.2019 23:07, Rick McGuire wrote:
> The purpose of the rexx.cat  file is (in theory), that by 
> having separation
> between the executables and the error texts, we can easily translate the 
> error messages. In
> reality, there has never been any attempt at having multiple versions of the 
> messages, and I
> suspect we have really been misusing the catopen() mechanisms in a way that 
> would really prevent
> multiple languages from happening. The move toward the USB execution only 
> complicates this since
> we desire to pick up a specific rexx.cat  file rather than 
> using the DLPATH
> capabilities. 
>
> In addition, the Windows version makes no attempt at implementing NLS 
> support. The error messages
> are bound into the rexx dll as string resources. To do any sort of 
> translation, you need to
> rebuild the interpreter with a different .rc file. There is no switching.
>
> As I'm working on code to locate the specific .cat file, it occurred to be 
> that it would be a
> trivial matter to implement something like Windows uses and have an internal 
> message table rather
> than have this external artifact that needs to be located. 
>
> Rick

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel