Joris Huizer wrote:
On 10/05/2011 04:43 PM, Marko Nikolic wrote:
static void test_mccolor_types(HWND hWndDateTime, int mccolor_type, const
char* mccolor_name)
{
-LRESULT r;
-COLORREF theColor, prevColor;
+//LRESULT r;
+COLORREF theColor, prevColor, crColor;
Please
David Laight wrote:
On Fri, May 27, 2011 at 10:09:04PM +0400, Nikolay Sivov wrote:
On Fri, May 27, 2011 at 5:16 PM, Marko Nikolic grk...@gmail.com wrote:
---
?dlls/comctl32/tests/treeview.c | ? ?6 +++---
?1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/dlls/comctl32
Alexandre Julliard wrote:
Marko Nikolic grk...@gmail.com writes:
In case of test failure, expected and received values are traced.
Format for the two values was different, corrected so both values
are traced as hex.
Error values are in general more useful in decimal.
You are right, I
Henri Verbeet wrote:
On 14 September 2010 15:44, Mike Frysinger vap...@gentoo.org wrote:
note: i couldnt find a statement of what C standard wine aims for. if
it is attempting pre-c99, then this will have to be done differently.
perhaps introducing a project-wide define like VARARRAY which
Andrey Turkin wrote:
On Monday 23 August 2010 13:16:07 Michael Stefaniuc wrote:
IMHO gcc is *wrong* in emitting a warning there. sizeof(PCMWAVEFORMAT)
is a compile time constant and gcc can see that sizeof(PCMWAVEFORMAT)
falls well inside the number range expressible by a LONG. Logically
Nikolay Sivov wrote:
On 8/21/2010 12:18, Marko Nikolic wrote:
Nikolay Sivov wrote:
On 8/20/2010 20:04, Marko Nikolic wrote:
Changed variable type to match function return type.
---
dlls/appwiz.cpl/appwiz.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
Nikolay Sivov wrote:
On 8/20/2010 20:04, Marko Nikolic wrote:
Changed variable type to match function return type.
---
dlls/appwiz.cpl/appwiz.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/dlls/appwiz.cpl/appwiz.c b/dlls/appwiz.cpl/appwiz.c
index ffd2b24
Paul Vriens wrote:
On 07/14/2010 09:40 AM, Damjan Jovanovic wrote:
Changelog:
* wineboot: fix Serbian Latin translation
Damjan Jovanovic
Hi Damjan,
Thanks for looking into this. I guess we need the pragma statement now
as you are introducing UTF-8, not?
I did talk to Nenad about
Hi,
I have found in wine documentation that it is recommended to avoid long data
type, since it is different in Win64 and Unix64. This is reasonable,
however, is there some similar policy regarding size_t/ssize_t usage?
Those types are often defined as long type, so they could produce the same