I am using tcl 8.3.3 and tclodbc (winNT and Win2k). I am filling an
entry field with data form an odbc-connection. I change the data and
write it back to my database. Everything works perfect but I am not
able to see the Euro-Symbol in my EntryField. (It shows a tiny ugly
rectangle). Even inserting an Euro-Symbol with AltGr-E works fine to
the database but again not shown in the EntryField. The font I am
using has an Euro-Symbol (I tried Arial and Courier New). Wrting an
Euro-Symbol in Notepad and copy-paste it to the entry field does show
an Euro-Symbol but a "?" is written to the database.
Any hints?
Alex
iso8859-15, I think is the encoding that has it.
--
David Gravereaux <davy...@pobox.com>
Tomasoft Engineering, Hayward, CA
[species: human; planet: earth,milkyway,alpha sector]
Please be aware of the 7.5 year ping times when placing a call from alpha centari
What is displayed if you use the value "\u20ac"
i.e.
label .l -text "Symbol \"\u20ac\""
pack .l
I get the Euro sign :-)
George
Yes I get a wonderfull Euro-Sign.
But - If I read a file or getting Data from odbc - I never get the
symbol. (No matter wich encoding I use for the Channel)
ie: (C:/euro.txt is a file with an Euro-Symbol in it)
set all ""
foreach encoding [encoding names] {
set fileID [open c:/euro.txt r ]
fconfigure $fileID -encoding $encoding
while {[gets $fileID line] >= 0} {
set all $all$line\n
}
close $fileID
}
label .l -text $all
pack .l
Should I process the string in any way before displayed?
Something somewhere isn't working quite right. However, it is quite
possibly not Tcl. Let me explain...
There is no Euro sign in the charset encoding known as ISO8859-1. It
post-dates it by a good few years. If your database data is written
as ISO8859-1, then it cannot (correctly) contain a Euro sign (though
you could convert it to the universal currency symbol for storage,
which would probably be good enough for you.)
set stringToStore [string map "\u20ac \u00a4" $stringToConvert]
The only two charsets (I know of) that contain the Euro symbol are
UNICODE and ISO8859-15. Tcl uses UNICODE internally (UTF is a variant
of UNICODE.) If you really want your DB to store it, you have to make
sure that all software that accesses the DB knows what the encoding is
(or doesn't care; this is the case more often than not.)
What is the encoding of the strings in that database?
I don't know why AltGR-E did not insert a Euro into the entry; that
might actually be a bug in Tk (which is not as thoroughly i18ned because
GUIs are a lot more difficult to get right) though it was pleasing that
cut-n-paste got it right. (I can't test it on this platform at all. :^)
Donal.
--
-- Itanium-based servers combined with Microsoft's latest server software
offer customers superior performance, greater choice, reliability and
investment protection at significantly lower costs than proprietary
solutions. -- Abhi Talwalkar (Intel VP)
George
:Any hints?
The only hint I can give you is that it sounds obvious to me that the
font being used for that entry field has a different encoding than is
being used for the output to your database. Somehow you need to find
out what these two encodings are and then get them into 'sync'.
--
--
"I know of vanishingly few people ... who choose to use ksh." "I'm a minority!"
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting
On my keyboard, it's next to the (for some reason unfunctional) Compose key
and inserts a universal currency symbol instead. Helpful...
Donal.
: I am using tcl 8.3.3 and tclodbc (winNT and Win2k). I am filling an
: entry field with data form an odbc-connection. I change the data and
You should bear in mind that Microsoft NEVER users ISO standard
encodings. Try to change from ISO Latin-1 to CP1252.
--
Win95 is not a virus; a virus does something.
-- unknown source
Well, I don't know what Mucrosoft[*] are up to there, but according to
the definitive documentation on http://www.unicode.org/ \u0080 is a non-
printing character. ("Embrace and Extend" would be better known as "We
are Mucrosoft of Borg...") At least it is easy to bodge a fix (the
correct way is to make the data in the DB correct, but that is probably
going to be a lot of work.)
# One way (making real euros)...
set fixedData [string map "\u0080 \u20ac" $dataFromDB]
# ...and the other (making false euros).
set dataToDB [string map "\u20ac \u0080" $dataWithRealEuroSign]
And make sure that you note in the documentation to go with the database
(the data, not the software) that this transformation is being done or
the poor soul that comes along to try and port it in a few years will be
up the creek without a paddle... :^)
Donal.
[* Heh! I like that typo. ]
--
Donal K. Fellows (at home)
--
FOOLED you! Absorb EGO SHATTERING impulse rays, polyester poltroon!!
(WARNING: There is precisely one error in this message.)
Only if Unicode was put in. Remember the GIGO principle.
> I switched down to simple FileIO with various encoding settings.
> But most of the time I get Hex80 and not Hex20AC (I get some other
> values but never,never 20ac) Looking at
> http://www.microsoft.com/truetype/unicode/1252.htm shows a table
> where both 80 an 20AC are listed and I dont know if this could help...
OK, the DB doesn't actually contain Unicode, but actually CP1252 (which
is the standard single-byte encoding for western european languages under
Windows, and unknown anywhere else.) You can fix this (assuming you're
using a recent-enough version of Tcl) by using [encoding convertfrom]
and [encoding convertto] (depending on which direction you're going.)
set dataToDB [encoding convertto cp1252 $standardTclString]
set string [encoding convertfrom cp1252 $dataFromDB]
(Alas, it seems that only 8.4a3 of the distributed versions is actually
recent enough. Even 8.3.3 is wrong...)
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- A large ASCII art .sig is the Usenet equivalent of walking around in
public with your asscrack sticking out past the top of your sweatpants.
You be the judge. -- Mike Hoye <mh...@prince.carleton.ca>