#include "stdafx.h"
#include <windows.h>

LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM);

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, 
                   PSTR szCmdLine, int iCmdShow)
{
	HWND       myHWND;	
	MSG        myMSG;
	WNDCLASS   myWNDCLASS;
	myWNDCLASS.style =  CS_HREDRAW | CS_VREDRAW;
	myWNDCLASS.lpfnWndProc =  WndProc;	
	myWNDCLASS.cbClsExtra =  0;
	myWNDCLASS.cbWndExtra =  0;
	myWNDCLASS.hInstance = hInstance;
	myWNDCLASS.hCursor = LoadCursor(NULL,IDC_ARROW);
	myWNDCLASS.hIcon = LoadIcon(NULL,IDI_APPLICATION);
	myWNDCLASS.hbrBackground = (HBRUSH)GetStockObject(WHITE_BRUSH);
	myWNDCLASS.lpszClassName =  "Klasse1";	
	myWNDCLASS.lpszMenuName  =  NULL;
	RegisterClass(&myWNDCLASS);	
	myHWND = CreateWindow("Klasse1", "Titel", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, NULL, NULL, hInstance, NULL);
	ShowWindow(myHWND, iCmdShow);
	UpdateWindow(myHWND);

         //und so weiter

Nun kann ich aber nicht starten weil der erste und der zweite Parameter bei CreateWindow in einen LPCWSTR gecastet werden sollen. Mach ich das, startet zwar mein Fenster, der Text ist aber nicht zu lesen, sind lauter Vierecke.

Komischerweise sind alle Beispiele, die ich gefunden hab (zum Beispiel MSDN und ein paar gegoogelte) ohne typecasten, geht aber bei mir, wie gesagt, nicht.

Thx für Hilfe und Durchlesen

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

// #include <tchar.h> nicht vergessen!
CreateWindow(_T("Klasse1"), _T("Titel"), //... 

// Wobei char wird zu TCHAR, LPCSTR wird zu LPCTSTR usw. am besten auch tstrcpy usw. dann benutzen...

Bei letzterem kannst de nicht Unicode und Unicode compilieren

#include <Windows.h>

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

Also das da oben geht, ohne Tchar.h

// 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.

(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) ?

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

Wie wär's mit 'reinschauen?

*SCNR*

Greetz, Swordfish

CodeFinder schrieb:

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

Wie wär's mit 'reinschauen?

*SCNR*

Greetz, Swordfish

ttl

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?

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

und gut is.

Greetz, Swordfish

Also so:

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

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

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 ...

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

[...]
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 .

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

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.

Nur eine Frage noch zu den "neuen" Befehlen.
Du hast gesagt, dass meistens "einfach nur ein l" davor steht, das funktioniert zum Beispiel mit lstrcpy perfekt, nur gibt es kein lsizeof weswegen Dinge wie

sizeof(keyStroke) / sizeof(wchar_t) - 1

entstehen, gibts da keine schönere Lösung.

Außerdem funktioniert das bei mir nicht richtig.

Was ich inetwa habe:

Ein Fenster, in dem, in einem Rechteck, ein Text angezeigt werden soll. Jener Text zeigt an, ob eine Pfeiltaste gedrückt wurde, wenn nicht steht "No Arrow pressed".

Relevante Codeausschnitte sehen bei mir so aus:

//Membervariable
wchar_t keyStroke[] = TEXT("Nothing pressed yet ...");

// ...

//wird eine Taste gedrückt (WM_KEYDOWN)

switch(wParam)
			{
				case VK_LEFT:
					lstrcpy(keyStroke,TEXT("Arrow: Left"));
					break;

//und so weiter

// ...

//wird das Fenster gezeichnet findet sich folgender Befehl
DrawText(myHDC, keyStroke, sizeof(keyStroke) / sizeof(wchar_t) - 1, &myRect, DT_CENTER|DT_TOP);

Das funktioniert ansich perfekt, außer das ich wieder Dinge wie "Arrow:Left|||||" zu sehen bekomme.

Deswegen frage ich nach einer Variante like lsizeof.

Gibt es irgendwo eine Liste mit all diesen Befehlen? Thx 4 help!

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/resources/strings/stringreference/stringfunctions/lstrlen.asp
(Links in der navi stehen weitere String Funktionen, das ganze ist auch in der Platform SDK Doku drin...)