Schwierigkeiten mit dem Microsoft Visual C++ 2008-Compiler (Express)

_matze

Doch, glaub mir. Ein Beispiel aus einem meiner Programme:

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.

_matze

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

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

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

Nun, ich erstelle ein normales, leeres Projekt (Win32-Projekt,Leeres Projekt, keine vorkompilierten Header) und geben dann den Standartcode ein:

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

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);
}

Eigentlich ist es egal, was ich nehme. WINAPI, CALLBACK oder einfach nur __stdcall, dass ist (zumindest in meinen API-Funktionen und MFC-Klassen) Jacke wie Hose. Ich habe mir mal die Header angesehen, und ich habe 4 Definitionen (#define) für __stdcall gefunden. Ich glaube nicht so recht daran, dass es deshalb nicht funktioniert.

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

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

C0de4Fun

Hi,

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

_matze

Es liegt an dem Parameter

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.

Ok, eine dritte Frage: Was ist der Unterschied zwischen Multibyte und Unicode?
Folgendes weiss ich bereits:
1. Beide verbrauchen mehr als 1 Byte pro Buchstabe.
2. Daher gibt es mindestens 65535 verschiedene Buchstaben.
3. Beide unterstützen auch asiatische Buchstaben- oder Silbensätze.

WAS IST DER UNTERSCHIED? ICH WEISS ES NICHT MEHR.

C0de4Fun schrieb:

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.

_matze

Microsoft schrieb:

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.

Ok, fassen wir einmal zusammen:
1. Multibytes können auch 1 Byte betragen.
2. Multibytestrings können daher eine Liste aus 1- und 2-Byteblöcken sein.
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.

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?

Jochen Kalmbach

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

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