How can I distinguish between empty window text and error with GetWindowText API?

Question

The return value of the GetWindowText function GetWindowText described as follows :

If the function succeeds, the return value is the length, in characters, of the copied string, not including the character terminating zero. If the window does not have a title bar or text, if the title bar is empty, or if the window or control descriptor is invalid, the return value is zero. To get extended error information, call GetLastError.

Now when you call this method and get the return value equal to zero, how do I know if the GetLastError value will return a reasonable value? In the end, zero is used not only to indicate a failure, but can also mean that the window text is empty, in which case GetLastError will not return undefined.

My own ideas:

• At first I thought that maybe GetWindowText could set the last error to 0 on success. But testing shows that this is not the case (and if that were the case, I still could not rely on it, since this is not documented).
• Then I thought that maybe GetWindowText might leave the last error unchanged upon successful completion, so before calling it, it checks to see if the last error will change. Testing shows that this may work, but since it is not, I cannot rely on it. (And I assume that this will largely depend on the specific circumstances and implementation of GetWindowText .)
• And, of course, I could first check the length of the window text with GetWindowTextLength , and then call GetWindowText only if the length was greater than 0. However, what if the window changes the text between my calls to GetWindowTextLength and GetWindowText ? I, again, could not rely on the return value of zero, indicating an error.

So what can I do to definitely decide if GetWindowText ?

Answer 1

SetLastError(ERROR_SUCCESS) is safe and supported in advance.

The documentation for the last error codes makes it clear that the function may or may not delete the last error value upon successful completion. However, it is obvious that if the function succeeds, it will either leave the value of the last error unchanged, or set it to zero, but never change it to the value of the error.

Implementation rules for WinAPI functions can be summarized as:

• Do not SetLastError if the error does not occur.
• If the helper function sets an error code that does not cause your API to crash, call SetLastError(0) so that it does not cause a fatal internal error to the caller, or call RestoreLastError and pass all GetLastError returned when entering your API .
• If your API crashes without exception with a SEH exception, call SetLastError to report it (unless a helper function has been created).

The documented behavior "some functions that SetLastError with zero when they SetLastError " is a consequence of point 2.

Answer 2

Yes, you are right, you cannot use GetLastError() to see the difference. Not pretty. The only workaround I can come up with is to use IsWindow() after that. If this returns TRUE, then a null return does mean "empty string". This, however, is not related to passing a pointer to a bad buffer, which I hope is easy to avoid in your code.