Newsgroup: it.comp.programmare.win32
Titolo: Errori ritornati dalle API di Windows

Ciao a tutti,
sto tentando di utilizzare le API CreateFile(), ReadFile(), WriteFile(),
CloseHandle(), ecc. ecc. per comunicare attraverso una porta seriale
scrivendo un programma in Visual Basic (lo so, esiste il controllo MsComm,
ma voglio usare 'ste API per altri motivi).
Naturalmente ogni funzione può ritornare un errore che vado puntualmente
a controllare mediante Err.LastDllError. Bene, come faccio a gestire
tutti i possibili errori di ogni routine?
In altre parole, se la CreateFile() fallisce, per quale motivo fallisce?
Vado a vedere Err.LastDllError. Ma quali possibili valori può assumere
un errore della CreateFile()? Nell'MSDN non sembra ci sia questa
informazione, cioé tutti i possibili errori che può ritornare una
routine.

 routine.
La funzione che restituisce il codice di errore eventualmente generato dalla
CreateFile e' la GetLastError (corrispondente alla Err.LastDllError).
Nell'help dell'MSDN la GetLastError ti porta a tutti i "System Error Codes"
che raccoglie tutti i possibili codici restituiti.
Questo probabilmente lo sapevi.
Esiste inoltre un'altra API che e' la FormatMessage che provvede a
restituirti una descrizione dell'errore senza che ti ingegni ad
intercettarlo tu.
La puoi usare in questo modo (attenzione!!! ho scritto queste righe senza
provarle)
Const FORMAT_MESSAGE_FROM_SYSTEM = &H1000
Const LANG_NEUTRAL = &H0
Declare Function FormatMessage Lib "kernel32" Alias "FormatMessageW" _
    (ByVal Flags As Long, ByVal Source As Long, ByVal MessageID As Long, _
    ByVal LanguageID As Long, Buffer As Long, ByVal Size As Long, ByVal
Args As     Long) As Long
StringaErrore = Space(256)
lRet = FormatMessage (FORMAT_MESSAGE_FROM_SYSTEM, ByVal 0&,
Err.LastDllError, LANG_NEUTRAL, StringaErrore, 256, ByVal 0&)
MsgBox Left(StringaErrore, lRet)
In questo modo puoi tranquillamente visualizzare il messaggio di errore
corrispondente per capire cosa e' successo.

 provarle)
[CUT]
E' giusto quello che dici ed è un consiglio sicuramente utile.
Il problema è che voglio gestire io, in modo diverso, tutti i possibili
errori ritornati da una certa API di Windows, per esempio la CreateFile().
Possibile che non siano documentati, per ogni funzione API, tutti i
possibili errori che questa può ritornare, magari con una descrizione
della situazione in cui ciò può capitare?
Se per esempio utilizzo la CreateFile() per aprire una porta seriale
e questa mi ritorna ACCESS_DENIED, forse è meglio visualizzare un
messaggio del tipo "Porta già aperta da un'altra applicazione", piuttosto
che scrivere "Accesso negato". Oppure se ritorna FILE_NOT_FOUND, forse
è meglio scrivere "Porta seriale inesistente" piuttosto che "File non
trovato".
Questi due casi sono sicuramente possibili poiché li ho provati sul
mio sistema, ma chissà quante altre combinazioni esistono? Magari dovrei
personalizzare qualche altro messaggio d'errore o gestirlo in modo
diverso dal normale, però non so quali possono essere.

La risposta credo che sia "non esiste" :-)
Una possibile soluzione comunque è usare il lavoro fatto dalla microsoft per
il C#. Infatti in C# una buona fetta degli errori di Windows sono trattati
come eccezioni, e una grossa fetta della API del C# è la API del Windows.
Quindi puoi cercare di fare dei semplici paragoni fra le eccezioni del C# e
gli errori definiti in winerror.h . (nell'msdn dicono ogni funzione di C#
che eccezioni può avere)
--- bye

 seriale inesistente" piuttosto che "File non trovato".
bazzeccole. Come discutere di che colore vuoi la tua bara. Se vuoi fare 
una buona cosa, quel che dovresti fare è dare un messaggio d'errore con 
un po' più di contesto. Qualcosa come: "Impossibile aprire la porta: ", 
seguito dal messaggio associato all'errore
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.2.1. C, C++ and ASM developers
                               and beta testers are welcome!