>>Hi Tore,
>>
>>Nifty program. Unfortunately it does not show that character in the character set.
>
>Well nothing will show a character which doesn't exist. In that character set.
>
>So you have several options:
>- go Unicode. Replace all controls with unicode capable ones. The almost perfect solution except it's too expensive (in man-hours) for one ś.
>- do that for just this one field and control. Almost manageable.
>- textbox.fontCharSet=238 (central european) and perhaps set keyboard layout to Polish in .gotfocus() (but I guess you'd be asking more questions if the app was to run in Poland). Set the field to binary (nocptran) so the s-acute doesn't get converted to s-bald.

Ah yes... fun with code pages... It gets more fun when you're dealing with double-byte character sets you're apt to run into with Asian languages like Chinese, Japanese and Korean (and each of which have several variants). Learned quickly to avoid having string constants containing characters in the 128-255 range (as this range is typically used as "lead-in" characters for double-byte character sequences). Have run into the occasional situation at customer site where not all PCs had the same configuration for non-Unicode programs.
I remember the fun of transferring data between the various computer systems with different display codes (e.g. ASCII, EBCDIC, CDC 6/12 ...) back when I was at university. Aside from worries regarding if characters existed on all systems, the occasional buggy translation table would cause problems.