#include <windows.h>

int CALLBACK WinMain(HINSTANCE hInstance,
                     HINSTANCE hPrevInstance,
                     LPTSTR    lpCmdLine,
                     int       nCmdShow)
{
    (...)//Restlicher Code.
}

Zweites Problem: Wenn ich in einem DOS-Programm (vortestweise) die MessageBox() aufrufe (beispielsweise, um eine selbstdefinierte Exception auszulösen) und ich die Funktion so aufrufe:

#include <windows.h>

int main()//Argumente spare ich mir...
{
    MessageBoxA(NULL,(LPCSTR)"Beispiel",(LPCSTR)"Beispiel",MB_OK|MB_ICONINFO);	//Dies funktioniert.
    MessageBox(NULL,(LPCWSTR)"Beispiel",(LPCWSTR)"Beispiel",MB_OK|MB_ICONINFO);	//Hier entstehen Kästchen.
}

dann erhalte ich beim Aufruf von MessageBoxA eine völlig normale MessageBox, beim Aufrufen von MessageBox (oder MessageBoxW) eine MessageBox mit undefinierbaren Zeichen (hauptsächlich Kästchen, aber der eine oder andere arabische Buchstabe ist auch dabei. Zumindest vermute ich, dass es arabisch ist.). Vielleicht liegt es an der Umwandlung vom char*- in einen LPCWSTR-String, aber ich habe keine Ahnung, was ich tun könnte. Wenn jemand Lösungsvorschläge hat, wäre ich demjenigen sehr verbindlich, der sie hier aufschreibt.

L"meinString"

Du kannst dir auch die Casts (LPCSTR bzw. LPCWSTR) sparen.

Pack ein "L" vor deine Strings, dann sollte es klappen.

L"meinString"

.

Ahh, danke. Werde ich versuchen!

Du kannst dir auch die Casts (LPCSTR bzw. LPCWSTR) sparen.

Leider nein. Wenn ich das mache, dann haut mir die Maschine den Fehler raus, dass "char* nicht in LPCWSTR (oder) LPCSTR konvertiert werden kann." Meistens kommt dann noch der Vorschlag, eine Typumwandlung im C-Style zu machen oder einen reinterpret_cast<>() anzuwenden.

MessageBox(0,"SetupDiGetClassDevs error.","Test",0);

Funktioniert einwandfrei. Ich glaube, bei dir ist das nur aufgetreten, wenn du z.B. in einem Unicode-Projekt an MessageBox (=MessageBoxW) einen char* und eben nicht einen wchar_t* übergeben hast. Dann kann vermutlich nicht implizit nach LPCWSTR gecastet werden (macht ja auch keinen Sinn) und du kannst halt nur C-Cast/reinterpret_cast anwenden. Und dann kriegst du auch so ein Kuddelmuddel (char* nach LPCWSTR casten).

EDIT: Einen konstanten wchar_t* kriegst du halt, wenn du dem String ein L voranstellst.

Der Compiler erkennt die Funktion WinMain() nicht als Prozedureinprungspunkt an:

Wie äußert sich das? Und wie hast du dein Projekt erzeugt?

#include <windows.h>

int CALLBACK WinMain()//Die vier Standartargumente spare ich mir...
{
    (...)//Der Rest...
}

Wenn ich das Zeug aber linken will, erscheint (in etwa) folgende Fehlermeldung:
"Nicht aufgelöstes Symbol WinMain@()".
Bei einem älteren Compiler (MSVC++ 8.0) funktioniert das aber.

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpszCmdLine, int nCmdShow){
:
:
:
	return 0;
}

Deine CALLBACK Funktion ist für den Messagehandler, kann man dann z.B. so schreiben:

LRESULT CALLBACK EventHandler_MainWnd(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam){
:
:
:

	return DefWindowProc(hWnd, message, wParam, lParam);
}

dann erhalte ich beim Aufruf von MessageBoxA eine völlig normale MessageBox, beim Aufrufen von MessageBox (oder MessageBoxW) eine MessageBox mit undefinierbaren Zeichen (hauptsächlich Kästchen, aber der eine oder andere arabische Buchstabe ist auch dabei. Zumindest vermute ich, dass es arabisch ist.). Vielleicht liegt es an der Umwandlung vom char*- in einen LPCWSTR-String, aber ich habe keine Ahnung, was ich tun könnte. Wenn jemand Lösungsvorschläge hat, wäre ich demjenigen sehr verbindlich, der sie hier aufschreibt.

