Question from new developer
I submitted bug 31753 for an application that I use, and started
making an attempt to fix it. I started with the last few messages
from the log:
fixme:win:LockWindowUpdate (0x501c4), partial stub!
fixme:win:LockWindowUpdate ((nil)), partial stub!
wine: Unhandled page fault on read access to 0x0023 at address
0x78680087 (thread 0009), starting debugger...
Looking at LockWindowUpdate(), I discovered that it had no conformance
tests. I wrote a few covering all the possible scenarios I could
think of (only 4 of them), and ran them on wine as well as cross
compiling them and running on XP. To my surprise, one of the tests
fails on wine, but passes on WinXP! This was great news, so I dug a
little further. Specifically the problem was attempting to do a
unlock operation by passing NULL, when the the function was already
unlocked. Windows treats this as an error and returns 0, while wine
returns 1.
So I fixed it, patch is attached (also at:
https://dl.dropbox.com/u/477050/0001-Fixed-LockWindowUpdate.txt)
I have two big questions:
1. I discovered later that I don't think this is the root of my
original bug - and in fact doesn't seem to affect behavior of my
program. Is it still worth submitting? I do believe it alleviates
the need for the fixme in the LockWindowUpdate function.
2. If it is worth submitting, could someone take a look at it and
point out all the dumb things I've done? I'm happy with the logic of
the code, but I'm sure I've done something horribly wrong in terms of
doing it the preferred way.
Thanks,
Chris Teague
From 84445fb85a4a22588af798195fcefd7db31b17fd Mon Sep 17 00:00:00 2001
From: root r...@kona-linux.qualcomm.com
Date: Fri, 21 Sep 2012 23:24:43 +
Subject: Fixed LockWindowUpdate
---
dlls/user32/painting.c| 43 +
dlls/user32/tests/Makefile.in |1 +
dlls/user32/tests/painting.c | 103 +
3 files changed, 128 insertions(+), 19 deletions(-)
create mode 100644 dlls/user32/tests/painting.c
diff --git a/dlls/user32/painting.c b/dlls/user32/painting.c
index 1a6de87..c70298e 100644
--- a/dlls/user32/painting.c
+++ b/dlls/user32/painting.c
@@ -1154,32 +1154,37 @@ HWND WINAPI WindowFromDC( HDC hdc )
*/
BOOL WINAPI LockWindowUpdate( HWND hwnd )
{
-static HWND lockedWnd;
+ static HWND lockedWnd;
-FIXME((%p), partial stub!\n,hwnd);
-
-USER_Lock();
-if (lockedWnd)
+ USER_Lock();
+ if (lockedWnd)
{
-if (!hwnd)
-{
-/* Unlock lockedWnd */
-/* FIXME: Do something */
-}
-else
-{
-/* Attempted to lock a second window */
-/* Return FALSE and do nothing */
-USER_Unlock();
-return FALSE;
+ if (hwnd)
+ {
+ /* Attempted to lock a second window */
+ /* Return FALSE and do nothing */
+ USER_Unlock();
+ return FALSE;
}
}
-lockedWnd = hwnd;
-USER_Unlock();
-return TRUE;
+ else /* Not locked */
+{
+ if (!hwnd)
+ {
+ /* Attempted to unlock while already unlocked */
+ /* Return FALSE and do nothing */
+ USER_Unlock();
+ return FALSE;
+ }
+
+}
+ lockedWnd = hwnd;
+ USER_Unlock();
+ return TRUE;
}
+
/***
* RedrawWindow (USER32.@)
*/
diff --git a/dlls/user32/tests/Makefile.in b/dlls/user32/tests/Makefile.in
index eb5789a..24ff612 100644
--- a/dlls/user32/tests/Makefile.in
+++ b/dlls/user32/tests/Makefile.in
@@ -17,6 +17,7 @@ C_SRCS = \
menu.c \
monitor.c \
msg.c \
+ painting.c \
resource.c \
scroll.c \
static.c \
diff --git a/dlls/user32/tests/painting.c b/dlls/user32/tests/painting.c
new file mode 100644
index 000..8b08ea2
--- /dev/null
+++ b/dlls/user32/tests/painting.c
@@ -0,0 +1,103 @@
+#include assert.h
+#include windows.h
+#include wine/test.h
+#include winbase.h
+
+/* Maybe auxiliary functions and definitions here */
+static HINSTANCE hinst;
+static HWND create_editcontrol (DWORD style, DWORD exstyle)
+{
+ HWND handle;
+
+ handle = CreateWindowEx(exstyle,
+ EDIT,
+ Test Text,
+ style,
+ 10, 10, 300, 300,
+ NULL, NULL, hinst, NULL);
+ ok (handle != NULL, CreateWindow EDIT Control failed\n);
+ assert (handle);
+ if (winetest_interactive)
+ShowWindow (handle, SW_SHOW);
+ return handle;
+}
+
+/* lock valid window, nothing locked */
+static void test_lockwindowupdate_1(void)
+{
+ HWND handle;
+ BOOL ret;
+
+ handle = create_editcontrol(ES_AUTOHSCROLL | ES_AUTOVSCROLL, 0);
+ assert (handle);
+
+ /* normal, successful window lock */
+ ret = LockWindowUpdate(handle);
+ ok(0 != ret, LockWindowUpdate: scenario 1 failed to lock\n);
+
+ /* locking NULL when a window is locked
Re: WineHQ on CMS/Framework
We had same question in the ReactOS web site. We have our own in-house developed CMS called RosCMS now, however there is a strong desire to change it to something maintained by 3rd party, so Drupal and Typo3 were considered. Two prototype websites were made, one using Drupal7 and another one (more recent and more complete) using Typo3. What's important is that we have a substantial set of interconnected services too: * JIRA (formerly Bugzilla, integrated authentication with the main website) * Mailing lists (no need for integration) * FishEye as a source code browser (integrated) * GIT mirror with source code browser (no need for integration) * Doxygen source code browser (no need for integration) * MediaWiki (fully integrated, single sign-on) * Forums (fully integrated, single sign-on) * Compatibility database (integrated with RosCMS, single sign-on, however it's ported neither to D7 nor T3) * Test manager (http://www.reactos.org/testman ) * Paste service (fully integrated to prevent spam, single sign-on) * Trunk builds download manager (http://www.reactos.org/getbuilds/ ) If any help is needed, let me know, would be glad to share. Best regards, Aleksey Bragin. On 22.09.2012 7:32, Kyle Auble wrote: After working on the wiki for a while, I finally wanted to ask about possibly moving WineHQ to a CMS or web framework. First off, while there are a couple of mentions on the wiki and mailing lists, is there still much interest in doing this? If there is, I think the second question is which kind of system do we want to use? While http://wiki.winehq.org/WinehqDesign mentions Drupal, which has a lot of plugins and features for easy editing, I've read that a CMS can become a hassle if your website needs to do more complex things than serving regular chunks of content. WineHQ provides a bug-tracker, a forum, a wiki, mailing lists, source-code browsers, and other tools besides static content, with lots of interconnections between them. If we did go with a web framework, we could still probably run a CMS on top of it for the AppDB and static pages.
Re: Question from new developer
On Fri, Sep 21, 2012 at 8:41 PM, Chris Teague chris.tea...@gmail.com wrote: I submitted bug 31753 for an application that I use, and started making an attempt to fix it. I started with the last few messages from the log: fixme:win:LockWindowUpdate (0x501c4), partial stub! fixme:win:LockWindowUpdate ((nil)), partial stub! wine: Unhandled page fault on read access to 0x0023 at address 0x78680087 (thread 0009), starting debugger... Looking at LockWindowUpdate(), I discovered that it had no conformance tests. I wrote a few covering all the possible scenarios I could think of (only 4 of them), and ran them on wine as well as cross compiling them and running on XP. To my surprise, one of the tests fails on wine, but passes on WinXP! This was great news, so I dug a little further. Specifically the problem was attempting to do a unlock operation by passing NULL, when the the function was already unlocked. Windows treats this as an error and returns 0, while wine returns 1. So I fixed it, patch is attached (also at: https://dl.dropbox.com/u/477050/0001-Fixed-LockWindowUpdate.txt) I have two big questions: 1. I discovered later that I don't think this is the root of my original bug - and in fact doesn't seem to affect behavior of my program. Is it still worth submitting? I do believe it alleviates the need for the fixme in the LockWindowUpdate function. The fixme is there because the function is far away from implemented, you can read more about it at the long standing bug 52 ( http://bugs.winehq.org/show_bug.cgi?id=52 ). IMO adding tests that prove something is wrong are always good. 2. If it is worth submitting, could someone take a look at it and point out all the dumb things I've done? I'm happy with the logic of the code, but I'm sure I've done something horribly wrong in terms of doing it the preferred way. You should join all tests in the same function and use an existing file. You need to fix the whitespace issues, you didn't follow the surrounding code style (possibly your editor was configured differently from the file). You are also not freeing the created windows. Thanks, Chris Teague I'm not used to reviewing patches, I hope someone else can do a better review. Best wishes, Bruno
Re: comctl32/listview: update dwStyle before checking for scrollbar
2012/9/22 Daniel Jelinski djelins...@gmail.com: 2012/9/22 Nikolay Sivov nsi...@codeweavers.com: And apparently we have code in WM_STYLECHANGED handler to deal with scroll bars: --- if (((lpss-styleOld WS_HSCROLL) != 0) ((lpss-styleNew WS_HSCROLL) == 0)) ShowScrollBar(infoPtr-hwndSelf, SB_HORZ, FALSE); if (((lpss-styleOld WS_VSCROLL) != 0) ((lpss-styleNew WS_VSCROLL) == 0)) ShowScrollBar(infoPtr-hwndSelf, SB_VERT, FALSE); --- these lines were edited 10 years ago last time, sure it could be a noop but that raises a question why it's here. Dead code. I meant to remove these in the next patch, since there are no bugs against scrollbars in listview. I guess user32 was way less capable back then. Now that I think about it, it's not exactly dead code - it will be executed when someone tries to hide scrollbars by setting window style. Needs a more thorough review. Regards, Daniel
re: Question from new developer
Chris wrote: 1. I discovered later that I don't think this is the root of my original bug - and in fact doesn't seem to affect behavior of my program. Is it still worth submitting? Generally, fixes are more likely to get committed when they don't break anything (did you run all the conformance tests?), their tests cases pass on all versions of windows (did you send your patch to testbot?), improve the behavior of a real program (I don't think you have demonstrated this yet), and are written from a position of relatively deep understanding. So you might want to find a more solid fix for your first submission. Welcome, and good luck! - Dan
Re: WineHQ on CMS/Framework
Sun, Sep 23, 2012 04:33, Aleksey Bragin wrote: Two prototype websites were made, one using Drupal7 and another one (more recent and more complete) using Typo3. What's important is that we have a substantial set of interconnected services too: I honestly haven't heard of Typo3 before now (I guess it really hasn't caught on outside the German-speaking world yet), but my first impression is that may be closer to what we would want than Drupal. I've heard that Drupal can be very brittle and hard to use if your design doesn't fit a template. The fact that your T3 prototype is more complete despite being a younger site seems like a hint that it has been more productive for you. Being able to integrate most of your services with the CMS is also very reassuring. Have you come across a situation where you think having a framework would have helped? The main scenario I'm picturing is if someday we wanted to combine data from different parts of the website (for example, bugzilla queries along with related git patches). That may be overdoing things, but I feel like those cross-connections are one of the main things that could really help WineHQ. Right now it seems like there's a lot of good information, but it may be spread out over forum threads, mailing lists, the wiki, AppDB, etc. with no simple way to connect the dots (even after using search). - Kyle
Re: [1/8] windowscodecs: Add some tests for GIF palette.
Series looks good to me.
Re: [7/8] windowscodecs: Calculate transparent color index for global GIF palette.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=21729 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
