one liner patch to stop crash, everquest2.exe

[Andrew Fenn]

Any suggestion on where to go from here? Does this need more discussion
elsewhere or should a simple return WINED3DERR_INVALIDCALL do it?

I'm having trouble understanding where I should be checking for this error
and returning an the invalid call.

On Mon, Jul 21, 2008 at 9:28 PM, Stefan Dösinger <stefan at codeweavers.com>
wrote:

> > Ah, so it's essentially a recursive Reset call. My guess would be that
> > we don't want to allow that, but it requires some tests on native
> > win32 to verify. You could try returning WINED3DERR_INVALIDCALL when
> > Reset gets called from inside another Reset call, to see how the
> > application reacts to that.
> This also raises another question regarding the window handling in wined3d:
> Are we allowed / supposed to modify the window size and position of the
> destination window the app supplies like this? A lot of apps seem to need
> that, otherwise the rendering is placed incorrectly or not visible because
> the window is hidden. However, it could be that Windows somehow renders
> correctly without changing the Window's properties.
>
> So the SetWindowPos() call in Reset() might be the wrong thing here. It is
> not entirely unexpected that the app calls Reset when it receives a Window
> position / size change. If the Window size changes, the app is supposed to
> reset the D3D device, otherwise the rendering output is stretched in
> Present(which can look kinda ugly)
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-devel/attachments/20080724/55608c87/attachment.htm