Folks,
Things look pretty good on the listview front. In fact, I am kindda happy the way things are, as the S-series patches were rather tricky at points...
Currently, I know of the following problems: -- Newsbin dies swiftly (reported my Rein Klazes) -- FTPCommander seems to experience some listview-related faults (reported by Carlos Lozano) -- Xnews has some minor focus rectangle problems (discovered by myself :)) -- IDAdemo _may_ have some minor drawing glitches (ditto)
At this point, I would like to ask everybody that is aware of a listview problem to report it. I might not be able to put as much time, and effort into listview, as I did lately, so the more of a complete picture I have now, the better the chances that I'm gonna fix it.
Next on my TODO: -- Fix Newsbin's crash (BTW, Rein I need a new trace with the latest CVS, if possible) -- Store per-column info into the listview (see the second status update for details)
If you feel that there is a particular are of the listview that needs attention, let me know so I can work it into my TODO, time permitting.
Add to TODOs : LVS_SORTASCENDING isn't supported,so a program like regedit can't display its values without setting comctl to native.
If you feel that there is a particular are of the listview that needs attention, let me know so I can work it into my TODO, time permitting.
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
On 17 Oct 2002, dpaun@rogers.com wrote:
-- Store per-column info into the listview (see the second status update for details)
I think this may have broken something in Xnews. In the newsgroup listing (always) and the article listing (sometimes), selecting an item causes the rightmost two columns or so to be cut off. Forcing a redraw of the window fixes it temporarily. I went back in CVS and 1.251 of listview.c is first version that does this. I also added U0 and U1 but that didn't make any difference.
I was out of town all last week, but now I'm caught up and running CVS 1.256+U0+U1...
- In Xnews open a group or article listing with a bunch of rows. Page down a few times, then hold Shift and page up once. What should be the new top row is being drawn on top of the listview heading. This happens only with multiple selection. Single-select Page up is fine. Looks like this first happened in 1.202.
- It seems we're back to O(n) performance on long listviews. My group listing with 50,000 entries takes about a second to select an item. I went back and found that 1.248 is the first one with this problem.
- Place an xterm or some other window partially covering a listview. Scroll down using the arrow key with the window on top. The row just coming out from under the xterm is a copy of the row above it rather than the correct one. Scrolling up does the same thing but with the row on the bottom. I first noticed this in the L or M series of patches right before I left, but I think it may be older than that.
On October 19, 2002 09:58 am, Paul Rupe wrote:
On 17 Oct 2002, dpaun@rogers.com wrote:
-- Store per-column info into the listview (see the second status update for details)
I think this may have broken something in Xnews.
Hi Paul,
Welcome back! You are right, the above mentioned change broke a bunch of things, it's not complete. I will work on it some today. So I'll defer work on the other bugs until I fix this, OK?
On October 19, 2002 09:58 am, Paul Rupe wrote:
I think this may have broken something in Xnews. In the newsgroup listing (always) and the article listing (sometimes), selecting an item causes the rightmost two columns or so to be cut off. Forcing a redraw of the window
This should be fixed now, with the V0-8. Can you please check?
- In Xnews open a group or article listing with a bunch of rows. Page down
a few times, then hold Shift and page up once. What should be the new top row is being drawn on top of the listview heading. This happens only with multiple selection. Single-select Page up is fine. Looks like this first happened in 1.202.
Very odd! I'll look into it, next.
- It seems we're back to O(n) performance on long listviews. My group
listing with 50,000 entries takes about a second to select an item. I went back and found that 1.248 is the first one with this problem.
Fixed. Please confirm.
- Place an xterm or some other window partially covering a listview.
Scroll down using the arrow key with the window on top. The row just coming out from under the xterm is a copy of the row above it rather than the correct one. Scrolling up does the same thing but with the row on the bottom. I first noticed this in the L or M series of patches right before I left, but I think it may be older than that.
Yes. This is related to a bug that I signaled sometime ago:
http://www.winehq.com/hypermail/wine-devel/2002/09/0748.html
It has nothing to do with the listview. I should file this as a bug... Alexandre, any comments on this one?
On 20 Oct 2002, dpaun@rogers.com wrote:
On October 19, 2002 09:58 am, Paul Rupe wrote:
I think this may have broken something in Xnews. In the newsgroup listing (always) and the article listing (sometimes), selecting an item causes the rightmost two columns or so to be cut off.
This should be fixed now, with the V0-8. Can you please check?
Confirmed.
- It seems we're back to O(n) performance on long listviews. My
group listing with 50,000 entries takes about a second to select an item.
Fixed. Please confirm.
Yep. Nice and fast again.
Yes. This is related to a bug that I signaled sometime ago:
http://www.winehq.com/hypermail/wine-devel/2002/09/0748.html
It has nothing to do with the listview. I should file this as a bug... Alexandre, any comments on this one?
You're right. Must be that the old listview (1.143) avoids this problem because it's so redraw-happy.
On October 20, 2002 06:17 pm, Paul Rupe wrote:
Thanks for retesting.
You're right. Must be that the old listview (1.143) avoids this problem because it's so redraw-happy.
Indeed. But I'm not going to slow down the listview to work around this bug... The bug needs to be fixed properly.
-
Dimitrie O. Paun -
Paul Rupe -
Sylvain Petreolle