GetLastError_() » Windowsfehlermeldungen erhalten

[AND51]

Hallo!

Diese Prozedur gibt einen String zurück, der eine Windows-Fehlermeldung enthält. Man liest oft bei Windows-API Befehlen, dass man GetLastError_() aufrufen soll, wenn ein API-Befehl fehlschlägt, um weitere Informationen über den Fehler zu erhalten. Ein Zahlencode nützt einem aber nichts. Daher könnt ihr diese Prozedur benutzen, um aus der Zahl einen String zu machen. Dieser String enthält dann die Fehlermeldung, wie sie in Windows gespeichert ist.

Also: Nach einem gescheiterten Vorgang einfach diese Prozedur aufrufen. Man kann auch den Code für die Fehlermeldung selbst bestimmen, oder man lässt -1 drin; dann wählt die Prozedur automatisch den richtigen Code.

Code: Alles auswählen

Procedure.s GetLastErrorAsString(ErrorCode=-1)
	Protected message.s{1024}
	If ErrorCode = -1
		ErrorCode=GetLastError_()
	EndIf
	FormatMessage_(#FORMAT_MESSAGE_FROM_SYSTEM, 0, ErrorCode, 0, @message, 1024, 0)
	ProcedureReturn message
EndProcedure

For n=2 To 5
	MessageRequester("Demo", GetLastErrorAsString(n), #MB_ICONEXCLAMATION)
Next

Die Fehlermeldungen erscheinen automatisch in der Sprache des Betriebssystems bzw. in der vom Benutzer eingestellten Sprache.


Beispiele:
"Zugriff verweigert"
"Das System kann die angegebene Datei nicht finden."

[X0r]

Bei mir passiert garnichts.

(Getestet auf WinXP, nicht Vista)

[Kiffi]

Bei mir passiert garnichts.

bei mir passiert mit PB4.2 auch nix. (seltsam das...)

mit PB4.3 B4 erscheinen die erwarteten MessageRequester.

Grüße ... Kiffi

[Josef Sniatecki]

Bei mir funktionierts....


...jedoch erst dann, wenn ich "Protected message.s{1<<16}"
zu "Protected message.s=Space(1<<16)" korrigiere.

[AND51]

Also ich habe es unter Vista mit PB 4.30 BETA 4 getestet.

Als ich dann von Unicode auf ASCII wechselte, merkte ich, dass kein String ausgegeben wird. Die Lösung war, in der FormatMessage_() Zeile den die angegebene Buffergröße um 1 bzw 2 Byte zu verringern.

@ Josef:
Der Sinn von {1<<16} ist ja gerade, dass man sich die Space()-Funktion sparen kann. Benutzt du auch 4.20?

Erklärung, die mir hinterher doch überflüssig erscheint, weil ich glaube, dass Josef das schon weiß, die mir aber zu schade ist, sie wieder zu löschen:
Dies bewirkt, dass ein String mit fester Länge ("fixed string") definiert wird, der sozusagen "von Hause aus" den benötigten Speicherplatz bereithält. Es stehen zu Anfang 1<<16, also 65536 Nullen im String. Space() bräuchte allerdings erst etwas Zeit um den String manuell mit Leerzeichen zu füllen.

[PMV]

Dies bewirkt, dass ein String mit fester Länge ("fixed string") definiert wird, der sozusagen "von Hause aus" den benötigten Speicherplatz bereithält. Es stehen zu Anfang 1<<16, also 65536 Nullen im String. Space() bräuchte allerdings erst etwas Zeit um den String manuell mit Leerzeichen zu füllen.

Ob ich in den Speicher 0 schreibe, oder 32 ... richtig genutzt ist es gleich
schnell ... mal davon abgesehen, dass diese Operation wohl erst
überhaupt Messbare unterschiede ergeben könnten, wenn es ne Milliarde
mal pro Sekunde aufgerufen wird

Hm, PBV4.20 scheint probleme mit fixed-Strings größer als $1FD6 zu haben

MFG PMV

[freak]

64k für eine Fehlermeldung ist totaler Overkill.
Selbst wenn es jemals zu einer so langen Fehlermeldung kommen sollte, welcher User will die dann noch lesen ?

> Es stehen zu Anfang 1<<16, also 65536 Nullen im String. Space() bräuchte allerdings erst etwas Zeit um den String manuell mit Leerzeichen zu füllen.

Und wo denkst du das die Nullen herkommen ?
Das ist wiedermal der typische Optimierungswahn der nur zu Problemen führt.

4.20 hatte Probleme mit derart großen lokalen Variablen auf dem Stack, desshalb geht das da nicht, aber auch in 4.30 ist es total übertrieben 64k Platz auf dem Stack zu verschwenden für eine Fehlermeldung. 1000 Zeichen sind da schon mehr als genug, und dann ist es auch egal ob man dabei Space() verwendet oder nicht.

[Kiffi]

Also ich habe es unter Vista mit PB 4.30 BETA 4 getestet.

wie gut, dass Du es in Deinem Ursprungsposting nicht erwähnt hast und in
Deiner Sig noch 4.2 steht (das hat zumindest bei mir die erwähnte
Verwunderung ausgelöst)

Grüße ... Kiffi

[cxAlex]

Das ist wiedermal der typische Optimierungswahn der nur zu Problemen führt.

Es ist doch die Sache eines jeden einzelnen wie und ob er seinen Code optimiert. Manchmal macht es was aus ob eine Funktion 40 anstatt 50 us zum Ausführen braucht.

[PMV]

Richtig, manchmal kann man aber genauer definieren. Es macht etwas
aus, wenn diese Codestelle ne Million mal pro Sekunde ausgeführt wird.
Nur dann machen solche Optimierungen sinn. Und solch eine Prozedur wird
ganz bestimmt max. 1 mal pro Minute aufgerufen, wenns richtig schlimm
wird

In diesem Fall ist dort aber noch nicht mal eine Optimierung.

MFG PMV