Christian Neumair chris@gnome-de.org writes:
this patch improves dc:LockWindowUpdate (windows/dce.c); locking other windows still not possible, though.
Apart from removing the fixme this doesn't appear to change anything at all. What were you trying to fix?
Am Fre, 2002-10-18 um 00.19 schrieb Alexandre Julliard:
Christian Neumair chris@gnome-de.org writes:
this patch improves dc:LockWindowUpdate (windows/dce.c); locking other windows still not possible, though.
Apart from removing the fixme this doesn't appear to change anything at all. What were you trying to fix?
- /* Unlock lockedWnd */ - /* FIXME: Do something */ + /* Unlock lockedWnd */ + lockedWnd = 0; + + USER_Unlock(); + return TRUE;
The version in HEAD actually doesn't unlock the window inside the function but just exits the if loop. The patch adds an unlock function (see msdn, when not passing hwnd, the active window should be unlocked) and moves the stub to the place where it belongs. Basically this makes the code easier to read. If you want we can remove the whole if (!hwnd) code because if hwnd is 0, lockedWnd = hwnd does the right thing, too.
regs, Chris
Christian Neumair chris@gnome-de.org writes:
The version in HEAD actually doesn't unlock the window inside the function but just exits the if loop. The patch adds an unlock function (see msdn, when not passing hwnd, the active window should be unlocked) and moves the stub to the place where it belongs. Basically this makes the code easier to read. If you want we can remove the whole if (!hwnd) code because if hwnd is 0, lockedWnd = hwnd does the right thing, too.
Well, it already does the right thing today, so I don't see why you need to change it. If it's just to make it more readable OK, but I don't see much point given that this function is completely wrong anyway. And I definitely don't see a reason for removing the fixme message.
Am Fre, 2002-10-18 um 17.34 schrieb Alexandre Julliard:
Christian Neumair chris@gnome-de.org writes:
The version in HEAD actually doesn't unlock the window inside the function but just exits the if loop. The patch adds an unlock function (see msdn, when not passing hwnd, the active window should be unlocked) and moves the stub to the place where it belongs. Basically this makes the code easier to read. If you want we can remove the whole if (!hwnd) code because if hwnd is 0, lockedWnd = hwnd does the right thing, too.
Well, it already does the right thing today, so I don't see why you need to change it. If it's just to make it more readable OK, but I don't see much point given that this function is completely wrong anyway. And I definitely don't see a reason for removing the fixme message.
I see a reason: FIXME denotes that something should be fixed, but in this place we don't need to fix anything. I prepared a really small patch, have a look at it and tell me if you still find the cleanup obsolete. And I think it's not a good idea to tell the users that something has gone wrong (stub) while the desired action was taken without any problems.
regs, Chris
Christian Neumair chris@gnome-de.org writes:
I see a reason: FIXME denotes that something should be fixed, but in this place we don't need to fix anything. I prepared a really small patch, have a look at it and tell me if you still find the cleanup obsolete. And I think it's not a good idea to tell the users that something has gone wrong (stub) while the desired action was taken without any problems.
But no desired action has taken place at all! All we do is store the window in an internal variable, but we don't lock the window updates at all, which is the whole point of the function. So a fixme is definitely appropriate.
Am Fre, 2002-10-18 um 19.58 schrieb Alexandre Julliard:
Christian Neumair chris@gnome-de.org writes:
I see a reason: FIXME denotes that something should be fixed, but in this place we don't need to fix anything. I prepared a really small patch, have a look at it and tell me if you still find the cleanup obsolete. And I think it's not a good idea to tell the users that something has gone wrong (stub) while the desired action was taken without any problems.
But no desired action has taken place at all! All we do is store the window in an internal variable, but we don't lock the window updates at all, which is the whole point of the function. So a fixme is definitely appropriate.
Sorry, I didn't know that. Maybe I should read source code more carefully.
regs, Chris
Sorry, I sent the whole file where I modified some other stuff to play around :/. Please try this patch.
regs, Chris
-
Alexandre Julliard -
Christian Neumair