Re: Hack/work-around for cursor problem on sparc-solaris

> I don't see how you can do that, SetCursor doesn't call LoadCursor.
> And LoadCursor on system cursors is not supposed to fail so there is
> no need to handle that case; if it fails it's a bug that should be
> fixed.

That's true, but the paradigm
  SetCursor(LoadCursorA(...));

happens in a lot of places...   What I'm suggesting is replacing them with
something like:
  HCURSOR cursor = LoadCursorA(...);
  if (cursor) {
    SetCursor(cursor);
  } else {
    SetDefaultCursor();
  }

As I said, if you don't think this will ever happen in 'real life', I'm happy to
leave my hack in place locally until I get the cursor thing sorted out
correctly...

But if there are any legitimate cases where LoadCursorA might fail, this would
probably give a better result...

Warren

Hack/work-around for cursor problem on sparc-solaris

[Alexandre Julliard]

Warren_Baird(a)cimmetry.com writes:
> happens in a lot of places...   What I'm suggesting is replacing them with
> something like:
>   HCURSOR cursor = LoadCursorA(...);
>   if (cursor) {
>     SetCursor(cursor);
>   } else {
>     SetDefaultCursor();
>   }
>
> As I said, if you don't think this will ever happen in 'real life', I'm happy to
> leave my hack in place locally until I get the cursor thing sorted out
> correctly...
>
> But if there are any legitimate cases where LoadCursorA might fail, this would
> probably give a better result...

I don't think there are places where LoadCursor can legitimately
fail. Besides, since your SetDefaultCursor is not an exported API it
could only be used inside user32.dll, where LoadCursor will definitely
never fail (modulo bugs of course).

-- 
Alexandre Julliard
julliard(a)winehq.com