Folks,
The listview should now be better than before I started working on it. If there are regressions, I would like to know about them.
During my work, the REPORT mode got a lot faster rendering. The Q-series patches undoes partly those speed enhancements. However, the situation is temporary, and when I'm done with it, we'll have pretty much as fast a rendering as possible.
For this to happen, I need to do a bit more infrastructure work. Namely, we have to keep track of column information, such as rect, alignment, etc. This will no only speed up report rendering, it will allow us to have icons for subitems as well (most of the work for this is actually done, I just need a place to put the on/off flag).
Once this is done, we can start working on actually adding features. And there are a _lot_ of features that we're missing. But this is another story! :) My aim here is to bring the listview to a solid foundation that can take all these new features without turning it into something (1) buggy, (2) unmanageable, and (3) slow.
There is one more infrastructure bit that may need to be done. That is, we may need to keep an ordered array of item positions in LVS_{,SMALL}ICON modes. Currently, we don't have something like this, and as a result we need to iterate over the entire item set in the above mentioned modes. This works for a small number of items, but when we have 10s of thousands, or millions, or what have you of items, it will blow chunks. The good thing is that all the iterator work that I've done lately nicely separates all these details away from the code. So it can wait for now.
So once again, I am interested to hear about regressions. I think the code reached a state where we can concentrate on cleaning up our act, before adding new features.
On Tuesday 15 October 2002 06:39, Dimitrie O. Paun wrote:
So once again, I am interested to hear about regressions. I think the code reached a state where we can concentrate on cleaning up our act, before adding new features.
Most of the regressions are fixed now. Thanks
But the double click selection do not work eg in the MSOffice file open dialogs.
Regards Zsolt
On October 16, 2002 06:16 am, Rizsanyi Zsolt wrote:
But the double click selection do not work eg in the MSOffice file open dialogs.
Did you apply the R-series?
On Wednesday 16 October 2002 17:59, Rizsanyi Zsolt wrote:
On Wednesday 16 October 2002 14:39, Dimitrie O. Paun wrote:
On October 16, 2002 06:16 am, Rizsanyi Zsolt wrote:
But the double click selection do not work eg in the MSOffice file open dialogs.
Did you apply the R-series?
I'm using the cvs from about 5 hours ago (12:00 CET).
Ok. I have updated cvs, and the double click problem went away :)
But I have tested more toroughly the open dialog of Word97 and found out that it has some update problems when changing beetwen different view modes.
Like when you change from Details view to Properties view, then the header of the Details view (where the Name, Size, Type, ... is written) stays there. If you change back to List view and then directly to Properties, then the Properties view is ok.
Another problem, is that when you change from Properties view to List view, then the icons are not loaded correctly, but every item gets the same (unknown file) icon . But if you change the directory (and back), then everything is normal.
In the Details view, the header is weird. If you scroll to right, then the name of the first column appears in the header.
Mouse wheel scrolling do not work (tough I dont know if it should, but it would be nice).
And in the date column (in Details view), instead of date only the date format (M/d/yyyy) is shown.
Maybe not all of that is a listview issue, but you maybe I could help some...
Regards Zsolt
On October 18, 2002 08:22 am, Rizsanyi Zsolt wrote:
Ok. I have updated cvs, and the double click problem went away :)
At least there is _some_ good news :)
But I have tested more toroughly the open dialog of Word97 and found out that it has some update problems when changing beetwen different view modes.
Duh!
Like when you change from Details view to Properties view, then the header of the Details view (where the Name, Size, Type, ... is written) stays there. If you change back to List view and then directly to Properties, then the Properties view is ok.
WTH is "Properties"? I don't have Office97, so can you please send me a sceenshot with it OK, and with the problem?
On Tue, 15 Oct 2002 00:39:43 -0400, you wrote:
So once again, I am interested to hear about regressions. I think the code reached a state where we can concentrate on cleaning up our act, before adding new features.
OK, here is the status for newsbin. All relative to the status that I reported before.
For the sake of this report there are two listviews: one filled with newsgroups the other with messages. The actions that I like to do is 1) select a newsgroup with left button click on de group listview 2) call up a context menu and choose retrieve messages 3) see the message listview getting populated. As an alternative to 2) I can double click or use the main menu.
Here are the changes observed with the different revisions of listview.c:
rev 1.199 Right click to get context menu doesn't work anymore; rev 1.200 The message listview doesn't get populated anymore. From the flickers it looks like message are added and almost immedeately removed again. rev 1.205 Right click works again (see r 1.199) rev 1.206 Left clicks now bring up the context menu. More over instead of selecting one, two groups get selected (the other one is 14 lines below the pointer psoition) rev 1.207 Selection isn't hightlighted anymore rev 1.208 Selection highlighting works again. rev 1.210 After step 2) the group listview clears and the program crashes, details below.
Upto 1.230 (== current cvs) I haven't seen any changes yet. The R patches appear to solve the selection issues, but not the crash is still there and the latest (R3) introduces a new crash long before any window is drawn. No details of this yet.
Details of the crash in current cvs:
| Unhandled exception: page fault on read access to 0x245c8b73 in 32-bit code (0x004092ed). | In 32-bit mode. | 0x004092ed (nbpro.exe..text+0x82ed in H:\binw\nbpro\nbpro.exe): call *0x20(%eax) | Backtrace: | =>0 0x004092ed (nbpro.exe..text+0x82ed in H:\binw\nbpro\nbpro.exe) (ebp=00409180) | 1 0x0c43f608 (_end+0x43e3e8c) (ebp=245c8b53) | *** Invalid address 0x245c8b53 (LIBFILTER.DLL..reloc+0x14585b53) |
Message log +relay,+listview (950 KB) is on www.xs4all.nl/~rklazes/temp/nb.log.bz2
Rein.
On October 16, 2002 06:23 am, Rein Klazes wrote:
Upto 1.230 (== current cvs) I haven't seen any changes yet. The R patches appear to solve the selection issues, but not the crash is still there and the latest (R3) introduces a new crash long before any window is drawn. No details of this yet.
OK. Newsbin seems to be using custom draw, and for some reason it crashes. So let's disable it, and see what else is wrong. As you say, R-series fixes the selection issues, and a buch of other stuff, so please test with them. I am interested in a trace like the one you posted for R3, to see why, and where it crashes.
After you get the trace, add the line: return 0; before the line 703: return notify_hdr(infoPtr, NM_CUSTOMDRAW, &lpnmlvcd->nmcd.hdr);
Like so:
static inline DWORD notify_customdraw (LISTVIEW_INFO *infoPtr, DWORD dwDrawStage, NMLVCUSTOMDRAW *lpnmlvcd) { lpnmlvcd->nmcd.dwDrawStage = dwDrawStage; return 0; return notify_hdr(infoPtr, NM_CUSTOMDRAW, &lpnmlvcd->nmcd.hdr); }
Hopefully this will eliminate the crash.
On Wed, 16 Oct 2002 08:17:11 -0400, you wrote:
On October 16, 2002 06:23 am, Rein Klazes wrote:
Upto 1.230 (== current cvs) I haven't seen any changes yet. The R patches appear to solve the selection issues, but not the crash is still there and the latest (R3) introduces a new crash long before any window is drawn. No details of this yet.
OK. Newsbin seems to be using custom draw, and for some reason it crashes. So let's disable it, and see what else is wrong. As you say, R-series fixes the selection issues, and a buch of other stuff, so please test with them. I am interested in a trace like the one you posted for R3, to see why, and where it crashes.
backtrace:
| Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00409198). | In 32-bit mode. | 0x00409198 (nbpro.exe..text+0x8198 in H:\binw\nbpro\nbpro.exe): movl 0x0(%ebp),%eax | Backtrace: | =>0 0x00409198 (nbpro.exe..text+0x8198 in H:\binw\nbpro\nbpro.exe) (ebp=00000000) |
Log: www.xs4all.nl/~rklazes/temp/nb2.log.bz2
After you get the trace, add the line: return 0; before the line 703: return notify_hdr(infoPtr, NM_CUSTOMDRAW, &lpnmlvcd->nmcd.hdr); Hopefully this will eliminate the crash.
It still crashes at the same point.
Rein.
On October 16, 2002 09:21 am, Rein Klazes wrote:
It still crashes at the same point.
OK, let's try this: -- apply all my R-series patches -- apply the "Listview struct defs v6.0" -- make sure you back out the "return 0" hack we just tried
And see if it still crashes. If it does, please send me a trace just like you did before.
On Wed, 16 Oct 2002 17:19:59 -0400, you wrote:
On October 16, 2002 09:21 am, Rein Klazes wrote:
It still crashes at the same point.
OK, let's try this: -- apply all my R-series patches -- apply the "Listview struct defs v6.0" -- make sure you back out the "return 0" hack we just tried
And see if it still crashes. If it does, please send me a trace just like you did before.
Uploaded to www.xs4all.nl/~rklazes/temp/nb3.log.bz2
Rein.
On October 17, 2002 01:49 am, Rein Klazes wrote:
Uploaded to www.xs4all.nl/~rklazes/temp/nb3.log.bz2
Fine. That didn't work... :/ But I think I fixed now: please try T0, and T1. If that doesn't work...
On Thu, 17 Oct 2002 23:55:59 -0400, you wrote:
On October 17, 2002 01:49 am, Rein Klazes wrote:
Uploaded to www.xs4all.nl/~rklazes/temp/nb3.log.bz2
Fine. That didn't work... :/ But I think I fixed now: please try T0, and T1. If that doesn't work...
It does. Now it crashes again like it did after the change in rev. 1.210:
| Unhandled exception: page fault on read access to 0x4e8880d8 in 32-bit code (0x004092ed). | In 32-bit mode. | 0x004092ed (nbpro.exe..text+0x82ed in H:\binw\nbpro\nbpro.exe): call *0x20(%eax) | Backtrace: | =>0 0x004092ed (nbpro.exe..text+0x82ed in H:\binw\nbpro\nbpro.exe) (ebp=004c7470) | 1 0x2bdce900 (LIBFILTER.DLL..reloc+0x1bd8b900) (ebp=4e8880b8) | *** Invalid address 0x4e8880b8 (_end+0xc2c0718) |
A fresh message log uploaded as www.xs4all.nl/~rklazes/temp/nb4.log.bz2
Rein.
On October 18, 2002 03:35 am, Rein Klazes wrote:
It does.
Finally! I had nightmares about it... :)
Now it crashes again like it did after the change in rev. 210
You mean that 209 worked fine, and 210 crashes?!? That was supposed to be a noop change... I looked at it again, and there's not much to it.
Listen, I need your help to fix it, as I'm running out of time. Can you take 209, and then apply bits of the changes until you find which one does it? If you don't know how to do that, let me know, and I'll try to come up with some patches.
On Fri, 18 Oct 2002 09:33:14 -0400, you wrote:
On October 18, 2002 03:35 am, Rein Klazes wrote:
It does.
Finally! I had nightmares about it... :)
Now it crashes again like it did after the change in rev. 210
You mean that 209 worked fine, and 210 crashes?!?
209 does not crash and 210 crashes. I checked again to be sure.
That was supposed to be a noop change... I looked at it again, and there's not much to it.
Listen, I need your help to fix it, as I'm running out of time. Can you take 209, and then apply bits of the changes until you find which one does it? If you don't know how to do that, let me know, and I'll try to come up with some patches.
No problem. Hopefully I can do that later today.
Rein.
On Fri, 18 Oct 2002 09:33:14 -0400, you wrote:
On October 18, 2002 03:35 am, Rein Klazes wrote:
It does.
Finally! I had nightmares about it... :)
Now it crashes again like it did after the change in rev. 210
You mean that 209 worked fine, and 210 crashes?!? That was supposed to be a noop change... I looked at it again, and there's not much to it.
Listen, I need your help to fix it, as I'm running out of time. Can you take 209, and then apply bits of the changes until you find which one does it? If you don't know how to do that, let me know, and I'll try to come up with some patches.
This makes r210 work again:
| --- listview.210.c 2002-10-19 09:59:20.000000000 +0200 | +++ listview.c 2002-10-21 19:54:28.000000000 +0200 | @@ -3102,7 +3102,7 @@ | TRACE("(hdc=%x, nItem=%d)\n", hdc, nItem); | | /* get information needed for drawing the item */ | - lvItem.mask = LVIF_TEXT | LVIF_IMAGE | LVIF_STATE | LVIF_INDENT; | + lvItem.mask = LVIF_TEXT | LVIF_IMAGE | LVIF_STATE | LVIF_INDENT | LVIF_PARAM; | lvItem.stateMask = LVIS_SELECTED | LVIS_FOCUSED | LVIS_STATEIMAGEMASK; | lvItem.iItem = nItem; | lvItem.iSubItem = 0;
Which must be done on one or two places more I think.
Rein.
On October 21, 2002 02:02 pm, Rein Klazes wrote:
This makes r210 work again:
Thank you! Please try V18, it should fix it.
On October 18, 2002 03:35 am, Rein Klazes wrote:
It does. Now it crashes again like it did after the change in rev.
BTW, how did you get it to crash? It starts up, and load newsgroups just fine here...
On Fri, 18 Oct 2002 09:46:18 -0400, you wrote:
On October 18, 2002 03:35 am, Rein Klazes wrote:
It does. Now it crashes again like it did after the change in rev.
BTW, how did you get it to crash? It starts up, and load newsgroups just fine here...
Select a newsgroup, right click and choose "download latest headers" The newsgroup listview then clears and the program crashes. Aparently when it is rebuilding the display again.
Using newsbin 4.05. Wine with no native system dll's.
Rein.
On Wed, 16 Oct 2002 08:17:11 -0400, you wrote:
Hopefully this will eliminate the crash.
It does prevent the original crash (using R2).
Rein.
-
Dimitrie O. Paun -
Rein Klazes -
Rizsanyi Zsolt