Postoji li neko resenje za nasa latinicna slova (šđžčć) u tabelama? Koliko sam razumeo, moze se koristiti ftWideString za tip fielda, ali kako da to polje povezem sa napr. DBEditom?
Pretrazivajuci forum zakljucio sam da su, sto se nasih slova tice, Delphi VCL komponente najveci problem. Ne znam da li je nesto uradjeno po tom pitanju u Delphiju 2005? Trenutno koristim Delphi 7.
Cak kada u unicode tabele (MSSQL baza sa nchar poljima, nchar je unicode tip stringa, delphi ga implementira kao TWideStringField) upisemo nasa slova kodirana kao Unicode, db-aware komponente prikazuju ta slova bez akcenata
(znaci nas alfabet->engleski alfabet). Ocigledno DB-aware komponente u svojim internim metodima za iscrtavanje kontrola ne poshtuju unicode. Ili naci (ili napisati ili prepraviti) unicode-compliant DB komponente ili resenje br.2.
Resenje br. 2 bi bilo staviti charset fontova DB-aware kontrola na EasternEuropean svuda gde ce se nasa slova prikazivati (najbolje na celu formu i ParentFont=True), a sto se tice jezika samih tabela, za delphi uopste nije bitno jer Delphi (koliko ja znam) ne radi NIKAKVU konverziju karaktera, samo upisuje sirove bajtove u tabele, stringovi se u tabelu upisuju kao standardni ASCII stringovi, a kodna stranica obavlja posao prikazivanja nasih slova. Onda ti ne treba widestring polje u tabeli kada ce delphi tu da upise ASCII karaktere i "bole ga uvo" sto je to widestring polje.Ovo je OK kada ce samo tvoj program da koristi bazu, ali ako se povezujes na remote server sa npr. MSSQL bazom, onda ce prikazivanje nasih slova u drugim programima koji koriste tu bazu zavisiti od nacina na koji ti "drugi" programi prikazuju podatke. Alternativno, serverska funkcija koja ce karakteristicna slova (AE, ae, |, itd..) konvertovati u nasa unicode slova pri upisivanju i obrnuto pri citanju, mada ovo ne znam kako bi izveo a znam da moze... Samo i sa koriscenjem charseta ima problema (npr. combobox ciji je charset fonta eastern-european, u svome editorskom delu prikazuje nasa slova postujuci kodnu stranicu, ali item-i comboboxa i dalje prikazuju znake za nasa slova), onda se postavlja u cpanelu windowsa Serbian(latin) kao default za Non-unicode programe, ali OPET to pravi probleme u celom windowsu (pa i u texteditoru Delphi-a)...
Hvala na odgovoru _v!rus_.
Znam za Control panel i default vrednost za Non-unicode programe, ali to stvarno pravi razne gluposti u WinXP.
Sve kontrole su mi inace postavljene na EASTEUROPE_CHARSET i neke cak i odrade prikaz kako treba, napr. DBText i DBGrid prikazuju šđžčć kako treba, ali pravi problem je sa unosom jer napr. DBEdit šđžčć prosledi tabeli kao šdžcc.
Zaista, nije mi jasno kako ljudi kod nas uopste pisu Delphi DB-aware programe!?!?
To je to gubljenje akcenata o kome sam rekao ranije, (sem za "š" ,"ž" i veliko "Đ", jer ta slova postoje u western kodnoj stranici), ali to se javlja samo ako upisujes u WideString polje tabele. Prepravi polje na (ASCII) string u samoj tabeli, pa ponovo iscitaj polja da budu TStringField a ne TWideStringField. Samo da znas da unicode programi ce nepravilno prikazivati nasa slova jer ne koriste kodne stranice, ali ce unos iz dbedita raditi (provereno, upravo radim na takvom projektu). Npr. slovo "ć" ce biti zapisano u bazu kao "ae" (jedan znak), ali ce sve native delphi komponente kojima je charset EstEurp prikazivati pravilno (skoro sve, vidi moj prethodni post, combobox deo).
I jos ce ti mozda zatrebati ovo - da bi sa ovakvim nasim slovima (koja su u stvari znaci) radili Upper i LowerCase koristi AnsiUpperCase i AnsiLowerCase, jer "obicni" upper i lowercase menjaju charove samo u opsegu a..Z.
_v!rus_: E da, postoji i idotsko resenje koriscenjem nekih od YUxxx fontova, ali to nijedan programer ne bi trebao ozbiljnije da razmotri... ;-)
Apsolutno si u pravu!
Elem, evo kombinacije koja mi je zaista proradila kako treba: Tnt Data Controls + ftWideString tip polja. Sve radi savrseno na WinXP, treba samo postaviti kontrole na EASTEUROPE_CHARSET.
Samo pokusavam da pomognem