Folks,
After my latest X-series patches (currently at X6), I am aware of the following listview bugs:
Yes, you read correctly: NONE. :)
So I ask you for one of two things: -- bug reports or -- success stories
Otherwise, I'm gonna declare listview the coolest, nicest, most huggable piece of code out there <g>.
Hi,
On Thu, 24 Oct 2002, Dimitrie O. Paun wrote:
Folks,
After my latest X-series patches (currently at X6), I am aware of the following listview bugs:
Yes, you read correctly: NONE. :)
So I ask you for one of two things: -- bug reports
Here goes! I tested with all patches up to X6 applied. I took WinZip 8.1 (hopefully easy to get a hold of), opened a big zip file and noticed the following things:
* if I resize the 'Type' column there is a lot of flicker in the first column. Now there are some things to be said about that: - since this changes the width of the first column it seems unavoidable to redraw it (unless we keep its maximum width?) - on NT4 it only redraws the columns when I release the mouse button so of course it does not flicker. So either our comctl32 is more advanced and does on-the-fly resizing, or maybe it should not.
* if I move the 'Type' column to the left it gets corrupted. See listview1.png.
* on NT4 'PageUp' moves the selection to the first visible item of the list. Once on the first visible item of the page it moves us one page up, i.e. the selected item becomes the last fully visible item of the list. Not sure if this is a listiew issue or a srollbar issue.
* similarly on NT4 'PageDown' moves the selection to the last _fully_ visible item of the list. Once on the last _fully_ visible item of the list it scrolls one page down, i.e. that item becomes the first visible item of the list.
* when editing an item (e.g. in the Open dialog), the old value of the item is not erased and will appear behind the said item. See listview2.png. This could almost be considered a feature.
* still in the Open dialog, if I click on an item that is not fully visible in the right-most column, then the list will scroll to make that item visible. However I also get this scrolling for items in the right-most column even though all items in that column appear to be fully visible. Also, on NT4 I do not get this scrolling so the issue may be there or again, it may be the exact behavior changed in later comctl32 revisions.
* if I click on the headers garbage temporarily appears in them but then the correct text is redisplayed. Seems more likely to be a header issue... (the blue icon indicating the sort order does not appear either)
* Ctrl+Up/Down Arrow does not seem to work. More precisely, the current position of the cursor is not shown in any way although a slight flicker gives us a hint that the cursor really is moving..
* when moving using Ctrl+Up/Down Arrow, space should be (de)selecting the current item. That does not seem to work either.
That may seem like a long list but I think it does not contain anything really major. Goo job!
or -- success stories
Well, just put back the old listview and compare with the new one. The new one is much better despite the above issues.
On Thu, 24 Oct 2002, Francois Gouget wrote: [...]
On Thu, 24 Oct 2002, Dimitrie O. Paun wrote:
Folks,
After my latest X-series patches (currently at X6), I am aware of the following listview bugs:
Yes, you read correctly: NONE. :)
So I ask you for one of two things: -- bug reports
Here goes! I tested with all patches up to X6 applied. I took WinZip 8.1 (hopefully easy to get a hold of), opened a big zip file and noticed the following things:
[...]
Hmm, one more thing actually: WinZip crashes on exit and this crash goes `away if I restore the old comctl32 library... Can you reproduce the crash or should I send you a log?
On October 24, 2002 06:48 am, Francois Gouget wrote:
Hmm, one more thing actually: WinZip crashes on exit and this crash goes `away if I restore the old comctl32 library... Can you reproduce the crash or should I send you a log?
Yes, please, always send me a log :)
On October 24, 2002 06:43 am, Francois Gouget wrote:
- if I resize the 'Type' column there is a lot of flicker in the first
column. Now there are some things to be said about that:
- since this changes the width of the first column it seems
unavoidable to redraw it (unless we keep its maximum width?)
- on NT4 it only redraws the columns when I release the mouse button
so of course it does not flicker. So either our comctl32 is more advanced and does on-the-fly resizing, or maybe it should not.
Win2k I think does on-the-fly resizing, and it's a lot nicer from a usability perspective, IMO. Now, ours is not that good, but... I'll try a few things to eliminate the flicker, it is one of the few that still remain, and it's annoying, I agree.
- if I move the 'Type' column to the left it gets corrupted. See
listview1.png.
What exactly did you move? The edge to the left, or to the right or 'Type'?
On Thu, 24 Oct 2002, Dimitrie O. Paun wrote:
On October 24, 2002 06:43 am, Francois Gouget wrote:
- if I resize the 'Type' column there is a lot of flicker in the first
column. Now there are some things to be said about that:
- since this changes the width of the first column it seems
unavoidable to redraw it (unless we keep its maximum width?)
- on NT4 it only redraws the columns when I release the mouse button
so of course it does not flicker. So either our comctl32 is more advanced and does on-the-fly resizing, or maybe it should not.
Win2k I think does on-the-fly resizing, and it's a lot nicer from a usability perspective, IMO. Now, ours is not that good, but... I'll try a few things to eliminate the flicker, it is one of the few that still remain, and it's annoying, I agree.
I retested with X7 and the flicker is gone :-)
- if I move the 'Type' column to the left it gets corrupted. See
listview1.png.
What exactly did you move? The edge to the left, or to the right or 'Type'?
It happened when I moved the left edge of the 'Type' column. This resizes the first column and moves all the other columns. I retested with X7 to confirm that the issue is still there and noticed that similar redraw issues occurred when I move/resize other columns.
On October 24, 2002 03:01 pm, Francois Gouget wrote:
I retested with X7 and the flicker is gone :-)
You are too kind! Most of it (but not all), at least it's gone ... :) However, it breaks right aligned, and centered columns, X11 fixes that. For those, we can't do without the flicker, sorry (unless we do double buffering).
On October 24, 2002 03:01 pm, Francois Gouget wrote:
It happened when I moved the left edge of the 'Type' column. This resizes the first column and moves all the other columns. I retested with X7 to confirm that the issue is still there and noticed that similar redraw issues occurred when I move/resize other columns.
There is no reason for that column to get corrupted, as it gets ScrollWindowEx'ed. I think you are hitting this bug:
http://bugs.winehq.org/show_bug.cgi?id=1091
It's very, very easy to hit it if you play around with the column width, since you are doing a lot of iterleaved InvalidateRect & ScrollWindowEx.
On Thu, 24 Oct 2002, Dimitrie O. Paun wrote:
On October 24, 2002 03:01 pm, Francois Gouget wrote:
It happened when I moved the left edge of the 'Type' column. This resizes the first column and moves all the other columns. I retested with X7 to confirm that the issue is still there and noticed that similar redraw issues occurred when I move/resize other columns.
There is no reason for that column to get corrupted, as it gets ScrollWindowEx'ed. I think you are hitting this bug:
http://bugs.winehq.org/show_bug.cgi?id=1091
It's very, very easy to hit it if you play around with the column width, since you are doing a lot of iterleaved InvalidateRect & ScrollWindowEx.
Possible. I found an easier way to reproduce: just start notepad.exe, Go to the file open dialog, and put it in 'Details' mode. Then you get a header and can play with the column widths. If that's the same bug as 1091 it may be worth mentioning this as a way to reproduce the issue in the bug report.
On October 24, 2002 03:25 pm, Francois Gouget wrote:
Possible. I found an easier way to reproduce: just start notepad.exe, Go to the file open dialog, and put it in 'Details' mode. Then you get a header and can play with the column widths.
That's right.
If that's the same bug as 1091 it may be worth mentioning this as a way to reproduce the issue in the bug report.
I bet it is. I've added it there, on your behalf.
Any takers for this bug? <g>
On October 24, 2002 06:43 am, Francois Gouget wrote:
Here goes! I tested with all patches up to X6 applied. I took WinZip 8.1 (hopefully easy to get a hold of), opened a big zip file and noticed the following things:
How did you do that, CVS+X0-6 crashes on startup! Should I waste time debugging, or you have a modified tree... :)
On Thu, 24 Oct 2002, Francois Gouget wrote:
Hi,
On Thu, 24 Oct 2002, Dimitrie O. Paun wrote:
Folks,
After my latest X-series patches (currently at X6), I am aware of the following listview bugs:
Yes, you read correctly: NONE. :)
So I ask you for one of two things: -- bug reports
Here goes! I tested with all patches up to X6 applied. I took WinZip 8.1 (hopefully easy to get a hold of), opened a big zip file and noticed the following things:
Dimitrie O. Paun:
How did you do that, CVS+X0-6 crashes on startup! Should I waste time debugging, or you have a modified tree... :)
Argh! I cheated. I used a slightly older Wine and copied the comctl32 dll there. Today I retested with CVS Wine plus the latest X11 patch and got it to work by just replacing the shell32 library with an older one.
- if I resize the 'Type' column there is a lot of flicker in the first
column. Now there are some things to be said about that:
That one is fixed by X7 and it still works with X11. The columns are left aligned :-)
I generated a log of the Winzip 'crash on exit'. You can find it there: http://fgouget.free.fr/tmp/listview2.log.bz2 (2.7MB)
Also I am getting a crash when I resize the WinZip window: fixme:listview:LISTVIEW_SetColumnOrderArray iCount 9 lpiArray 0x406828a8 wine: listview.c:1639: LISTVIEW_GetItemOrigin: Assertion `nItem >= 0 && nItem < infoPtr->nItemCount' failed.
Now looking for alternatives to WinZip since it may not be so good for testing.
- on NT4 'PageUp' moves the selection to the first visible item of the
list. Once on the first visible item of the page it moves us one page up, i.e. the selected item becomes the last fully visible item of the list. Not sure if this is a listiew issue or a srollbar issue.
- similarly on NT4 'PageDown' moves the selection to the last _fully_
visible item of the list. Once on the last _fully_ visible item of the list it scrolls one page down, i.e. that item becomes the first visible item of the list.
- when editing an item (e.g. in the Open dialog), the old value of the
item is not erased and will appear behind the said item. See listview2.png. This could almost be considered a feature.
The above three can be reproduced in notepad's open dialog by putting it in 'Details' mode.
- still in the Open dialog, if I click on an item that is not fully
visible in the right-most column, then the list will scroll to make that item visible. However I also get this scrolling for items in the right-most column even though all items in that column appear to be fully visible. Also, on NT4 I do not get this scrolling so the issue may be there or again, it may be the exact behavior changed in later comctl32 revisions.
That one can be reproduced in Notepad's open dialog too.
- Ctrl+Up/Down Arrow does not seem to work. More precisely, the current
position of the cursor is not shown in any way although a slight flicker gives us a hint that the cursor really is moving..
- when moving using Ctrl+Up/Down Arrow, space should be (de)selecting
the current item. That does not seem to work either.
These two can be reproduced by putting the Control Spy listview in report mode (notepad's open dialog is not suitable because it does not allow multi-select).
On October 24, 2002 04:00 pm, Francois Gouget wrote:
Argh! I cheated. I used a slightly older Wine and copied the comctl32 dll there. Today I retested with CVS Wine plus the latest X11 patch and got it to work by just replacing the shell32 library with an older one.
Can you please search what broke shell32? This is Not Good (TM).
I generated a log of the Winzip 'crash on exit'. You can find it there: http://fgouget.free.fr/tmp/listview2.log.bz2 (2.7MB)
Oh, thanks, but I have Winzip, and there's nothing decent in the log. I've looked already :)
Also I am getting a crash when I resize the WinZip window: fixme:listview:LISTVIEW_SetColumnOrderArray iCount 9 lpiArray 0x406828a8 wine: listview.c:1639: LISTVIEW_GetItemOrigin: Assertion `nItem >= 0 && nItem < infoPtr->nItemCount' failed.
I'll look into this, if I get how to run WinZip.
- on NT4 'PageUp' moves the selection to the first visible item of the
list. Once on the first visible item of the page it moves us one page up, i.e. the selected item becomes the last fully visible item of the list. Not sure if this is a listiew issue or a srollbar issue.
- similarly on NT4 'PageDown' moves the selection to the last _fully_
visible item of the list. Once on the last _fully_ visible item of the list it scrolls one page down, i.e. that item becomes the first visible item of the list.
I haven't yet hacked keyboard handling. Maybe later.
- when editing an item (e.g. in the Open dialog), the old value of the
item is not erased and will appear behind the said item. See listview2.png. This could almost be considered a feature.
So should I change this? I can, it's not a problem...
- still in the Open dialog, if I click on an item that is not fully
visible in the right-most column, then the list will scroll to make that item visible. However I also get this scrolling for items in the right-most column even though all items in that column appear to be fully visible. Also, on NT4 I do not get this scrolling so the issue may be there or again, it may be the exact behavior changed in later comctl32 revisions.
Do you want this changed? I think it's desired behaviour, less the scrolling when it shouldn't...
On Thu, 24 Oct 2002, Dimitrie O. Paun wrote:
On October 24, 2002 04:00 pm, Francois Gouget wrote:
Argh! I cheated. I used a slightly older Wine and copied the comctl32 dll there. Today I retested with CVS Wine plus the latest X11 patch and got it to work by just replacing the shell32 library with an older one.
Can you please search what broke shell32? This is Not Good (TM).
I'll try if I can find the time....
[...]
- when editing an item (e.g. in the Open dialog), the old value of the
item is not erased and will appear behind the said item. See listview2.png. This could almost be considered a feature.
So should I change this? I can, it's not a problem...
If it's easy to change then it's best to match Windows.
- still in the Open dialog, if I click on an item that is not fully
visible in the right-most column, then the list will scroll to make that item visible. However I also get this scrolling for items in the right-most column even though all items in that column appear to be fully visible. Also, on NT4 I do not get this scrolling so the issue may be there or again, it may be the exact behavior changed in later comctl32 revisions.
Do you want this changed? I think it's desired behaviour, less the scrolling when it shouldn't...
Same here: as it currently is the rightmost column tends to 'jump left' when you click on it which can be a bit confusing.
On Thu, 24 Oct 2002, Dimitrie O. Paun wrote:
On October 24, 2002 04:00 pm, Francois Gouget wrote:
Argh! I cheated. I used a slightly older Wine and copied the comctl32 dll there. Today I retested with CVS Wine plus the latest X11 patch and got it to work by just replacing the shell32 library with an older one.
Can you please search what broke shell32? This is Not Good (TM).
Winzip was broken on 2002/07/23 by one of the following two patches:
* http://cvs.winehq.com/patch.py?id=1027475763780155356581421 Juergen Schmied juergenschmied@lycos.de - Cleaned up the implementation of shell folders and put them into separate files. - Fixed some memory leaks. - Some more fixes.
* http://cvs.winehq.com/patch.py?id=102747584224009388063951 Fixed duplication of definitions between shlwapi.h and obj_queryassociations.h.
I cannot compile Wine if I only apply the first one. I suspect there is a problem in the first one but unfortunately it is pretty large: ~4000 lines.
Francois Gouget wrote:
Winzip was broken on 2002/07/23 by one of the following two patches:
http://cvs.winehq.com/patch.py?id=1027475763780155356581421 Juergen Schmied juergenschmied@lycos.de
- Cleaned up the implementation of shell folders and put them into separate files.
- Fixed some memory leaks.
- Some more fixes.
http://cvs.winehq.com/patch.py?id=102747584224009388063951 Fixed duplication of definitions between shlwapi.h and obj_queryassociations.h.
See the bug: http://bugs.winehq.com/show_bug.cgi?id=924
The fix in http://bugs.winehq.com/show_bug.cgi?id=924 looks good. Could sbd send it as a patch ?
Thanks
Juergen
On Thu, 24 Oct 2002, Dimitrie O. Paun wrote:
On October 24, 2002 04:00 pm, Francois Gouget wrote:
Argh! I cheated. I used a slightly older Wine and copied the comctl32 dll there. Today I retested with CVS Wine plus the latest X11 patch and got it to work by just replacing the shell32 library with an older one
Can you please search what broke shell32? This is Not Good (TM)
Winzip was broken on 2002/07/23 by one of the following two patches:
http://cvs.winehq.com/patch.py?id=1027475763780155356581421 Juergen Schmied juergenschmied@lycos.de
- Cleaned up the implementation of shell folders and put them into separate files
- Fixed some memory leaks
- Some more fixes
http://cvs.winehq.com/patch.py?id=102747584224009388063951 Fixed duplication of definitions between shlwapi.h and obj_queryassociations.h
I cannot compile Wine if I only apply the first one. I suspect there is a problem in the first one but unfortunately it is pretty large: ~4000 lines
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0
--- juergen.schmied@debitel.net
El dom, 27 de oct de 2002, a las 13:14, Jürgen Schmied escribio:
The fix in http://bugs.winehq.com/show_bug.cgi?id=924 looks good. Could sbd send it as a patch ?
My patch with subject: (Day 26 oct) SHGFI_USEFILEATTRIBUTES support in SHGetFileInfoA
fixes this problem (winzip is working again and really nice!!!) and some different issues relative to SHGFI_USEFILEATTRIBUTES.
Regards, Carlos.
On Thu, 24 Oct 2002 02:36:48 -0400, you wrote:
Folks,
After my latest X-series patches (currently at X6), I am aware of the following listview bugs:
Yes, you read correctly: NONE. :)
So I ask you for one of two things: -- bug reports
Since you asked (newsbin):
- the last column in the messages listview doesn't display any text. It should display the From: field. Also the listview's header is blank for that column.
- Updating/refreshing the messages listview (when downloading headers) is far less efficient then with native comctl32. The whole listview gets refreshed instad of just the visible update. This is especially noticable when the updates are not in the visible part of the listview: builtin keeps flashing while native is completely still.
- resizing the columns (funny some of them, not all) looses the green background colour.
or -- success stories
All other problems (not counting drag/drop featurerequest) that I reported are fixed now. I have stress tested with the largest newsgroups available (some 20,000 items) which are handled quite well. The old code came to a grinding halt even with much smaller groups.
Great job!
Rein.
On October 24, 2002 07:34 am, Rein Klazes wrote:
- resizing the columns (funny some of them, not all) looses the green
background colour.
Fixed by X8-11. Give it a spin.
On October 24, 2002 07:34 am, Rein Klazes wrote:
- Updating/refreshing the messages listview (when downloading headers)
is far less efficient then with native comctl32. The whole listview gets refreshed instad of just the visible update. This is especially noticable when the updates are not in the visible part of the listview: builtin keeps flashing while native is completely still.
Fixed by X12. Take it for a spin, and let me know.
So, I know this has been discussed before... but I can't recall: is native (W98) regedit expected to work right now? For me, it doesn't. It's better with the latest CVS than yesterday (died on an assertion), but now it's back to "blank". The listview shows correct headers, but no actual line-items. Native commctrl/comctl32 works OK.
On October 25, 2002 02:36 am, Greg Turner wrote:
So, I know this has been discussed before... but I can't recall: is native (W98) regedit expected to work right now? For me, it doesn't. It's better with the latest CVS than yesterday (died on an assertion), but now it's back to "blank". The listview shows correct headers, but no actual line-items. Native commctrl/comctl32 works OK.
Well, I don't have that application, so you'll need to help debug it if you want it working :). First step is a --debugmsg +listview. If you think that's relevant, a screenshot too.
On Friday 25 October 2002 07:35 am, Dimitrie O. Paun wrote:
On October 25, 2002 02:36 am, Greg Turner wrote:
So, I know this has been discussed before... but I can't recall: is native (W98) regedit expected to work right now? For me, it doesn't.
Well, I don't have that application, so you'll need to help debug it if you want it working :). First step is a --debugmsg +listview. If you think that's relevant, a screenshot too.
ok, I'll do this tonight, and maybe even try to drill in a little deeper if I can figure anything interesting out. FYI, I think this problem existed before your listvew work started, so its probably not your doing.
BTW, thanks for your ongoing work, listviews feel much better lately!
On Thu, 24 Oct 2002 19:20:44 -0400, you wrote:
On October 24, 2002 07:34 am, Rein Klazes wrote:
- Updating/refreshing the messages listview (when downloading headers)
is far less efficient then with native comctl32. The whole listview gets refreshed instad of just the visible update. This is especially noticable when the updates are not in the visible part of the listview: builtin keeps flashing while native is completely still.
Fixed by X12. Take it for a spin, and let me know.
It is a bit too much. The flashing is gone, great. But when the message listview is filled and the display updates, of the perhaps 10 new items that are added to the bottom only the last 2 or 3 are displayed. That leaves white gaps in the listview which will update when the display is minimized/restored or some similar action.
Rein.
On October 25, 2002 11:34 am, Rein Klazes wrote:
It is a bit too much. The flashing is gone, great. But when the message listview is filled and the display updates, of the perhaps 10 new items that are added to the bottom only the last 2 or 3 are displayed. That leaves white gaps in the listview which will update when the display is minimized/restored or some similar action.
This is quite odd, I don't see that here. Can you please send me some screenies?
On Fri, 25 Oct 2002 11:38:23 -0400, you wrote:
On October 25, 2002 11:34 am, Rein Klazes wrote:
It is a bit too much. The flashing is gone, great. But when the message listview is filled and the display updates, of the perhaps 10 new items that are added to the bottom only the last 2 or 3 are displayed. That leaves white gaps in the listview which will update when the display is minimized/restored or some similar action.
This is quite odd, I don't see that here. Can you please send me some screenies?
www.xs4all.nl/~rklazes/temp/nb2.png shows the problem quit well, only two items are displayed where there should have been much more; www.xs4all.nl/~rklazes/temp/nb3.png same window after it was temporary partly obscured by another window showing the missing items.
Rein.
On October 25, 2002 12:16 pm, Rein Klazes wrote:
www.xs4all.nl/~rklazes/temp/nb2.png shows the problem quit well, only two items are displayed where there should have been much more; www.xs4all.nl/~rklazes/temp/nb3.png same window after it was temporary partly obscured by another window showing the missing items.
Thank you, please try Z5.
On Fri, 25 Oct 2002 14:47:14 -0400, you wrote:
On October 25, 2002 12:16 pm, Rein Klazes wrote:
www.xs4all.nl/~rklazes/temp/nb2.png shows the problem quit well, only two items are displayed where there should have been much more; www.xs4all.nl/~rklazes/temp/nb3.png same window after it was temporary partly obscured by another window showing the missing items.
Thank you, please try Z5.
Now it is visually back to the situation before X12, lots of flickering.
Rein.
On October 25, 2002 03:24 pm, Rein Klazes wrote:
Now it is visually back to the situation before X12, lots of flickering.
I beg to differ. I've tried it, and it *sometimes* flickers *once* (that is, at the end of the download, it refreshes again, even if it shouldn't). Problem is, that the _app_ requires that behaviour! That is, it depends on WM_SETREDRAW(TRUE) to invalidate the list, and it's issuing one at the end...
On Fri, 25 Oct 2002 15:23:59 -0400, you wrote:
On October 25, 2002 03:24 pm, Rein Klazes wrote:
Now it is visually back to the situation before X12, lots of flickering.
I beg to differ. I've tried it, and it *sometimes* flickers *once* (that is, at the end of the download, it refreshes again, even if it shouldn't). Problem is, that the _app_ requires that behaviour! That is, it depends on WM_SETREDRAW(TRUE) to invalidate the list, and it's issuing one at the end...
What I see different from native comcontrol is that 1- during a refresh everything is redrawn, including the header control; 2- the refreshing continues about once every second until the download is finished, certainly not "sometimes" or only "at the end".
I will investigate the WM_SETREDRAW messages, perhaps they appear too often in my situation. That still does not explain why a refresh with native dll manages only to repaint the updated part, which is nill at the end of the download.
Rein.
On October 25, 2002 04:18 pm, Rein Klazes wrote:
What I see different from native comcontrol is that 1- during a refresh everything is redrawn, including the header control;
This is fixable, and it will get fixed soon.
2- the refreshing continues about once every second until the download is finished, certainly not "sometimes" or only "at the end".
Hm, maybe I didn't look at newsgroups that took many seconds. In fact, I've seen similar behavior (but not generated by WM_SETREDRAW, the app itself would invalidate the entire window from outside), in other apps (e.g. All-SeeingEye: http://www.udpsoft.com/eye/)
I will investigate the WM_SETREDRAW messages, perhaps they appear too often in my situation. That still does not explain why a refresh with native dll manages only to repaint the updated part, which is nill at the end of the download.
I think the native does double buffering to avoid that flicker. I will eventually add that too, but I want to make sure, before I do, that we do have the most optimal invalidating/painting code that's possible. Once we're satisfied with that, I'll try to eliminate the rest of the flicker by rendering to an off-screen buffer.
I did this in the Trackbar control, and it works quite well.
On 24 Oct 2002, dpaun@rogers.com wrote:
So I ask you for one of two things: -- bug reports
A couple minor Xnews problems (running X7):
- Open a newsgroup with enough articles to cause a vertical scrollbar. As the articles load, Xnews displays them without any threading or sorting. After it's done, it should thread them and redraw the whole list, but only the top row gets redrawn. The usual minimize/restore fixes it and there's no problem if there's no scrollbar. The problem first appeared in v1.282, which is very odd because all that one did was add a #include "wine/unicode.h".
- This is something that never worked in the old code either so it may not be listview-related. An obscure Xnews feature is that you can right-click the read column in the newsgroup listing and edit its contents. Instead the standard context menu for that window appears.
El jue, 24 de oct de 2002, a las 14:12, Paul Rupe escribio:
On 24 Oct 2002, dpaun@rogers.com wrote:
So I ask you for one of two things: -- bug reports
A couple minor Xnews problems (running X7):
- Open a newsgroup with enough articles to cause a vertical scrollbar. As
the articles load, Xnews displays them without any threading or sorting. After it's done, it should thread them and redraw the whole list, but only the top row gets redrawn. The usual minimize/restore fixes it and there's no problem if there's no scrollbar. The problem first appeared in v1.282, which is very odd because all that one did was add a #include "wine/unicode.h".
Winrar doesn't work when you add that #include. :(
Regards, Carlos.
On October 24, 2002 02:12 pm, Paul Rupe wrote:
- This is something that never worked in the old code either so it may not
be listview-related. An obscure Xnews feature is that you can right-click the read column in the newsgroup listing and edit its contents. Instead the standard context menu for that window appears.
Looked at this. Our notifications seems correct, Xnews does very strange things with mouse input. Please write the author, and ask him what he needs to get this working.
-
Carlos Lozano -
Dimitrie O. Paun -
Duane Clark -
Francois Gouget -
Greg Turner -
Jürgen Schmied -
Paul Rupe -
Rein Klazes