CreateWindow, Parameter 1 und 2 typecasten???

CodeFinder

Mal BTW: Also ich bevorzuge statt _T(exp) immer TEXT(exp), aber dat is wohl Ansichtsache .

*D*Evil

Nope ist es nicht. Wenn du keine tchar includierst nimmst du TEXT. Andernfalls _T

CodeFinder

lol aber wenne windows.h inkludierst, inkludierste autom. tchar.h , also kann man auch TEXT nehemen^^

*D*Evil

Wäre mir ehrlichgesagt neu... VC2003 includiert bei nem WinAPI Programm(vom Assist erstellt) auch immer die tchar EXTRA hinzu...

CodeFinder

Hm ok, dann vllt n Missverständnis...:

#include <Windows.h>

TCHAR szIrgWas[] = TEXT("blablabla");

Also das da oben geht, ohne Tchar.h

D*3ce

Hm, danke für die Tipps, workt nun einwandfrei!

groovemaster

(D)Evil schrieb:

// Unicode
CreateWindow(L"Klasse1", L"Titel", //...);

Dann aber bitte CreateWindowW benutzen.

CodeFinder schrieb:

Also das da oben geht, ohne Tchar.h

Das funktioniert, weil TCHAR und TEXT in <winnt.h> definiert werden, welche wiederum durch <windows.h> eingebunden wird. <tchar.h> muss man jedenfalls immer separat einbinden, wenn Funktionalität daraus genutzt werden soll.

CodeFinder

groovemaster schrieb:

(D)Evil schrieb:
// Unicode
CreateWindow(L"Klasse1", L"Titel", //...);
Dann aber bitte CreateWindowW benutzen.

Das macht der Compiler automatisch.

groovemaster schrieb:

CodeFinder schrieb:

Also das da oben geht, ohne Tchar.h

Das funktioniert, weil TCHAR und TEXT in <winnt.h> definiert werden, welche wiederum durch <windows.h> eingebunden wird. <tchar.h> muss man jedenfalls immer separat einbinden, wenn Funktionalität daraus genutzt werden soll.

Ahso...danke. Aber welche Funktionen sind denn bspw. in tchar.h deklariert (für die es sich lohnt diese Datei zu inkludieren) ?

Swordfish

CodeFinder schrieb:

[...] Aber welche Funktionen sind denn bspw. in tchar.h deklariert [...] ?

Wie wär's mit 'reinschauen?

*SCNR*

Greetz, Swordfish

CodeFinder

Swordfish schrieb:

CodeFinder schrieb:

[...] Aber welche Funktionen sind denn bspw. in tchar.h deklariert [...] ?

Wie wär's mit 'reinschauen?

*SCNR*

Greetz, Swordfish

ttl

D*3ce

Also ganz komme ich da noch nicht mit.

Was ist zum Beispiel, wenn ich der Funktion ein CharakterArray übergeben will?

//Beispiel
char myText[] = "Hello World";
				TextOut(myHDC, 15, 15, myText, sizeof(myText) - 1);

Das geht nicht, weil ich wieder Typcasten müsste, wie mach ich das also in solchen Fällen?

Swordfish

Wenn es in einer UNICODE Anwendung ist, dann machst du

wchar_t myText[] = L"Hello World";
TextOut( myHDC, 15, 15, myText, sizeof(myText) - 1 );

und gut is.

Greetz, Swordfish

CodeFinder

Oder (sry Swordy, das ich das noch erwähne, ik weiß du magst keine Makros,a ber hier isses sinnvoll ) du benutzt das Makro TEXT und den Datentyp TCHAR, damit kannst du dann Zeichensatz-unabhängig kompilieren.

Also so:

TCHAR myText[] = TEXT("Hello World");
TextOut( myHDC, 15, 15, myText, lstrlen(myText));

Swordfish

CodeFinder schrieb:

Oder (sry Swordy, das ich das noch erwähne, ik weiß du magst keine Makros, aber hier isses sinnvoll ) du benutzt das Makro TEXT und den Datentyp TCHAR, damit kannst du dann Zeichensatz-unabhängig kompilieren.

Sinvoll? Ich kann die Sinnhaftigkeit einer möglichen "Zeichensatz-unabhängigen" Compilierung nicht erkennen. Bei mir ist es so, dass ich entweder eine UNICODE-Anwendung oder eine ASCII- (oder ANSI-, nenn es wie du willst) Anwendung erstelle. Aber was hab' ich von einer .exe mit UNICODE und einer .exe der im Prinzip selben Anwendung in ASCII?

Kannst du mir das bitte erklären.

Greetz, Swordfish

D*3ce

Irgendwie geht das mit dem wchar_t nicht, er zeigt mir nun zwar schön einen String in meinen Fenster an, allerdings sieht der so aus:
"Hello World||||||||"

Das liegt denk ich irgendwie an dem sizeof ... wenn ich -13 mach passt es, also stimmt irgend was mit dem Stringdelimiter (wenn man das so schreibt) nicht, denk ich ...

Swordfish

Ähm, sorry, du nummst natürlich:

wchar_t myText[] = L"Hello World";
TextOut( myHDC, 15, 15, myText, sizeof( myText ) / sizeof( wchar_t ) - 1 );

D!3ce schrieb:

wenn ich -13 mach passt es, also stimmt irgend was mit dem Stringdelimiter (wenn man das so schreibt) nicht, denk ich ...

Nein, am abschließenden L"\0" liegt's nicht, sondern daran, das TextOut im Parameter cbString die Anzahl der auszugebenden Zeichen haben möchte und nicht die Anzahl der Bytes.

Greetz, Swordfish

CodeFinder

Swordfish schrieb:

[...]
Kannst du mir das bitte erklären.
[...]

Jop, clör:
Also es liegt ja auf der Hand, das ein UNICODE-Programm mehr Speicher verbraucht, als ein ANSI-Programm rischtisch ?

Die Vorzüge von UNICODE liegen auch auf der Hand: Man kann auch exotische Sprachen bzw. Zeichen einbauen bzw. unterstützen.

So nun kannst du, wenn du ein Programm schreibst, eine speicherintensive UNICODE-Version herausgeben und eine ANSI-Version, die jedoch einen kleinere Sprach-Unterstützung hat. Also so seh ich das zum mindestens .

D*3ce

Ui, super!

Das funktioniert nun und ist auch einigermaßen logisch, danke schön!

groovemaster

CodeFinder schrieb:

Aber welche Funktionen sind denn bspw. in tchar.h deklariert (für die es sich lohnt diese Datei zu inkludieren) ?

Die Datei zu verwenden ist immer dann sinnvoll, wenn du TCHAR verwendest. Für praktisch alle char/wchar_t Standard Funktionen, wie zB strlen, strcpy, sprintf, etc.pp, gibt es entsprechende TCHAR Gegenstücke. Allerdings sind diese Sachen nicht offiziell, deshalb beginnen die Bezeichner auch mit einem Unterstrich. Aber wenn du MinGW oder den MSC verwendest, ist die Datei verfügbar. Windows selbst stellt ebenfalls TCHAR Funktionen bereit. Diese beginnen mit l, zB lstrcpy. Dies ist aber bei weitem nicht so umfangreich, und kann zudem nicht statisch zur Anwendung gelinkt werden, da diese Funktionen in einer DLL liegen (kernel32).

Und um nochmal darauf zurückzukommen:

CodeFinder schrieb:

Das macht der Compiler automatisch.

Der Compiler macht hier nichts automatisch. Der verarbeitet im Endeffekt nur ...A und ...W Funktionen. Bevor es soweit ist, kommt der Präprozessor zum Zuge. Der macht, abhängig davon, ob das Makro UNICODE definiert ist (bei <tchar.h> ist es übrigens _UNICODE), aus "Bezeichner" entweder "BezeichnerA" (UNICODE nicht definiert) oder "BezeichnerW" (UNICODE definiert). Deshalb sollte man möglichst immer auf eine der folgenden Möglichkeiten zurückgreifen, um Inkonsistenzen zu vermeiden.

// 1) ANSI only
CreateWindowA("Klasse1", "Titel", //...);
// 2) Unicode only
CreateWindowW(L"Klasse1", L"Titel", //...);
// 3) ANSI/Unicode
CreateWindow(TEXT("Klasse1"), TEXT("Titel"), //...);
//    bzw. mit <tchar.h>
CreateWindow(_T("Klasse1"), _T("Titel"), //...);

Alles andere ist nicht zu empfehlen. Das kann sogar soweit gehen, dass das Projekt überhaupt nicht mehr kompiliert werden kann.
Stell dir vor, an einer Stelle steht

CreateWindow("Klasse1", "Titel", //...);

und an anderer Stelle

CreateWindow(L"Klasse1", L"Titel", //...);

Dann kannst du in den Projekteinstellungen Unicode ein- und ausschalten wie du willst, das wird dir nicht helfen.

Wieso man dieses ANSI/Unicode portable Konzept eingeführt hat, kann sicherlich hinterfragt werden. Fakt ist aber, dass gerade ältere Windows Betriebssysteme nur begrenzten Support für Unicode haben. Dort wird idR ANSI kompiliert, bei einem aktuellen Windows ist natürlich Unicode sinnvoll. Und da ist es definitiv praktischer, man legt einfach nur einen Hebel um und alles funktionert, anstatt ständig zwei Projekte zu pflegen.
Natürlich kann man, wenn man einen Zeichensatz nicht braucht bzw. nicht unterstützen will, diesen verwerfen. Dann sollte man sich aber auch über die Konsequenzen im Klaren sein, und das Projekt diesbzgl. absichern, zB mit

#ifndef UNICODE
    #error Projekt darf nur mit Unicode kompiliert werden!
#endif

oder Ähnlichem.

CodeFinder

@groovemaster:
Danke für den ausführliche und informativen Post...aber...das wusste ich eigentlich schon...das der Präprozessor auch Präprozessor-Direktiven (alá '#include') verarbeitet (bzw ersetzt) und nicht der Compiler ist mir klar; War wohl n bissl woanders...trotzdem DANKE!