Trevor Davis wrote:

> Here is a Word document with some Greek text for testing, sent to me
> by the client:  www.dbsonline.com/greek.zip

Hi Trevor

It is not quite lunch time yet!

Part of your problem is that the .docx contains Unicode and I think
when you paste that into your ANSI table it does not know how to
re-encode it.
I saw exactly the same.

But, having created a table with Greek code page (Windows XP set for
Greece *including* the Advanced option of Language to match the
non-Unicode programs), the following worked in DBSys:

1.  Open test table
2.  Use Windows Character Map in Advanced view with Character set =
Windows: Greek, to select a few Greek characters
3.  Copy the text and Paste into table field, then Save.
4.  Close table and re-open it.   Wow, still Greek!
5.  Alter table back to Locale = ANSI Standard.
6.  Open table - still Greek!
7.  Add new record with more Greek pasted from Character Map - still
works!
8.  Change Windows back to English(UK) for non-Unicode programs and to
English input/format
9.  Reboot, Open table to see characters (not ???), but not Greek ones
(actually the Western European ANSI chars)

So I think it is possible, provided:
 * the Windows non-Unicode language is set correctly.
 * the text is input using a greek keyboard or from some other ANSI
source (in my case Character Map).

Have loads of fun investigating this .. and thinking about when to move
on to Uniocade.  <bg>

Trevor,

<< With Delphi XE5 (DBISAM 4.37) copy/paste was OK, but just moving to the
next field caused the text to change to ???G?? >.

With XE5, the controls, etc. all use Unicode strings, and DBISAM relies on
the current system locale/code page for converting any Unicode characters to
ANSI before they get assigned to a field in the table (this happens at the
TField level in DB.pas).  The locale in the table is *solely* for use in
comparisons and sorting and does not affect this.

So, if you're not seeing the proper text in an XE5 application, then that
means that the system locale/code page is not set properly.

Tim Young
Elevate Software
www.elevatesoft.com

Thank you very very much Malcolm!

"Language for non-Unicode programs" does the trick. Greek characters from the
character map worked and I was even able to cut and paste Greek text from the
Word document.

It worked with tables created prior to setting Windows for Greek, and after.
Whether the table Locale was Greek or not (as you found).

I tested with the other Windows Regional and Language options set to Greek as
well: "Standards and formats", Location, Languages | "Default input language",
which worked. And then tested again with my regular Canadian settings for
those, but keeping "Language for non-Unicode programs" set to Greek. And both
times it worked. "Language for non-Unicode programs" was what made it work.
That's what I was missing. Thank you so much.

--
Trevor Davis
Davis Software
www.dbsonline.com


"Malcolm" <malcolm@spam.will.bounce> wrote in message
news:D7A55A1B-70E6-4510-810C-01F9511CFE0C@news.elevatesoft.com...
> Trevor Davis wrote:
>
>> Here is a Word document with some Greek text for testing, sent to me
>> by the client:  www.dbsonline.com/greek.zip
>
> Hi Trevor
>
> It is not quite lunch time yet!
>
> Part of your problem is that the .docx contains Unicode and I think
> when you paste that into your ANSI table it does not know how to
> re-encode it.
> I saw exactly the same.
>
> But, having created a table with Greek code page (Windows XP set for
> Greece *including* the Advanced option of Language to match the
> non-Unicode programs), the following worked in DBSys:
>
> 1.  Open test table
> 2.  Use Windows Character Map in Advanced view with Character set =
> Windows: Greek, to select a few Greek characters
> 3.  Copy the text and Paste into table field, then Save.
> 4.  Close table and re-open it.   Wow, still Greek!
> 5.  Alter table back to Locale = ANSI Standard.
> 6.  Open table - still Greek!
> 7.  Add new record with more Greek pasted from Character Map - still
> works!
> 8.  Change Windows back to English(UK) for non-Unicode programs and to
> English input/format
> 9.  Reboot, Open table to see characters (not ???), but not Greek ones
> (actually the Western European ANSI chars)
>
> So I think it is possible, provided:
>  * the Windows non-Unicode language is set correctly.
>  * the text is input using a greek keyboard or from some other ANSI
> source (in my case Character Map).
>
> Have loads of fun investigating this .. and thinking about when to move
> on to Uniocade.  <bg>

Thanks Tim,

Setting the Windows Regional option "Language for non-Unicode programs" fixed
it. I only tested again with Delphi 7 but probably a safe bet it would be fine
for XE5 too.


> The locale in the table is *solely* for use in comparisons and sorting and
> does not affect this.

Comparisons and sorting would be nice to have working properly too.

When I create a new table programmatically (CreateTable with FieldDefs and
IndexDefs), the Locale is ANSI Standard regardless of whether the Windows
Regional options are Greek or not. (Using DBISAM 4.26). Is there a way to set
the Locale programmatically?

--
Trevor Davis
Davis Software
www.dbsonline.com


"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:BE4F8120-FB32-4F65-9353-76DD653A7303@news.elevatesoft.com...
> Trevor,
>
> << With Delphi XE5 (DBISAM 4.37) copy/paste was OK, but just moving to the
> next field caused the text to change to ???G?? >.
>
> With XE5, the controls, etc. all use Unicode strings, and DBISAM relies on
> the current system locale/code page for converting any Unicode characters to
> ANSI before they get assigned to a field in the table (this happens at the
> TField level in DB.pas).  The locale in the table is *solely* for use in
> comparisons and sorting and does not affect this.
>
> So, if you're not seeing the proper text in an XE5 application, then that
> means that the system locale/code page is not set properly.
>
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>
>