[d3d] Memcpy segfault
A reference application I use fails with a segfault in d3d, Its called Little Fighter 2 It fails after a call to BLT where both the source and dest are NULL and delivers this trace. I suspect the memcpy at line 1251 in surface_gdi.c then fails because sbuf or dbuf are invalid or NULL. I'm not very familiar with this code so I'd welcome views on the correct fix, (Other than just checking dbuf and sbuf for NULL) trace:ddraw:IDirectDrawSurfaceImpl_Blt (7ff33bd8)-(0,0,0,1000400,7fd2fb20) trace:d3d_surface:IWineGDISurfaceImpl_Blt (7ff33cb8)-(0,0,0,1000400,7fd2fb20) trace:d3d_surface:IWineGDISurfaceImpl_LockRect (7ff33cb8) : [EMAIL PROTECTED] flags(), output [EMAIL PROTECTED], [EMAIL PROTECTED] trace:d3d_surface:IWineD3DSurfaceImpl_GetPitch (7ff33cb8) trace:d3d_surface:IWineD3DSurfaceImpl_GetPitch (7ff33cb8) Returning 2384 trace:d3d_surface:IWineGDISurfaceImpl_LockRect Locked Rect (7ff33d20) = l 0, t 0, r 794, b 550 trace:d3d_surface:IWineGDISurfaceImpl_LockRect returning [EMAIL PROTECTED], pitch(2384)
Re: Mouse woes and luck of interest
On Sat, 2006-10-14 at 23:27 -0600, Vitaliy Margolen wrote: As you know Wine has number of problems with it's mouse handling. Just enough to look at the bugzilla to see how many programs affected. After spending several weeks trying to find and fix this problems I in the dead-end now. Just curious, but do your patches obviate the need for this one:
Re: Mouse woes and luck of interest
On Wed, 2006-10-18 at 00:34 -0700, Scott Ritchie wrote: On Sat, 2006-10-14 at 23:27 -0600, Vitaliy Margolen wrote: As you know Wine has number of problems with it's mouse handling. Just enough to look at the bugzilla to see how many programs affected. After spending several weeks trying to find and fix this problems I in the dead-end now. Just curious, but do your patches obviate the need for this one: Sorry, forgot the link. As an aside note, whomever made ctrl+enter a hotkey for send my email without confirmation before it's finished in evolution needs to be shot. http://bugs.winehq.org/show_bug.cgi?id=1064 Thanks, Scott Ritchie
Re: direct access to IO space [Was: kernel level drivers - next try]
James == James Courtier-Dutton [EMAIL PROTECTED] writes: James This feature is being ask for by people who don't understand what James most hardware requires from a driver. 1) IO ports or memory James mapped IO. 2) DMA handler 3) IRQ handler James Getting IO port access in wine really is not going to help a James whole lot! For a lot of programms used to program electronic devices, IO port access under wine would help a lot! -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
d3d8: GetDepthStencilSurface/GetRenderTarget refcount issue
I'm trying to solve bug 5872 http://bugs.winehq.org/show_bug.cgi?id=5872
BF1942 calls GetDepthStencilSurface/IUnknown_Release and checks the
refcount to be 0, but wine returns 1. (test hack attached)
I have done some testing: The first call to GetDepthStencilSurface
increases the refcount of the device, any subsequent call increases the
refcount of the surface.
On release calls the refcount of the surface gets decreased. If the
refcount is 1 the release call decreases the surface refcount AND the
device refcount.
The exact same behaviour shows GetRenderTarget. d3d9 does also the same.
Any ideas how we should implement this behaviour?
Markus
diff --git a/dlls/d3d8/tests/device.c b/dlls/d3d8/tests/device.c
index e735502..3ad8ca0 100644
--- a/dlls/d3d8/tests/device.c
+++ b/dlls/d3d8/tests/device.c
@@ -20,6 +20,7 @@ #define COBJMACROS
#include d3d8.h
#include dxerr8.h
#include wine/test.h
+#include stdio.h
static IDirect3D8 *(WINAPI *pDirect3DCreate8)(UINT);
@@ -183,6 +184,8 @@ static void test_refcount(void)
D3DPRESENT_PARAMETERSd3dpp;
D3DDISPLAYMODE d3ddm;
int refcount = 0, tmp;
+IDirect3DSurface8 *pRenderTarget2 = NULL;
+IDirect3DSurface8 *pStencilSurface2 = NULL;
DWORD decl[] =
{
@@ -217,6 +220,8 @@ static void test_refcount(void)
d3dpp.Windowed = TRUE;
d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD;
d3dpp.BackBufferFormat = d3ddm.Format;
+d3dpp.EnableAutoDepthStencil = TRUE;
+d3dpp.AutoDepthStencilFormat = D3DFMT_D16;
hr = IDirect3D8_CreateDevice( pD3d, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL,
hwnd,
D3DCREATE_SOFTWARE_VERTEXPROCESSING, d3dpp,
pDevice );
@@ -226,6 +231,41 @@ static void test_refcount(void)
refcount = get_refcount( (IUnknown *)pDevice );
ok(refcount == 1, Invalid device RefCount %d\n, refcount);
+printf(hr=%x refDevice=%d\n\n, hr, refcount);
+
+hr = IDirect3DDevice8_GetDepthStencilSurface(pDevice, pStencilSurface2);
+printf(hr=%x refSurface=%d\n, hr, get_refcount( (IUnknown
*)pStencilSurface2) );
+printf(hr=%x refDevice=%d\n\n, hr, get_refcount( (IUnknown *)pDevice) );
+
+hr = IDirect3DDevice8_GetDepthStencilSurface(pDevice, pStencilSurface2);
+printf(hr=%x refSurface=%d\n, hr, get_refcount( (IUnknown
*)pStencilSurface2) );
+printf(hr=%x refDevice=%d\n\n, hr, get_refcount( (IUnknown *)pDevice) );
+
+hr = IDirect3DDevice8_GetRenderTarget(pDevice, pRenderTarget2);
+printf(hr=%x refTarget=%d\n, hr, get_refcount( (IUnknown
*)pRenderTarget2) );
+printf(hr=%x refDevice=%d\n\n, hr, get_refcount( (IUnknown *)pDevice) );
+
+hr = IDirect3DDevice8_GetRenderTarget(pDevice, pRenderTarget2);
+printf(hr=%x refTarget=%d\n, hr, get_refcount( (IUnknown
*)pRenderTarget2) );
+printf(hr=%x refDevice=%d\n\n, hr, get_refcount( (IUnknown *)pDevice) );
+
+refcount = IUnknown_Release(pRenderTarget2);
+printf(hr=%x refTarget=%d\n, hr, refcount );
+printf(hr=%x refDevice=%d\n\n, hr, get_refcount( (IUnknown *)pDevice) );
+
+refcount = IUnknown_Release(pRenderTarget2);
+printf(hr=%x refTarget=%d\n, hr, refcount );
+printf(hr=%x refDevice=%d\n\n, hr, get_refcount( (IUnknown *)pDevice) );
+
+refcount = IUnknown_Release(pStencilSurface2);
+printf(hr=%x refSurface=%d\n, hr, refcount );
+printf(hr=%x refDevice=%d\n\n, hr, get_refcount( (IUnknown *)pDevice) );
+
+refcount = IUnknown_Release(pStencilSurface2);
+printf(hr=%x refSurface=%d\n, hr, refcount );
+printf(hr=%x refDevice=%d\n, hr, get_refcount( (IUnknown *)pDevice) );
+return;
+
/* Buffers */
hr = IDirect3DDevice8_CreateIndexBuffer( pDevice, 16, 0, D3DFMT_INDEX32,
D3DPOOL_DEFAULT, pIndexBuffer );
CHECK_CALL( hr, CreateIndexBuffer, pDevice, ++refcount );
@@ -316,6 +356,6 @@ START_TEST(device)
if (pDirect3DCreate8)
{
test_refcount();
-test_swapchain();
+//test_swapchain();
}
}
Re: [wined3d] windowed mode software cursor position (try 2)
Am Dienstag 17 Oktober 2006 23:04 schrieb Karsten Elfenbein: * correct the software cursor position if the app is running in windowed mode as the cursor coordinates are absolute while the backbuffer is aligned with the app window Your patch adds indentions with tabulators, while the other code in the file uses spaces. Please use for spaces per indention level too pgpFQ015o4uXf.pgp Description: PGP signature
QT 4.x + MinGW under wine
Hi, I tried to install QT 4.2 from www.trolltech.com and MinGW. The installation went fine, but it looks like wine needs a little bit more work. %wine qtdemo.exe fixme:wintab32:WTInfoW (0, 0, 0x0): stub err:x11drv:X11DRV_CreateBitmap Trying to make bitmap with planes=1, bpp=32 fixme:system:SystemParametersInfoW Unimplemented action: 8202 (SPI_GETFONTSMOOTHINGTYPE) fixme:system:SystemParametersInfoW Unimplemented action: 8202 (SPI_GETFONTSMOOTHINGTYPE) fixme:system:SystemParametersInfoW Unimplemented action: 8202 (SPI_GETFONTSMOOTHINGTYPE) fixme:system:SystemParametersInfoW Unimplemented action: 8202 (SPI_GETFONTSMOOTHINGTYPE) fixme:system:SystemParametersInfoW Unimplemented action: 8202 (SPI_GETFONTSMOOTHINGTYPE) fixme:font:ExtTextOutW flags ETO_NUMERICSLOCAL | ETO_NUMERICSLATIN | ETO_PDY unimplemented err:seh:setup_exception stack overflow 0 bytes in thread 0009 eip 9c188b60 esp 00451000 stack 0x451000-0x66 Also see: http://www.turbocat.net/~hselasky/wine --HPS
Re: d3d8: GetDepthStencilSurface/GetRenderTarget refcount issue
Am Mittwoch 18 Oktober 2006 10:18 schrieb Markus Amsler: I'm trying to solve bug 5872 http://bugs.winehq.org/show_bug.cgi?id=5872 BF1942 calls GetDepthStencilSurface/IUnknown_Release and checks the refcount to be 0, but wine returns 1. (test hack attached) I have done some testing: The first call to GetDepthStencilSurface increases the refcount of the device, any subsequent call increases the refcount of the surface. On release calls the refcount of the surface gets decreased. If the refcount is 1 the release call decreases the surface refcount AND the device refcount. The exact same behaviour shows GetRenderTarget. d3d9 does also the same. Any ideas how we should implement this behaviour? Doh - refcounting fun :-/ We know that surfaces, textures, ..., hold a reference to the device, which is what you see with the increased device refcount. We have an IDirect3DDevice?_AddRef call in CreateSurface / CreateTexture... Native seems to have this AddRef call in IDirect3DResource_AddRef: if(oldref == 0) IDirect3DDevice8_AddRef(This-myDevice); I guess this is the first thing we have to change. The next is that the auto depth stencil surface and the implicit render targets seem to be created with a reference count of 0, that is why they have a ref of 1 on the first GetRenderTarget, and why the AddRef from above increases the device refcount. And the implicit surfaces aren't destroyed until the device is destroyed. This will be fun to implement with our release code :-/ It could be that the implicit render target and auto depth stencil COM objects are not COM objects in d3d's internal management and that they are constructed in the first call to GetRenderTarget. But we won't be able to do that. Or well, we can do it in d3d8.dll and d3d9.dll, but not in wined3d.dll. But applications don't see what we are doing in wined3d anyway. What you need for sure is a really good test case to convince AJ that all this is correct ;-) pgppTWc6BwaTK.pgp Description: PGP signature
Re: d3d8: GetDepthStencilSurface/GetRenderTarget refcount issue
On 18/10/06, Stefan Dösinger [EMAIL PROTECTED] wrote: We have an IDirect3DDevice?_AddRef call in CreateSurface / CreateTexture... Native seems to have this AddRef call in IDirect3DResource_AddRef: if(oldref == 0) IDirect3DDevice8_AddRef(This-myDevice); I guess this is the first thing we have to change. Not sure how you read that from the test. The next is that the auto depth stencil surface and the implicit render targets seem to be created with a reference count of 0, that is why they have a ref of 1 on the first GetRenderTarget, and why the AddRef from above increases the device refcount. It could just be that the surface object is only created on the first call to GetRenderTarget. Note that in this test we don't do any actual rendering, so it's not impossible that in a typical application the depth stencil would already be created the moment GetRenderTarget is called. It could be that the implicit render target and auto depth stencil COM objects are not COM objects in d3d's internal management and that they are constructed in the first call to GetRenderTarget. But we won't be able to do that. Or well, we can do it in d3d8.dll and d3d9.dll, but not in wined3d.dll. Sure we can. Regular surfaces are currently created with a callback to d3d8 / d3d9 as well. I wonder what happens if you release the surface you get from GetDepthStencilTarget, and then try to do some rendering with the device.
Re: oleidl.idl must include windows.h and ole2.h if COM_NO_WINDOWS_H is not defined.
Francois Gouget [EMAIL PROTECTED] writes: 2) Or modify these sections so they read: #if !defined(COM_NO_WINDOWS_H) !defined(__WINESRC__) # include windows.h # include ole2.h #endif I think we want that, otherwise we'll end up having to add COM_NO_WINDOWS_H to pretty much every single source file. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Mouse woes and luck of interest
Scott Ritchie wrote: On Wed, 2006-10-18 at 00:34 -0700, Scott Ritchie wrote: On Sat, 2006-10-14 at 23:27 -0600, Vitaliy Margolen wrote: As you know Wine has number of problems with it's mouse handling. Just enough to look at the bugzilla to see how many programs affected. After spending several weeks trying to find and fix this problems I in the dead-end now. Just curious, but do your patches obviate the need for this one: Sorry, forgot the link. As an aside note, whomever made ctrl+enter a hotkey for send my email without confirmation before it's finished in evolution needs to be shot. http://bugs.winehq.org/show_bug.cgi?id=1064 It doesn't start for me at all. Vitaliy.
Re: d3d8: GetDepthStencilSurface/GetRenderTarget refcount issue
We have an IDirect3DDevice?_AddRef call in CreateSurface / CreateTexture... Native seems to have this AddRef call in IDirect3DResource_AddRef: if(oldref == 0) IDirect3DDevice8_AddRef(This-myDevice); I guess this is the first thing we have to change. Not sure how you read that from the test. Not from this test, but I had a test which did this: CreateVertexBuffer(vb) // ref++ Release(vb) // ref-- AddRef(vb) // ref++ CreateVertexBuffer(vb) //ref++ SetStreamSource(device, 0, vb); //ref unchanged Release(vb) //ref-- GetStreamSource(device, 0, vb);//ref++ and check the device refcount after each call, with the results from above. I didn't send the test because it did an incorrect thing(release to 0, then addref). It could just be that the surface object is only created on the first call to GetRenderTarget. Note that in this test we don't do any actual rendering, so it's not impossible that in a typical application the depth stencil would already be created the moment GetRenderTarget is called. Yeah, I mentioned that. But I suspect that the surface resources are created with the device, just that the COM object is constructed on the first GetRenderTarget call. It could be that the implicit render target and auto depth stencil COM objects are not COM objects in d3d's internal management and that they are constructed in the first call to GetRenderTarget. But we won't be able to do that. Or well, we can do it in d3d8.dll and d3d9.dll, but not in wined3d.dll. Sure we can. Regular surfaces are currently created with a callback to d3d8 / d3d9 as well. Yes, but some methods in WineD3D need the back buffer and the front buffer implementation pointer, like Present or LockRect/UnlockRect I wonder what happens if you release the surface you get from GetDepthStencilTarget, and then try to do some rendering with the device. I suspect that it won't have any effect(except that the refcount falls to 0) pgpqQprvf1tNS.pgp Description: PGP signature
Re: d3d8: GetDepthStencilSurface/GetRenderTarget refcount issue
On 18/10/06, Stefan Dösinger [EMAIL PROTECTED] wrote: Yes, but some methods in WineD3D need the back buffer and the front buffer implementation pointer, like Present or LockRect/UnlockRect Well yes, but you don't know if those access the field directly or call GetRenderTarget / GetDepthStencil internally. Btw, this construction looks very similar to what happens when you call GetVertexDeclaration after having set an FVF with SetFVF.
Re: d3d8: GetDepthStencilSurface/GetRenderTarget refcount issue
Hi, Well yes, but you don't know if those access the field directly or call GetRenderTarget / GetDepthStencil internally. Good point Btw, this construction looks very similar to what happens when you call GetVertexDeclaration after having set an FVF with SetFVF. Yup pgprcQbBEFlEt.pgp Description: PGP signature
Re: user [2/2]: add GetRawInputDeviceList stub (try 3)
On Mi, 2006-10-18 at 10:35 +, L. Rahyen wrote:
+
+UINT WINAPI GetRawInputDeviceList(PRAWINPUTDEVICELIST
pRawInputDeviceList, PUINT puiNumDevices, UINT cbSize)
+{
+memset(pRawInputDeviceList, 0, sizeof *pRawInputDeviceList);
+*puiNumDevices = 0;
+FIXME(stub\n);
+return 0;
+}
The FIXME should be the first code in the stub and
is not informative.
I suggest to use:
FIXME((%p, %p, %u) stub\n,
pRawInputDeviceList, puiNumDevices, cbSize);
When a different App use NULL for pRawInputDeviceList
(documented on MSDN as a vaild Parameter) or puiNumDevices,
your stub will still crash, but the FIXME give a usable hint,
where to look.
A small Test will help to make a real Implementation.
-# @ stub GetRawInputDeviceList
+@ stdcall GetRawInputDeviceList(ptr long long)
The second Parameter is used as ptr
--
By by ... Detlef
Re: user [2/2]: add GetRawInputDeviceList stub (try 3)
A small Test will help to make a real Implementation. I already thought about doing full implementation but because this function (its full implementation) isn't very useful in most cases (but maybe I'm wrong?) I probably will spend my free time doing other work in near future... I have few applications and some games that I wish to run under Wine but cannot (because of crashes) so I'm going to fix this (at least I will try to fix them). If you wonder why this is so important to me, then I tell you that I and my brother havn't other options to run Windows applications like games - we cannot reboot to Windows, play game, then return to Linux. So if we cannot run some game under Wine - we cannot run it at all. For some not yet working under Wine applications (like 3ds max) I can use QEmu/VMWare but this is very inconvinient though (only software rendering works, memory wasted and other problems) so I use emulators very rarely. Because I'm programmer all these problems is very good motivation to try myself in Wine development... I suggest to use: FIXME((%p, %p, %u) stub\n, pRawInputDeviceList, puiNumDevices, cbSize); +@ stdcall GetRawInputDeviceList(ptr long long) Thanks for your suggestions!
Re: compiling wine for amd64 on ubuntu dapper 6.06
Just tried to compile wine .23 on dapper 6.06 on AMD 64-bit. Make all terminated with these messages. What does this error mean and how can I get past it? gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_KERNEL32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -gstabs+ -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o wowthunk.o wowthunk.c ../../tools/winebuild/winebuild -D_REENTRANT -fPIC --as-cmd as --32 -o relay16asm.o --relay16 LD_LIBRARY_PATH=../../libs/wine:$LD_LIBRARY_PATH ../../tools/wmc/wmc -i -U -H /dev/null -o nls/winerr_deu.mc.rc nls/winerr_deu.mc LD_LIBRARY_PATH=../../libs/wine:$LD_LIBRARY_PATH ../../tools/wmc/wmc -i -U -H /dev/null -o nls/winerr_enu.mc.rc nls/winerr_enu.mc ../../tools/winebuild/winebuild -D_REENTRANT -fPIC --as-cmd as --32 --dll -o krnl386.exe.spec.o --dll-name kernel --main-module kernel32.dll --res version16.res --export ./krnl386.exe.spec LD_LIBRARY_PATH=../../libs/wine:$LD_LIBRARY_PATH ../../tools/wrc/wrc --nostdinc -I. -I. -I../../include -I../../include -D__WINESRC__ -D_KERNEL32_ -fokernel.res kernel.rc ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./kernel32.spec comm.drv.spec.o krnl386.exe.spec.o stress.spec.o system.drv.spec.o toolhelp.spec.o win87em.spec.o windebug.spec.o atom16.o error16.o kernel16.o registry16.o toolhelp16.o win87em.o actctx.o atom.o change.o comm.o computername.o console.o cpu.o debugger.o dosmem.o editline.o environ.o except.o fiber.o file.o file16.o format_msg.o global16.o heap.o instr.o kernel_main.o lcformat.o local16.o locale.o lzexpand.o module.o ne_module.o ne_segment.o oldconfig.o path.o powermgnt.o process.o profile.o pthread.o relay16.o resource.o resource16.o selector.o snoop16.o stress.o string.o sync.o syslevel.o system.o tape.o task.o thread.o thunk.o time.o toolhelp.o utthunk.o version.o virtual.o volume.o vxd.o windebug.o wowthunk.o relay16asm.o kernel.res -Wl,--image-base,0x7b80 -o kernel32.dll.so -lntdll ../../libs/port/libwine_port.a -L/lib32 -L/usr/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32 /usr/sbin/prelink.bin: kernel32.dll.so: Unknown stabs code 0x2e make[2]: Leaving directory `/tmp/wine-0.9.23/dlls/kernel32' make[1]: Leaving directory `/tmp/wine-0.9.23/dlls' make: *** [dlls] Error 2
Re: fix for the winemp3 module
Mike McCormack wrote: Deun wrote: Changelog by Denis Huguet ([EMAIL PROTECTED]) * 2006/10/17 : Major diff between winemp3's layer3.c file and the one from MPlayer-1.0pre7try2/mp3lib/layer3.c for fixing decoding glitches found out when opening mp3 file with GoldWave 4.21 with wine-0.9.22 (same with 0.9.23) Hi Denis, That's a big change. It would be nicer to submit it piece by piece, fix by fix, clarifying which bug you are fixing and to get rid of the extraneous #if 0's and C++ comments. That would make regression analysis easier in case the patch introduces a bug. thanks, Mike also, mplayer is GPL:ed, so you cannot use their work in wine (which is LGPL) so the patch has to be made from the code of the original library (mpglib), which is LGPL A+
Re: wineconsole[3/6]: remove spaces from the ends of lines while copying to the clipboard
Mikołaj Zalewski wrote:
This is very practical and matches the Windows behaviour
diff --git a/programs/wineconsole/user.c b/programs/wineconsole/user.c
index e1efda2..557ccfc 100644
--- a/programs/wineconsole/user.c
+++ b/programs/wineconsole/user.c
@@ -689,8 +689,15 @@ static voidWCUSER_CopySelectionToClipbo
for (y = 0; y h; y++, c.Y++)
{
- ReadConsoleOutputCharacter(data-hConOut, p[y * w], w - 1, c,
NULL);
- p[y * w + w - 1] = (y h - 1) ? '\n' : '\0';
+ LPWSTR end;
+ ReadConsoleOutputCharacter(data-hConOut, p, w - 1, c, NULL);
+
+ /* strip spaces from the end of the line */
+ end = p + w - 1;
+ while (end p *(end - 1) == ' ')
+ end--;
+ *end = (y h - 1) ? '\n' : '\0';
+ p = end + 1;
}
GlobalUnlock(hMem);
SetClipboardData(CF_UNICODETEXT, hMem);
did you check that this behavior is done for every mode of the console ?
A+
Re: wineconsole[4/6]: allow making selections with a mouse also when not in the QuickEdit mode
Mikołaj Zalewski wrote:
The user may start the selection from the popup menu. The mouse should
work then
diff --git a/programs/wineconsole/user.c b/programs/wineconsole/user.c
index 557ccfc..c4250e5 100644
--- a/programs/wineconsole/user.c
+++ b/programs/wineconsole/user.c
@@ -1116,12 +1116,14 @@ static LRESULT CALLBACK WCUSER_Proc(HWND
WCUSER_GenerateKeyInputRecord(data, uMsg == WM_SYSKEYDOWN, wParam,
lParam, TRUE);
break;
case WM_LBUTTONDOWN:
-if (data-curcfg.quick_edit)
+if (data-curcfg.quick_edit || PRIVATE(data)-has_selection)
{
if (PRIVATE(data)-has_selection)
+WCUSER_SetSelection(data, 0);
+
+if (data-curcfg.quick_edit PRIVATE(data)-has_selection)
{
PRIVATE(data)-has_selection = FALSE;
-WCUSER_SetSelection(data, 0);
}
else
{
@@ -1137,7 +1139,7 @@ static LRESULT CALLBACK WCUSER_Proc(HWND
}
break;
case WM_MOUSEMOVE:
-if (data-curcfg.quick_edit)
+if (data-curcfg.quick_edit || PRIVATE(data)-has_selection)
{
if (GetCapture() == PRIVATE(data)-hWnd PRIVATE(data)-has_selection
(wParam MK_LBUTTON))
@@ -1151,14 +1153,13 @@ static LRESULT CALLBACK WCUSER_Proc(HWND
}
break;
case WM_LBUTTONUP:
-if (data-curcfg.quick_edit)
+if (data-curcfg.quick_edit || PRIVATE(data)-has_selection)
{
if (GetCapture() == PRIVATE(data)-hWnd PRIVATE(data)-has_selection
(wParam MK_LBUTTON))
{
WCUSER_MoveSelection(data, PRIVATE(data)-selectPt1,
WCUSER_GetCell(data, lParam));
ReleaseCapture();
-PRIVATE(data)-has_selection = FALSE;
this looks suspicious to me ? how to do end the selection ? the only
time you do it is when a second button down :-/
}
}
else
Re: wineconsole[5/6]: when selection with the mouse, any key except for Enter should cancel the selection
Mikołaj Zalewski wrote:
diff --git a/programs/wineconsole/user.c b/programs/wineconsole/user.c
index c4250e5..19a1625 100644
--- a/programs/wineconsole/user.c
+++ b/programs/wineconsole/user.c
@@ -705,6 +705,12 @@ static voidWCUSER_CopySelectionToClipbo
CloseClipboard();
}
+static void WCUSER_EndSelection(const struct inner_data* data)
+{
+PRIVATE(data)-has_selection = FALSE;
+WCUSER_SetSelection(data, 0);
+}
+
/**
* WCUSER_PasteFromClipboard
*
@@ -935,15 +941,22 @@ static void WCUSER_HandleSelectionKey(st
if (!down) return;
+if (PRIVATE(data)-mouse_selection)
+{
+if (state == 0 wParam == VK_RETURN)
+WCUSER_CopySelectionToClipboard(data);
+WCUSER_EndSelection(data);
+return;
+}
+
switch (state)
{
case 0:
switch (wParam)
{
case VK_RETURN:
-PRIVATE(data)-has_selection = FALSE;
-WCUSER_SetSelection(data, 0);
WCUSER_CopySelectionToClipboard(data);
+WCUSER_EndSelection(data);
break;
case VK_RIGHT:
c1 = PRIVATE(data)-selectPt1;
@@ -1131,6 +1144,7 @@ static LRESULT CALLBACK WCUSER_Proc(HWND
SetCapture(PRIVATE(data)-hWnd);
WCUSER_SetSelection(data, 0);
PRIVATE(data)-has_selection = TRUE;
+PRIVATE(data)-mouse_selection = TRUE;
}
}
else
@@ -1292,6 +1306,7 @@ static LRESULT CALLBACK WCUSER_Proc(HWND
PRIVATE(data)-selectPt2.X = PRIVATE(data)-selectPt2.Y = 0;
WCUSER_SetSelection(data, 0);
PRIVATE(data)-has_selection = TRUE;
+PRIVATE(data)-mouse_selection = FALSE;
break;
case IDS_COPY:
if (PRIVATE(data)-has_selection)
diff --git a/programs/wineconsole/winecon_user.h
b/programs/wineconsole/winecon_user.h
index aa86338..1744fcd 100644
--- a/programs/wineconsole/winecon_user.h
+++ b/programs/wineconsole/winecon_user.h
@@ -37,6 +37,7 @@ struct inner_data_user {
HBITMAP cursor_bitmap; /* bitmap used for the caret */
BOOLhas_selection; /* an area is being selected
(selectPt[12] are edges of the rect) */
+BOOLmouse_selection;/* the selection was made with a mouse
*/
COORD selectPt1; /* start (and end) point of a mouse
selection */
COORD selectPt2;
};
as a principle, why do oppose keyboard selection to mouse selection
looks to me you could in principle do both... so any key except return,
arrow keys should end the selection
and you woun't need the extraneous mouse_selection
Re: wineconsole[4/6]: allow making selections with a mouse also when not in the QuickEdit mode
case WM_LBUTTONUP:
-if (data-curcfg.quick_edit)
+if (data-curcfg.quick_edit || PRIVATE(data)-has_selection)
{
if (GetCapture() == PRIVATE(data)-hWnd
PRIVATE(data)-has_selection
(wParam MK_LBUTTON))
{
WCUSER_MoveSelection(data, PRIVATE(data)-selectPt1,
WCUSER_GetCell(data, lParam));
ReleaseCapture();
-PRIVATE(data)-has_selection = FALSE;
this looks suspicious to me ? how to do end the selection ? the only
time you do it is when a second button down :-/
The selection is cancelled if the hits Enter to copy the data to the
clipboard (or after the later patch hit any other key to cancel). The
current behaviour is strange as why to select a rectangle with a mouse
if it will be unselected on WM_LBUTTONUP? Currectly the user would need
to keep the mouse button down and press Enter to copy the data and have
any use of the mouse selection.
Mikolaj Zalewski
Re: wineconsole[5/6]: when selection with the mouse, any key except for Enter should cancel the selection
as a principle, why do oppose keyboard selection to mouse selection looks to me you could in principle do both... so any key except return, arrow keys should end the selection and you woun't need the extraneous mouse_selection I wanted to make it in the same way as on Windows. But I think it's a good idea to allow keyboard movements on mouse selections and always canceling the selection with the keyboard. I'll rewrite the patch and resend it. Mikolaj Zalewski
Re: wineconsole[3/6]: remove spaces from the ends of lines while copying to the clipboard
did you check that this behavior is done for every mode of the console ? A+ What do you mean by every mode? Mikolaj Zalewski
Re: wineconsole[3/6]: remove spaces from the ends of lines while copying to the clipboard
Mikołaj Zalewski wrote: did you check that this behavior is done for every mode of the console ? A+ What do you mean by every mode? Mikolaj Zalewski consoles have several modes (set SetConsoleMode()), which may interfer with this behavior and btw, a test case for windows behavior would also be welcomed A+
Re: wineconsole[4/6]: allow making selections with a mouse also when not in the QuickEdit mode
Mikołaj Zalewski wrote:
case WM_LBUTTONUP:
-if (data-curcfg.quick_edit)
+if (data-curcfg.quick_edit || PRIVATE(data)-has_selection)
{
if (GetCapture() == PRIVATE(data)-hWnd
PRIVATE(data)-has_selection
(wParam MK_LBUTTON))
{
WCUSER_MoveSelection(data, PRIVATE(data)-selectPt1,
WCUSER_GetCell(data, lParam));
ReleaseCapture();
-PRIVATE(data)-has_selection = FALSE;
this looks suspicious to me ? how to do end the selection ? the only
time you do it is when a second button down :-/
The selection is cancelled if the hits Enter to copy the data to the
clipboard (or after the later patch hit any other key to cancel). The
current behaviour is strange as why to select a rectangle with a mouse
if it will be unselected on WM_LBUTTONUP? Currectly the user would
need to keep the mouse button down and press Enter to copy the data
and have any use of the mouse selection.
Mikolaj Zalewski
but your code doesn't release the selection on button up, which is
rather strange when you do only mouse selection
A+
Re: wineconsole[4/6]: allow making selections with a mouse also when not in the QuickEdit mode
but your code doesn't release the selection on button up, which is rather strange when you do only mouse selection A+ I've checked it and currently the whole section is dead code as on WM_LBUTTONUP the (wParamMK_LBUTTON) is always false. However if I remove this condition I think my code is correct. I release the mouse capture - that's enough as the handler for WM_MOUSEMOVE and WM_LBUTTONUP checks if GetCapture() == PRIVATE(data)-hWnd. Setting has_selection = FALSE would means that the seletion has been removed - there would be no way to copy it to the clipboard. Also the window is not updated to show that the selection is removed. I'll check if the spaces are removed for other console modes. I don't know if it's possible to write an automatic test as this requires mouse interaction, I don't know how to get a hWnd of a console windows. Also it would fail on wine as by default it starts the ncurses backend. Mikolaj Zalewski
Bug #6439: requesting explanation of GDI_CheckNotLock in order to fix
I would like to draw attention to bug #6439 (http://bugs.winehq.org/show_bug.cgi?id=6439) in which Enterprise Architect 6.5 (trial version at http://www.sparxsystems.com.au/bin/easetup.exe) crashes with a debug assertion on _CheckNotSysLevel, as detailed in the bug report. From the winedbg trace, the inmediate cause of this debug assertion is the call of GDI_CheckNotLock() at the very start of CreateCompatibleDC(), when the stack of callers in the same thread have already taken references to GDI objects via GDI_GetObjPtr(). The basic question is: why is _CheckNotSysLevel required at CreateCompatibleDC()? What kind of damage might be caused by the removal of the check (in CreateCompatibleDC() and DeleteDC())? On Enterprise Architect, the removal of the assertions allow the app to load the sample file (EAExample.eap) correctly without crashing, and everything appears to work normally. -- The following cryptic message was allegedly found in the inner edge of a Windows XP installation CD: 4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420 7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074 6865206461726B6E6573732062696E64207468656D2E0A It is rumored that only a true Unix Wizard can decypher this mysterious message, which supposedly encodes the true nature and purpose of the software.
use wine as screensaver for x
Hi. While waiting for the commit of my localspl-Patches, i want to picked up an fun project: Has anyone an Idea, how to modify user32.dll and winex11.drv to open a Window, when I already have the X11 Window-ID (example: XSCREENSAVER_WINDOW=0x280020)? My Idea is to include the wrapper code in explorer.exe and use similar code as already present for /desktop. The Window width and height is not known on startup and does not match a well-known Desktop Size. I think, I need to add an Export to winex11.drv to fetch the size and reuse X11DRV_create_desktop() or add an Export to someting similar as X11DRV_create_desktop(). The client registers a Window Class with a known name (WindowsScreenSaverClass) and then CreateWindowEx must be redirected to the already created X11-Window. A lightwight solution might be to implement minimal features from scrsave.lib (RegisterClass) in explorer.exe and then call ScreenSaverProc directly. Any Ideas? -- By by ... Detlef
[wined3d] fix for BltOverride
This change for the non scaled BltOverride should allow correct usage of src and dest rect. So the content ends up where it is supposed to be. It is needed for a correct Frontbuffer capture while running in a window. (next mail) bltfix.diff Description: Binary data
[wined3d] GetFrontBufferData
This patch depends on the BltOverride change. It allows the apps to grab the FrontBufferData. (for screen captures) Todo: - implement a windowed mode switch Karsten getfrontbufferblt.diff Description: Binary data
Re: [Korean] Use the SUBLANG_NEUTRAL in Korean resources.
2006-10-19 (Wed), 07:39 +0900, Byeong-Sik Jeon wrote: At [use SUBLANG_NEUTRAL in French resources], 2006-10-18 (Wed), 20:47 +0200, Jonathan Ernst wrote: Thanks to Mikolaj Zalewski for spotting it. It's great. It's important. This patch solves the some font problem for korean wine beginners. Oops. I'm sorry. This patch don't solve the some font problem. It was my rash testing...
Re: oleidl.idl must include windows.h and ole2.h if COM_NO_WINDOWS_H is not defined.
Francois Gouget wrote: On Wed, 18 Oct 2006, Alexandre Julliard wrote: Francois Gouget [EMAIL PROTECTED] writes: 2) Or modify these sections so they read: #if !defined(COM_NO_WINDOWS_H) !defined(__WINESRC__) # include windows.h # include ole2.h #endif I think we want that, otherwise we'll end up having to add COM_NO_WINDOWS_H to pretty much every single source file. Actually, in the PSDK there seems to be a correlation between COM_NO_WINDOWS_H and idl files. It's not 100% but that may be just be because they don't ship all the idl files. Also, the COM_NO_WINDOWS_H #ifdef is not present in the idl file, suggesting that it is being added by midl. Yes, this is correct. -- Rob Shearman
Re: [Korean] Use the SUBLANG_NEUTRAL in Korean resources.
It should make no differance for Korean is you use SUBLANG_NEUTRAL or SUBLANG_DEFAULT as there is only one sublang. SUBLANG_NEUTRAL is a fallback that is used if no translation is available in the user's selected sublang. In can be used for locales that have many sublangs (e.g. French have French (France), French (Belgian), French (Canada), French (Swiss) etc) but the language is the same so it's enough to make one translation. While making the translations statistics I've found that SUBLANG_NEUTRAL and SUBLANG_DEFAULT are often randomly mixed. Maybe I should make a wiki page where people knowing the language could write if it requires separate translations for each sublang or one translation with SUBLANG_NEUTRAL and then update all the files? Mikolaj Zalewski
Re: Bug #6439: requesting explanation of GDI_CheckNotLock in order to fix
Alex Villacís Lasso wrote: I would like to draw attention to bug #6439 Why that bug in particular? Can we pick any other? You seems to really like to copy list of all of your bugs. Hell that's turn this list into another Bugzilla! You know, I wanted to look at this bug when I get home. And now after reading your email ... I just added you to my list of bug submitters to ignore bugs from. Vitaliy
