What is with the "no error" errors in Win32 ? I encountered yet another
case, with bitblt, where the return value indicates error (0), but
the call to getlasterror returns the "no error" code. This has occurred
on several other calls, and I have to work around it by ignoring the
error. In all these cases, the function appeared to work correctly,
despite the error return.

Is it just that it is so uncommon for people to actually check the error
returns that some of them don't work ?

-- 
Samiam is Scott A. Moore

Personal web site: http:/www.moorecad.com/scott
My electronics engineering consulting site: http://www.moorecad.com
ISO 7185 Standard Pascal web site: http://www.moorecad.com/standardpascal
Classic Basic Games web site: http://www.moorecad.com/classicbasic
The IP Pascal web site, a high performance, highly portable ISO 7185 Pascal
compiler system: http://www.moorecad.com/ippas

Good does not always win. But good is more patient.

On Tue, 16 Aug 2005 11:07:31 -0700, Scott Moore <samiam@moorecad.com>
wrote:

>What is with the "no error" errors in Win32 ? I encountered yet another
>case, with bitblt, where the return value indicates error (0), but
>the call to getlasterror returns the "no error" code. This has occurred
>on several other calls, and I have to work around it by ignoring the
>error. In all these cases, the function appeared to work correctly,
>despite the error return.
>
>Is it just that it is so uncommon for people to actually check the error
>returns that some of them don't work ?

These seem to be most common on Win9x/ME platforms, where GDI is most
broken, and less common on "real" Win32 platforms.

Perhaps poorly written display drivers can cause this to happen on
other platforms as well.

For BitBlt and friends, the culprit is often parameters out of range
or access to unallocated memory.

--
Sev

Severian [MVP] wrote:
> On Tue, 16 Aug 2005 11:07:31 -0700, Scott Moore <samiam@moorecad.com>
> wrote:
> 
> 
>>What is with the "no error" errors in Win32 ? I encountered yet another
>>case, with bitblt, where the return value indicates error (0), but
>>the call to getlasterror returns the "no error" code. This has occurred
>>on several other calls, and I have to work around it by ignoring the
>>error. In all these cases, the function appeared to work correctly,
>>despite the error return.
>>
>>Is it just that it is so uncommon for people to actually check the error
>>returns that some of them don't work ?
> 
> 
> These seem to be most common on Win9x/ME platforms, where GDI is most
> broken, and less common on "real" Win32 platforms.
> 
> Perhaps poorly written display drivers can cause this to happen on
> other platforms as well.
> 
> For BitBlt and friends, the culprit is often parameters out of range
> or access to unallocated memory.
> 
> --
> Sev

Thanks, that's good information. My platform is WindowsXP, and I have
seen a couple of these, but no, I didn't make a list. The bitblt that
caused the last error seems fine with the error ignored.

If BitBlit fails, usually you see the result right away.

Severian [MVP] wrote:


> Scott Moore <samiam@moorecad.com> wrote:
>
> >What is with the "no error" errors in Win32 ? I encountered yet another
> >case, with bitblt, where the return value indicates error (0), but
> >the call to getlasterror returns the "no error" code.


> These seem to be most common on Win9x/ME platforms, where GDI is most
> broken, and less common on "real" Win32 platforms.


Um, expected behaviour for bitblt, surely?

MSDN:
If the function succeeds, the return value is nonzero.
If the function fails, the return value is zero.
Windows NT/2000/XP: To get extended error information, call
GetLastError.

There is no apparent offer of having GetLastError for bitblt on win9x.

HTH,
TC

TC wrote:
> Severian [MVP] wrote:
> 
> 
> 
>>Scott Moore <samiam@moorecad.com> wrote:
>>
>>
>>>What is with the "no error" errors in Win32 ? I encountered yet another
>>>case, with bitblt, where the return value indicates error (0), but
>>>the call to getlasterror returns the "no error" code.
> 
> 
> 
>>These seem to be most common on Win9x/ME platforms, where GDI is most
>>broken, and less common on "real" Win32 platforms.
> 
> 
> 
> Um, expected behaviour for bitblt, surely?
> 
> MSDN:
> If the function succeeds, the return value is nonzero.
> If the function fails, the return value is zero.
> Windows NT/2000/XP: To get extended error information, call
> GetLastError.
> 
> There is no apparent offer of having GetLastError for bitblt on win9x.
> 
> HTH,
> TC
> 

Sounds like bitblt used to not cooperate with the getlasterror mechanisim,
but now kinda sorta does.

On Tue, 16 Aug 2005 13:22:22 -0700, Scott Moore
<samiamsansspam@Sun.COM> was understood to have stated the following:

>
>Thanks, that's good information. My platform is WindowsXP, and I have
>seen a couple of these, but no, I didn't make a list. The bitblt that
>caused the last error seems fine with the error ignored.

Well, if we're making a list, I've seen CreateWindow return NULL and
GetLastError() return 0 under XP. The condition was created by
creating child windows of the same class as the window currently
having it's WM_CREATE handled. :-)

Didn't it used to be the case that with Checked builds of Windows, GDI
would give you all sorts of parameter validation messages?  I seem to
remember it kicking out stuff but it has been sooo long ago.

In article <sq1bg11q8e5ukpm4rf6od9ogmi5gph2ebh@4ax.com>,
STKR!@microsoft.com (David W. Poole, Jr.) writes:

> On Tue, 16 Aug 2005 13:22:22 -0700, Scott Moore
> <samiamsansspam@Sun.COM> was understood to have stated the following:
>
>> Thanks, that's good information. My platform is WindowsXP, and I have
>> seen a couple of these, but no, I didn't make a list. The bitblt that
>> caused the last error seems fine with the error ignored.
>
> Well, if we're making a list, I've seen CreateWindow return NULL
> and GetLastError() return 0 under XP. The condition was created by
> creating child windows of the same class as the window currently
> having it's WM_CREATE handled. :-)

My favourite (?) way of inducing the condition on my Win98 box is
by forgetting to call WSAStartup().  A subsequent socket() call
will return INVALID_SOCKET, while GetLastError() will return zero.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

On 22 Aug 05 09:38:00 -0800, "Charlie Gibbs" <cgibbs@kltpzyxm.invalid>
was understood to have stated the following:

>> Well, if we're making a list, I've seen CreateWindow return NULL
>> and GetLastError() return 0 under XP. The condition was created by
>> creating child windows of the same class as the window currently
>> having it's WM_CREATE handled. :-)
>
>My favourite (?) way of inducing the condition on my Win98 box is
>by forgetting to call WSAStartup().  A subsequent socket() call
>will return INVALID_SOCKET, while GetLastError() will return zero.

I thought we were supposed to call WSAGetLastError() as opposed to
GetLastError()?