Polskie czcionki

[polymorphism]

sebaskow, do cholery, czy jesteś w stanie odpowiedzieć mi w końcu na pytanie, które 2x zadałem wcześniej, czyli:

Jak wyświetla Ci się tekst wprowadzony w ten sposób http://programowanie.cal.pl/forum/viewtopic.php?p=13275#p13275

[Cyfrowy Baron]

Twój kod polymorphism miałby znaczenie gdyby zmienna str była typu wchar_t, oczywiście takie dodawanie by nie zadziałało, ale chodzi o to, że począwszy od środowiska 2009, każdy łańcuch znaków jest traktowany jako UnicodeString, a nie AnsiString. Kompilator potraktowałby to jako AnsiString tylko gdyby zdefiniować ten typ, czyli:

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

AnsiString str;

str += "Zamknięcie raportu spowoduje stratę wszystkich nie wprowadzonych danych...\n\n";
str += "Czy chcesz zamknąć raport?\n\n";
str += "Wsiśnij TAK \tjeżeli chcesz zamknąć raport\n";
str += "Wciśnij NIE \tjeżeli jednak chcesz pozostać w trybie edycji\n";

[polymorphism]

Twój kod polymorphism miałby znaczenie gdyby zmienna str była typu wchar_t (...)

Nie do końca. Jeśli byłby to UnicodeString, nie dochodziłoby do konwersji ANSI unikod (zwróć uwagę, że dodaje tam literały unikodowe). Z kolei dla AnsiStringa konwersja unikod _(literał) ANSI _(kontrolki) byłaby dokonywana z uwzględnieniem aktualnego kodowania systemowego (w każdym razie tak zakładam). Czyli problem niezgodności stron kodowych ANSI powinien zniknąć.

[Cyfrowy Baron]

Tylko, że ja to już sprawdzałem, te literały są zbędne, gdyż jak wspomniałem, każdy łańcuch jest typu UnicodeString, co jest zresztą opisane gdzieś w plikach pomocy. A skoro String = UnicodeString, to literał niczego tutaj nie zmieni - tak sądzę.

[polymorphism]

No właśnie literał ma tu duże znaczenie, tzn strona kodowa tego literału. Jeśli literał poddajesz konwersji na unikod, to musisz uwzględnić jego stronę kodową. Zakładam, że w VCL-u domyślą stroną kodową przy tego typu konwersjach jest aktualna strona kodowa systemu, czyli w tym konkretnym przypadku inna niż ta, w której został skompilowany program. Stąd te problemy.

Zresztą ten sam problem masz w aplikacjach konsolowych. Konsola ciśnie w cp852, program domyślnie kompilowany jest w cp1250 i ta linia:

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

cout << "ęążźć\n";

nie wyświetli poprawnie znaków.

Rozwiązać można to na trzy sposoby:

1. przestawić kodowanie konsoli - nie takie proste.
2. skompilować aplikację w cp852 - niby ok, ale co jeśli konsola będzie w innym kodowaniu?
3. pisać w unikodzie
   
   KOD cpp:   �  UKRYJ  �

   KOD cpp:   �  POKAŻ  �

   wcout.imbue(locale(".OCP")); // <--- określam wyjściowe kodowanie - OEM, czyli kodowanie konsoli (windows only).
   
   wcout << L"ęążźć\n"; // <--- gdzieś na wyjściu strumienia nastąpi konwersja unikod --> OEM
    

[sebaskow]

sebaskow, do cholery, czy jesteś w stanie odpowiedzieć mi w końcu na pytanie, które 2x zadałem wcześniej, czyli:

Jak wyświetla Ci się tekst wprowadzony w ten sposób http://programowanie.cal.pl/forum/viewtopic.php?p=13275#p13275

Na tym komputerze gdzie był problem nie wyświetlało prawidłowo czcionek. Wciąż były krzaczki.

[polymorphism]

Hmm, dziwne. Może domyślna strona kodowa w VCL-u jest jednak na sztywno ustawiona, tzn. zgodnie z tą, w której kompilowany był program. No ale wtedy oznaczałoby to, że aplikacja korzysta z WinAPI w wersji ANSI.

Testowałeś to po przestawieniu mapowania _TCHAR na wchar_t?

[sebaskow]

Tak oczywiście. Nie mam już teraz okazji pokombinować, bo tak jak napisałem administrator porawił stronę kodową.
Ciekawe jest też to że nie mógł zainstalować drukarki sieciowej. Jak poprawił stronę kodową to i udało mu się zainstalować drukarkę.

Pozdrawiam

[sebaskow]

Szczegółów dotyczących tej drukarki nie znam, są to informacje które przekazali mi koledzy gdyż wówczas nie było mnie w pracy.