Hi Qatan,
>> ANSI and OEM are totally confusing Microsoft (Windows-specific) terms so we
>> stay out of using them in Harbour.
>> We already support both, but with other names. "ANSI" is usually "??WIN",
>> and "OEM" is usually "??85n".
>>
>> Viktor
>
> Are not "??ISO" and "??WIN" the same
Hello Viktor,
ANSI and OEM are totally confusing Microsoft
(Windows-specific) terms so we stay out of
using them in Harbour.
We already support both, but with other names.
"ANSI" is usually "??WIN", and "OEM" is usually
"??85n".
Viktor
Are not "??ISO" and "??WIN" the same thing?
T
I don't see why such complication is necessary,
or what do you really want to do. If you need
"ANSI" codepage, why don't you use PTISO, or
it's also possible to add a PTWIN codepage if
you (or anybody else) can provide one.
Waw! This is great news for me! ??ISO cp is more than enough to my needs
>> The problem is probably in your display or output
>> settings.
>>
>> Viktor
>
> Thank you Viktor!
>
> I got confused because I used an ANSI editor to write the PRG code when the
> codepage table code is written in OEM.
Yes, the codepage you chose is CP850, which
means "OEM" in Microsoft-sp
This is impossible to tell when pasted to an e-mail.
Anyhow I've checked it locally directly in the source
and to me the PT850 looks alright.
Try to open src/codepage/cppt850.c with an editor
which you can set to 850 CP, or your browser. Or
do the same with above test after your write the
result
Hi Leandro,
>> These are internal structures, so there if is any notion
>> of writing stable code I strongly suggest to not use
>> them directly at all.
>
>> I think the bug here is that you can access these members
>> at all. IMO they should be protected like HB_ITEM members.
>>
>
> You must b
Nothing missing nor bug. UPPER(CHR(0)) ir CHR(0), and CHR(0) is end of
string symbol.
Sorry Mindaugas, but I couldn't understand what you mean. Can you give me a
hand please? :)
Leandro
___
Harbour mailing list (attachment size limit: 40KB)
Harbour
Hi Viktor
These are internal structures, so there if is any notion
of writing stable code I strongly suggest to not use
them directly at all.
I think the bug here is that you can access these members
at all. IMO they should be protected like HB_ITEM members.
You must be right. The .C code
> HB_FUNC( _2D_CURRENTCODEPAGE )
> {
>const char * cdpID = hb_cdpID();
>PHB_CODEPAGE cdp = hb_cdpFind(cdpID);
>
>MessageBox(NULL,cdp->lower,'test',MB_OK);
>
>hb_reta(4) ;
>hb_storvc( cdp->lower, -1, 1 );
>hb_storvc( cdp->upper , -1, 2 );
>hb_storvc( cdpID , -
Hi,
We have also debuged the cdp->lower and cdp->upper members and they are
empty, so it is not a matter of hb_storvc usage.
Can somebody check if we are missing something or if it is a harbour bug?
Nothing missing nor bug. UPPER(CHR(0)) ir CHR(0), and CHR(0) is end of
string symbol.
Regar
Hello,
See code below:
HB_FUNC( _2D_CURRENTCODEPAGE )
{
const char * cdpID = hb_cdpID();
PHB_CODEPAGE cdp = hb_cdpFind(cdpID);
MessageBox(NULL,cdp->lower,'test',MB_OK);
hb_reta(4) ;
hb_storvc( cdp->lower, -1, 1 );
hb_storvc( cdp->upper , -1, 2 );
hb_storvc( cdpID
11 matches
Mail list logo
