4. CString Find mit 'x' oder "x"?

CString Find mit 'x' oder "x"?

  • S

    Hallo
    ich beziehe mich auf ein übergeordnetes Problem:
    http://www.c-plusplus.net/forum/viewtopic-var-p-is-968665.html#968665

    In meinem Code verwende ich die Findmethode der CString-Klasse.

    CString s;
s.Find('x');

    allerdings schreibe ich auch bei einzelnen Characters die Übergabe so:

    s.Find("x");

    kann das möglicherweise falsch sein?

    PS: Ja ich hab die MSDN dazu gelesen, doch ich kenne den Unterscied zuwenig bei den div. Parameter-übergabe-typen.

    0
  • E

    Laut MSDN ist es egal, es geht beides.

    int Find( TCHAR ch ) const;
    int Find( LPCTSTR lpszSub ) const;

    Ich habe da auch noch keine Unterschiede feststellen können.

    Wegen Unicode: Mach lieber _T() um JEDE Zeichenkette.
    Also:

    s.Find(_T('x'));
s.Find(_T("x"));

    🙂

    0
  • ?

    Die zweite Variante kann auch längere Zeichenketten finden, aber für deine Anwendung dürften sie das selbe Ergebnis liefern (bzw. find(char) ruft üblicherweise find(char*) auf).

    0
  • S

    estartu schrieb:

    Laut MSDN ist es egal, es geht beides.

    int Find( TCHAR ch ) const;
    int Find( LPCTSTR lpszSub ) const;

    Ich habe da auch noch keine Unterschiede feststellen können.

    Wegen Unicode: Mach lieber _T() um JEDE Zeichenkette.
    Also:

    s.Find(_T('x'));
s.Find(_T("x"));

    🙂

    Ich glaube ich habe gerade ein Unicode Problem entdeckt 😞
    Meine geschriebene Applikation wird in Japan verwendet und die meinen, dass sie meine Dateien nicht richtig öffnen können. Na toll!!!
    wie weiter? überall ein <_T(...)> reinmachen? Auch bei der Verwendung von Strings?
    also so etwa?:

    CString s = _T("hello");

// oder so:
CStriing ss = "world";

