1. editor->hWnd may be NULL for windowless richedit controls, but you
code doesn't seem to take that into consideration.
2. The style flags that you get from GetWindowLongW should probably
come from the cached values in editor->styleFlags.
The main reason why GetWindowLongW is used there is that
Nikolay Sivov пишет:
If a band has an empty string, wine allocates a padding space in
lpBand->rcCapText that causes an offset in a band.
It looks like a workaround, if get/set text behaves ok now (no tests
exist I suppose) then
the only place to be changed is this rectangle dimensions.
Why do
Nikolay Sivov пишет:
It looks like you need to add a simple test like that:
- add band with empty string and RBBIM_TEXT mask of course;
- query band data back with RB_GETBANDINFO and check this lpText field.
If it's really NULL (e.g. your buffer didn't change) instead of empty
string you shou
Nikolay Sivov пишет:
Where did you test that it isn't stored?
The patch fixes a bug when wine allocates an extra space for a band with
an empty string. I replaced NULL by "" in the size test to show the
native realization doesn't change its behavior unlike wine in this case.
James Hawkins wrote:
> There are several things wrong with this patch:
> * It's way too large. Please split it up.
> * No tests. You need to write tests to back up these changes.
Are tests necessary for simple stubs? I don't know what kind of
tests can be written for stubs, except tests for wrong
>From dd25a83863f492e6c804a46f339e5c22b7d0e3dd Mon Sep 17 00:00:00 2001
From: Sergey Khodych <[EMAIL PROTECTED]>
Date: Sat, 24 May 2008 21:29:05 +0300
Subject: BitBlt returns TRUE when drawing outside of the clipping or visible region.
---
dlls/winex11.drv/bitblt.c |6 --
> To reply to myself. I've missed the fact that if the requested format is
> the
> same as Wine's internal format it will be a simple memcpy. I did not
> want to
> penalize most dinput applications that just use default keyboard format
> (array
> of 256 bytes).
>
What do you think about using c
> I'd like to see tests for this. Also lots of programs will break because
> they won't get some not significant property. No short - don't do this.
But wine return a garbage value also for significant property. This
value may cause undefined behavior of application. The patch will make
errors
> No, there are 2 separate implementations - one ascii another unicode. During
> the object creation one would specify either ascii or unicode RIID.
Objects IDirectInputDevice8W and IDirectInputDevice8A has function
GetProperty. This function get struct of type DIPROPSTRING as
input/output parame
> In ascii function you are calling unicode function and copying it's output
> (unicode string) to the ascii string buffer. This is wrong. Also because
> these functions deal with strings you have to implement both ascii and
> unicode functions at the same time. You can't forward one to the othe
>
>> ...
>> +hr = SysKeyboardWImpl_GetObjectInfo(
>> (LPDIRECTINPUTDEVICE8W)iface , &didoi,
>> + ps->diph.dwObj,
>> ps->diph.dwHow );
>
> You mixing unicode and ascii. Also if you are implementing
> SysKeyboardAImpl_GetPropert
A possibility of using custom data format, for any type of devices, is
described in DirectX SDK documentation.
For example Monolith's F.E.A.R. use this method.
> Any particular reason for this? Do you have a program that sets different
> data format? The reason I ask - copying 256 bytes is much
12 matches
Mail list logo
