Several functions which could return a Result

[fgimian]

Summary

Hey there Kenny and friends, I'm sure this is a small subset, but I discovered various functions which can fail (with details available via GetLastError) although these presently don't return a Result type. They are as follows, with relevant return details copied here for your convenience:

SendMessageTimeoutW -> LRESULT

If the function succeeds, the return value is nonzero. SendMessageTimeout does not provide information about individual windows timing out if HWND_BROADCAST is used.

If the function fails or times out, the return value is 0. To get extended error information, call GetLastError. If GetLastError returns ERROR_TIMEOUT, then the function timed out.

GetWindowThreadProcessId -> u32

If the function succeeds, the return value is the identifier of the thread that created the window. If the window handle is invalid, the return value is zero. To get extended error information, call GetLastError.

AttachThreadInput -> BOOL

If the function succeeds, the return value is nonzero.

If the function fails, the return value is zero. To get extended error information, call GetLastError.

SetActiveWindow -> HWND

If the function succeeds, the return value is the handle to the window that was previously active.

If the function fails, the return value is NULL. To get extended error information, call GetLastError.

QueryDosDeviceW -> u32

If the function succeeds, the return value is the number of TCHARs stored into the buffer pointed to by lpTargetPath.

If the function fails, the return value is zero. To get extended error information, call GetLastError.

GetFileAttributesW -> u32

If the function succeeds, the return value contains the attributes of the specified file or directory. For a list of attribute values and their descriptions, see File Attribute Constants.

If the function fails, the return value is INVALID_FILE_ATTRIBUTES. To get extended error information, call GetLastError.

GetFileVersionInfoSizeW -> u32

If the function succeeds, the return value is the size, in bytes, of the file's version information.

If the function fails, the return value is zero. To get extended error information, call GetLastError.

CertCreateCertificateContext -> *mut CERT_CONTEXT

If the function succeeds, the function returns a pointer to a read-only CERT_CONTEXT. When you have finished using the certificate context, free it by calling the CertFreeCertificateContext function.

If the function is unable to decode and create the certificate context, it returns NULL. For extended error information, call GetLastError. Some possible error codes follow.

---

It is my understanding that the following two functions return the actual WIN32_ERROR code instead of using GetLastError. The windows-rs library returns a Result as expected for some other power functions such as PowerGetActiveScheme, PowerReadFriendlyName and PowerSetActiveScheme which return a WIN32_ERROR internally and are converted to a Result via the .ok() method.

PowerReadACValueIndex -> u32

Returns ERROR_SUCCESS (zero) if the call was successful, and a nonzero value if the call failed.

PowerWriteACValueIndex -> u32

Returns ERROR_SUCCESS (zero) if the call was successful, and a nonzero value if the call failed.

Crate manifest

N/A

Crate code

N/A

[tim-weis]

The only tractable way to get those transformations into windows-rs is if the information is included in the win32metadata. This can be made to work if the SDK headers had success/failure annotations. I looked at several of the APIs listed here and none had the required SAL annotations.

[fgimian]

The only tractable way to get those transformations into windows-rs is if the information is included in the win32metadata. This can be made to work if the SDK headers had success/failure annotations. I looked at several of the APIs listed here and none had the required SAL annotations.

Understood, thanks for the reply. @kennykerr feel free to transfer this issue to win32metadata mate. I'll attempt to check the metadata and raise similar issues there directly in future.

Cheers
Fotis

[riverar]

Good data, thanks! Will transfer.