Du definierst in deine Projekteigenschaften ob dein Projekt Unicode oder multibyte Zeichensatz verwenden soll. (Projekt-> Eigenschaften-> Konfigurationseigenschaften-> Allgemein-> Zeichensatz-> "Multi-Byte-Zeichensatz verwenden" oder "Unicode-Zeichensatz verwenden" auswählen). Der Compiler entscheide dann je nach ausgewälten Zeichesatz ob er für MessageBox MessageBoxA oder MessageBoxW auswählt. Siehe hierzu "winuser.h"

#ifdef UNICODE
#define MessageBox  MessageBoxW
#else
#define MessageBox  MessageBoxA
#endif // !UNICODE

guggstdu schrieb:

also bei mir sieht der Einstiegspunkt so aus (man beachte das WINAPI):

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpszCmdLine, int nCmdShow){
:
:
:
	return 0;
}

Deine CALLBACK Funktion ist für den Messagehandler, kann man dann z.B. so schreiben:

LRESULT CALLBACK EventHandler_MainWnd(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam){
:
:
:

	return DefWindowProc(hWnd, message, wParam, lParam);
}

Ich glaub dir ist nicht bewusst das sowohl "WINAPI" also auch "CALLBACK" nur eine #define ist wo "__stdcall" dahinter steckt ;).

Gruessli C0de4Fun

€ mist wohl zu spaet

LPTSTR lpszCmdLine

Der sollte so aussehen:

LPSTR lpszCmdLine

EDIT: Der Compiler hat dir doch auch gesagt, dass du die WinMain nicht überladen kannst. Das ist ein Anzeichen dafür, dass deine Parameter-Liste nicht korrekt ist (oder die Rückgabe). Du versuchst, eine WinMain-Variante zu notieren, die es nicht gibt.

WAS IST DER UNTERSCHIED? ICH WEISS ES NICHT MEHR.

Ich glaub dir ist nicht bewusst das sowohl "WINAPI" also auch "CALLBACK" nur eine #define ist wo "__stdcall" dahinter steckt ;).

Ja, stimmt war mir nicht bewußt. Ich habe mir da auch nie einen Kopf gemacht, weil mein Code ja auch funktioniert.

A multibyte character set may consist of both one-byte and two-byte characters. Thus a multibyte-character string may contain a mixture of single-byte and double-byte characters. A two-byte multibyte character has a lead byte and a trail byte. In a particular multibyte-character set, the lead bytes fall within a certain range, as do the trail bytes. When these ranges overlap, it may be necessary to evaluate the particular context to determine whether a given byte is functioning as a lead byte or a trail byte.

1. Unicode verwendet standartmässig 2 Byte.
2. Alle Unicodestrings sind eine Liste aus 2-Byteblöcken.
3. Unicode ist nicht so fehleranfällig, da nicht über den reservierten Speicher hinaus geschrieben werden muss.

Habe ich das jetzt richtig rekapituliert?

Ok, fassen wir einmal zusammen:
1. Multibytes können auch 1 Byte betragen.

Ja.

.......... schrieb:

2. Multibytestrings können daher eine Liste aus 1- und 2-Byteblöcken sein.

oder mehr... (deswegen ja *mulit*... sonst hiese es ja "double" (DBCS, was es auch gibt ))

.......... schrieb:

3. Jedoch sind diese Fehleranfällig, wenn man den Wert eines 1-Byteblock über OxFF stellt (1 Byte). Dann wird das nächste Byte uberschrieben.

Nö... wieso soll sowas Fehleranfällig sein... das Problem ist nur, dass man oft nicht weiss, welches *Encoding* verwendet wurde...

.......... schrieb:

1. Unicode verwendet standartmässig 2 Byte.

Nein. Unicode ist ein Zeichen-Standard und hat primär mit der Codierung in Dateien nichts zu tun. Zur Codierung wird aber UTF8 oder UTF16 empfohlen. Will man eine 1-zu-1 Kodierung des Standards in der Datei, so muss man UTF32 verwenden.

.......... schrieb:

2. Alle Unicodestrings sind eine Liste aus 2-Byteblöcken.

Dies trifft nur bei UTF16 zu (wchar_t)

.......... schrieb:

3. Unicode ist nicht so fehleranfällig, da nicht über den reservierten Speicher hinaus geschrieben werden muss.

Nein. Damit hat dies nichts zu tun.

Siehe auch meinen Artikel über Unicode im Artikel-Forum