Re: PATCH: Inserting an item in a listview sometimes generates incorrect messages
On March 6, 2003 06:04 am, Adam Gundy wrote: [wine-devel Cc:ed to keep people in the loop]
Is a listview guaranteed to be single threaded? I assume it is because it is all message driven - so some flag in the LISTVIEW_INFO structure could be set. I'd say that is even more opaque.
I think this would be better. It's localized in two points (where we set it, and where we use it), and it's easier to follow. The rest of the code should be unaware of this problem, so hiding it is the right thing to do IMO. The reason it's easier to follow is that if I don't see it, I don't care about it, which is what we want, and 99% of people looking at the code will fall in this category. If you do happen to stumble upon it, you can search for the infoPtr->blah thing that we're setting to see where and how this thing is used. You can't easily search with the current flag solution.
Actually, there is the rather unhelpful comment "But we are not supposed to modify nHotItem!* in LISTVIEW_ShiftIndices() - does 'real' Windows maintain the focus after an insertion? Perhaps that's why they don't send the messages - you know how they work: write the code then document its broken behaviour after the fact ;-)
Yes, I know. This is why I think it should just result from some other behavior naturally, I don't think MS went through the trouble of passing a boolean around all over the place just to not send this notification. One more reason to not uglify our interfaces, as it will just get fixed automatically when we properly support the HotItem. -- Dimi.
At 10:17 06/03/03 -0500, Dimitrie O. Paun wrote:
On March 6, 2003 06:04 am, Adam Gundy wrote:
[wine-devel Cc:ed to keep people in the loop]
Is a listview guaranteed to be single threaded? I assume it is because it is all message driven - so some flag in the LISTVIEW_INFO structure could be set. I'd say that is even more opaque.
I think this would be better. It's localized in two points (where we set it, and where we use it), and it's easier to follow. The rest of the code should be unaware of this problem, so hiding it is the right thing to do IMO. The reason it's easier to follow is that if I don't see it, I don't care about it, which is what we want, and 99% of people looking at the code will fall in this category. If you do happen to stumble upon it, you can search for the infoPtr->blah thing that we're setting to see where and how this thing is used. You can't easily search with the current flag solution.
fine by me. you want me to do it? Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions.
participants (3)
-
Adam Gundy -
Dimitrie O. Paun -
Dimitrie O. Paun