CString str = s + _T(ss);

    Ohh mann ich bin am Ende!

    0
  • ?

    sky21 schrieb:

    wie weiter? überall ein <_T(...)> reinmachen? Auch bei der Verwendung von Strings?

    Nein, nur beim Verwenden von Zeichen- und Stringliteralen.

    0
  • S

    CStoll (off) schrieb:

    sky21 schrieb:

    wie weiter? überall ein <_T(...)> reinmachen? Auch bei der Verwendung von Strings?

    Nein, nur beim Verwenden von Zeichen- und Stringliteralen.

    Du meinst also, überall wo ich ein...

    CString str;
 str.Find("this");
 //or
 str.Find('x');

    habe, kann ich diese mit...

    CString str;
 str.Find(_T("this"));
 //or
 str.Find(_T('x'));

    ersetzen und es geht?

    Nicht zu vergessen, dass meine Applikation auch das Öffnen und Speichern. Das ist damit auch gelöst?

    gibt es eine Möglichkeit, eine Testumgebung aufzusetzen und das zu testen? Es sind eben Kunden von uns und die will ich jetzt echt nicht mit X testversionen beglücken.

    Thanks so much for your help!!

    0
  • E

    Also, ich habe außer dem _T auch keine Ahnung von Unicode. 😞
    Aber ganz unten in diesem Artikel steht, wie man eine Anwendung unicode-tauglich macht.
    Das sollte dich etwas weiter bringen.

    Und dann wäre wohl am optimalsten mal ein PC mit japanischem Windows.
    Keine Angst, das kann man erstaunlich gut bedienen ohne ein Wort lesen zu können - ist immer noch Windows. 😉
    (Ich hab mal ein taiwanesisches Notebook getestet, da hatte ich auch blos Bildchen.)

    0
  • S

    estartu schrieb:

    Also, ich habe außer dem _T auch keine Ahnung von Unicode. 😞

    Kannst du mir das nochmals erklären, auch wenn du sagst, du hättest keine Ahnung? 🤡
    _T *muss* man zusammen mit #define _UNICODE verwenden oder?

    ich schnall den MSDN-Text dazu echt nicht. Dabei steht doch bei _T, dass es 'no effect' hat. Na wozu denn trotzdem verwenden?

    0
  • E

    Naja, ich verwende das aus dem einfachen Grund, dass mir ein Kollege mal folgendes sagte:

    Bau das ein, dann hast du später kein Problem, falls der Code unicodetauglich werden muss.

    Seitdem mache ich da aus purer Gewohnheit. Es kostet mich Überwindung, eine Zeichenkette ohne _T("") zu tippen. 🙄

    Was Unicode angeht, häng dich besser an Marc++us, der hatte das schon mal wo erklärt, ich weiß nur grade nicht wo. 😞

    0
  • P

    Kannst du mal den Link zu der Seite posten, die du nicht ganz verstehst?
    Denn bei der MSDN findet man mehr zu UNICODE.

    0
  • E

    Ich kopier dir das mal rein, das ist aus der Diskussion zu dem Artikel, den ich dir gesagt hatte:

    Marc++us schrieb:

    estartu_de schrieb:

    Was braucht man, damit man Unicode ausprobieren kann?
    Ich habs noch nicht gebraucht und mich deswegen noch nie weiter damit beschäftigt.

    Windows mit NT-Kernel oder Linux. 🙂

    Alle Wins mit NT-Kernel (NT, 2k, xp) basieren automatisch auf Unicode, intern werden alle Zeichenketten der API-Funktionen in Unicode verarbeitet.

    Für jede API-Funktion, die einen String-Parameter besitzt, gibt's im Kernel zwei Aufrufe, einmal einen SomeThingA und SomeThingW. Die beiden Funktionen unterscheiden sich dadurch, daß SomeThingA zuerst die Strings nach Unicode konvertiert, und dann SomeThingW aufruft. Auf der Eben der WinAPI-Programmierung siehst Du davon nix, weil Du immer SomeThing aufrufst, aber das ist Fake - diese Funktion gibt's gar nicht, das ist in Wirklichkeit nur ein Makro, das je nach Compilersetting SomeThing auf SomeThingA oder SomeThingW abbildet.

    Win9x haben nur einige wenige Unicode-Funktionen, unter anderem für die MessageBox, damit eine Unicode-Anwendung auf w9x sagen kann "ich funktioniere hier nicht".

    Das hilft dir zwar zum _T nicht, aber ich finde die Erklärung allgemein sehr hilfreich. 🙂
    (Und jetzt wo ich sie doch schon rausgesucht hatte...)

    0
  • S

    Paul_C. schrieb:

    Kannst du mal den Link zu der Seite posten, die du nicht ganz verstehst?
    Denn bei der MSDN findet man mehr zu UNICODE.

    http://msdn2.microsoft.com/en-us/library/7dzey6h6.aspx

    okok. ich glaub nach dem 1000x mal lesen versteh ichs langsam

    _T wird nur berücksichtigt, falls auch _UNICODE im Code definiert ist.

    Na toll, wenn ich _UNICODE definiere, hab ich nur ca. 580 Fehler 😞
    Na dann gute Nacht 🕶

    0
  • C

    Kurzfassung zu UNICODE:
    Wenn UNICODE definiert ist, werden die MFC-Zeichen- und String-Klassen anders behandelt - sie arbeiten nämlich auf der Basis von TCHAR (normal = char, unter UNICODE = wchar_t). Deshalb müssen String-Literale unterschiedlich gehandhabt werden - ein char*-Literal wird als "Hallo" geschrieben, ein wchar_t*-Literal als L"Hallo". Probleme bekommst du erst, wenn du beide einanger zuordnen willst (z.B. weil du TCHAR und char mischst).

    (und der Ausdruck _T("Hallo") wird je nach Umgebung in "Hallo" oder L"Hallo" übersetzt)

    0
  • S

    CStoll schrieb:

    Kurzfassung zu UNICODE:
    Wenn UNICODE definiert ist, werden die MFC-Zeichen- und String-Klassen anders behandelt - sie arbeiten nämlich auf der Basis von TCHAR (normal = char, unter UNICODE = wchar_t).

    Ohne dass ich mein Programm für UNICODE compiliere, kann ich ja z.b. wchar_t direkt werwenden oder?

    Kannst du mir hier anhand eines Beispiels erklären, wie ich das Zeichen mit dem Datenwer 0xE9 in eine UNICODE-Variable packe (also in wchar_t vermutlich) und dann auf dem Bildschirm ausgeben kann?

    0
  • J

    sky21 schrieb:

    Ohne dass ich mein Programm für UNICODE compiliere, kann ich ja z.b. wchar_t direkt werwenden oder?

    Ja.

    sky21 schrieb:

    Kannst du mir hier anhand eines Beispiels erklären, wie ich das Zeichen mit dem Datenwer 0xE9 in eine UNICODE-Variable packe (also in wchar_t vermutlich) und dann auf dem Bildschirm ausgeben kann?

    Was soll den 0xE9 sein? Meinst Du "LATIN SMALL LETTER E WITH ACUTE":
    http://www.fileformat.info/info/unicode/char/00E9/index.htm
    ?

    einfach so:

    wchar_t e = 0x00E9;

    Oder so:

    wchar_t str[] = L"H" L"\xE9" L"llo world!";
    0
  • S

    merci.
    die zuweisung ist simpel.
    was ich aber nicht weiss, ist, wie kann ich dieses zeichen dann richtig umwandeln bzw. ausgeben?

    // ja genau, ich will das 'e mit acute' ausgeben. und zwar soll es überall darstellbar sein, egal auf welcher windows-sprachversion das programm ausgeführt wird.

    wchar_t chr = 0xE9;
AfxMessageBox(chr); // geht ja leider so nicht :-)

    der Wert 0xE9 (233) darf eben nicht als extenden-ASCII code interpretiert werden, da je nach eingestellter codepage das 8.ASCII-Bit unterschiedlich interpretiert wird.

    Also muss ich doch diesen ASCII-Bytewert 0xE9 der hier <im westen> mit codepage <Latin-1 (bzw. 1252)> in unicode umwandeln und so darstellen. Denn dann wird scheinbar die lokal eingestellte codepage ignoriert (hoffentlich).

    0
  • J
     

    wchar_t str[] = L"H" L"\xE9" L"llo world!"; 
  ::MessageBoxW(this->GetSafeHwnd(), str, L"Caption", MB_OK);

    Wenn Du Dein MFC-Programm mit UNICODE übersetzt, dann geht es eigentlich scon immer...

    0
  • S

    Jochen Kalmbach schrieb:

    wchar_t str[] = L"H" L"\xE9" L"llo world!"; 
  ::MessageBoxW(this->GetSafeHwnd(), str, L"Caption", MB_OK);

    Wenn Du Dein MFC-Programm mit UNICODE übersetzt, dann geht es eigentlich scon immer...

    Ich kann es aber nich mit ... #define _UNICODE nicht kompilieren. Daher meine etwas doofe frage, ob es eben doch geht!

    0
  • J

    So wie ich es gezeigt habe geht es auch ohne _UNICODE!

    0
  • S

    Jochen Kalmbach schrieb:

    So wie ich es gezeigt habe geht es auch ohne _UNICODE!

    du hast vollkommen recht.
    Lustigerweise hab ich das Beispiel mit einem Englischen VC++ 6.0 gemacht mit Japanischen Regionaleinstellungen. Da meckert der Compiler ständig "C2002 unvalid wide-character constant". 👎

    hingegeben auf meinen hauptrechner mit dt. VC++ 6 läufts 👍

    tippfehler? hmm wohl kaum. Aber sicher ist sicher. ich kopiere mal quellcode und gleich das exe auf den anderen PC...

    EDIT:
    Wenn ich den INhalt nun anstatt in einer MessageBoxW() lieber in ein Label (static element) oder sonst einem control ausgeben will, dann könnte ich ja den MEthodenaufruf analog mit FunctionW machen oder? aber das geht wohl nicht so einfach:

    wchar_t str[] = L"H" L"\xE9" L"llo world!"; 
  ::MessageBoxW(this->GetSafeHwnd(), str, L"Caption", MB_OK);

  MessageBoxW(NULL, str, L"Cap", MB_OK); // ausgabe geht

  m_La.SetWindowTextW( str );
// geht nicht:
// compiler error: 
// C2039: 'SetWindowTextW' : Ist kein Element von 'CStatic'

    ahh mannnnn, ich glaub ich hab ein c++ freies wochenende nötig.

    0
Anmelden zum Antworten