[DUG] TListitems disappearing and reappearing causing access violations

Bevan Edwards bevan at achieve.co.nz
Thu Apr 11 23:53:29 NZST 2013


Hi Ross,

Have you perhaps thought that you have approached this in the wrong way?
It is clearly a mistake to maintain a list of TListItems external to the 
TListView control.  I believe you would be better off maintaining your 
list of objects/records with the appropriate structure, and then 
dynamically fill the TListView based on that information.

Check the help about virtual list views and the OnData event.

Regards,

Bevan


On 11/04/2013 3:52 p.m., Ross Levis wrote:
>
> Yes I realize that, but I didn't know that was possible with 
> TListItems which the VCL manages for you.  I need to know what 
> situations will cause that.  I really need access to all the items in 
> the listview immediately at any time.  The app will not run correctly 
> if something is freeing list items willy nilly.
>
> Presumably a RecreateWnd() is being executed on the ListView for some 
> reason other than any code in the software.  I've checked the VCL 
> source code for TCustomListView and where RecreateWnd is being 
> executed, and it's only with a change to a handful of Properties which 
> I am not altering in code. So Windows is doing this itself for some 
> reason.
>
> I think I will have to subclass the TListView's WindowProc property to 
> look for CM_RECREATEWND and WM_DESTROY messages, and stop all 
> processing until this is finished.  Hopefully that will sort it out.  
> What a bloody hassle.
>
> Ross.
>
> *From:*delphi-bounces at listserver.123.net.nz 
> [mailto:delphi-bounces at listserver.123.net.nz] *On Behalf Of *Todd Martin
> *Sent:* Thursday, 11 April 2013 10:04 a.m.
> *To:* NZ Borland Developers Group - Delphi List
> *Subject:* Re: [DUG] TListitems disappearing and reappearing causing 
> access violations
>
> Hi Ross
>
> Clearly the problem is NOT that the items are being removed from the 
> list. Rather the items are being freed, (from previous comments) in 
> various places, yet not removed.
>
> Just because assigned(PlayView.Items[i]) is true, does not mean that 
> that instance exists. It means that the object pointer is not nil. Do 
> you understand the difference between a nil pointer and a pointer to 
> memory that is no longer in use?
>
> Todd.
>
>
>
> I've heard today that TeamViewer isn't in use when the problem 
> occurs.  They often use it to resolve the issue after the problem has 
> occurred.
>
> They tell me they have seen it in mid-song where all the tracks 
> disappear and the app then becomes unresponsive or crashes because of 
> the app still accessing items that don't exist.
>
> There are no deletion routines in the program which delete every item 
> from the listview, so that's not what's going on. Considering there 
> are around 5000 users who have no problems at all, I don't think it 
> can be a coding problem.  There has been the very rare issue like this 
> reported over the years but this one user is getting it regularly, 
> like every couple of days.
>
> I thought I was on to something with remote control app but it appears 
> not.
>
> Another reported crash a couple of weeks ago was here...
>
> i := Item.Index;
>
> while (i < PlayView.Items.Count) and (PlayView.Items[i].Caption = 
> EventTimeStr) do
>
> ...
>
> The "while" line crashed with Access Violation in 
> ComCtrls.TListItems.GetItem, and the screen shot again showed no 
> items.  This should prove that it cannot be the software removing the 
> items as otherwise Items.Count would be 0.
>
> Someone else with dual monitors had a crash on the same line about 6 
> months ago and it has now been modified to validate items[i] is a real 
> item before retrieving the caption.  This will stop the error but the 
> software will not function correctly.
>
> Cheers.
>
> *From:*delphi-bounces at listserver.123.net.nz 
> <mailto:delphi-bounces at listserver.123.net.nz> 
> [mailto:delphi-bounces at listserver.123.net.nz] *On Behalf Of *Ross Levis
> *Sent:* Wednesday, 10 April 2013 2:38 a.m.
> *To:* 'NZ Borland Developers Group - Delphi List'
> *Subject:* Re: [DUG] TListitems disappearing and reappearing causing 
> access violations
>
> I guess I am.  It makes the most sense.  I'll have to try a test with 
> TeamViewer to duplicate it.
>
> *From:*delphi-bounces at listserver.123.net.nz 
> <mailto:delphi-bounces at listserver.123.net.nz> 
> [mailto:delphi-bounces at listserver.123.net.nz] *On Behalf Of *Kyley Harris
> *Sent:* Wednesday, 10 April 2013 12:48 a.m.
> *To:* NZ Borland Developers Group - Delphi List
> *Subject:* Re: [DUG] TListitems disappearing and reappearing causing 
> access violations
>
> I think the problem is that right now you are running on the Theory 
> that they are being reconstructed as you state, and you have not 
> created a test scenario to validate what you are saying.
>
> it could just be a coding error, and the delete event will tell you 
> when a list item is being destroyed. That list item will not be 
> destroyed if the window handle is reconstructed. Not in the source 
> code I can see.,
>
> On Wed, Apr 10, 2013 at 12:41 AM, Ross Levis <ross at stationplaylist.com 
> <mailto:ross at stationplaylist.com>> wrote:
>
> Actually that doesn't help so much.  I really need to know when 
> Windows is deleting the items.  My app also deletes items.  I guess I 
> could remove the OnDeletion event property before coding a delete and 
> reinstate if afterwards.  A little messy.
>
> I really need to associate the individual deleted items with the 
> identical new items that will be created just afterwards.  Ideally I 
> would want my app to stop processing all timers and functions while 
> the deletions and recreations are done.
>
> Getting too complicated.
>
> *From:*delphi-bounces at listserver.123.net.nz 
> <mailto:delphi-bounces at listserver.123.net.nz> 
> [mailto:delphi-bounces at listserver.123.net.nz 
> <mailto:delphi-bounces at listserver.123.net.nz>] *On Behalf Of *Kyley Harris
>
>
> *Sent:* Wednesday, 10 April 2013 12:06 a.m.
>
> *To:* NZ Borland Developers Group - Delphi List
> *Subject:* Re: [DUG] TListitems disappearing and reappearing causing 
> access violations
>
> the listview has an Ondeletion event. when that fires, you should 
> check the index, and remove any listitem references from your tlist.
>
> The issue seems to be that you are mixing view objects with data 
> objects. the system might go more smoothly if you were containing your 
> data objects disctinct from your view (tlistview) and synchronizing 
> the view to the source.
>
> On Tue, Apr 9, 2013 at 11:58 PM, Ross Levis <ross at stationplaylist.com 
> <mailto:ross at stationplaylist.com>> wrote:
>
> It isn't a user initiated procedure.  It's a broadcast media player in 
> automation mode and each track is a listitem. Items can be dropped off 
> the top and more added to the bottom as it plays automated.
>
> There is a TTimer which accesses all the items in the list once a 
> second to provide totals and such.  So the items are accessed very 
> regularly.
>
> Some of the list items are timed events which need to occur at a 
> specific time.  These item pointers are stored in a TList so the 
> software can easily access the next one without having to look for it 
> in the list.
>
> This user has had issues with the code that accesses this TList of 
> TListitem pointers, so that sounds like the pointers to the listitems 
> have been changed.
>
> Ideally the listitems shouldn't be accessed directly and a separate 
> data store should be used that is linked to each item via the Data 
> property.  A bit too late for that now though.
>
> So it sounds like I need to find the Windows message that is being 
> sent to the app to recreate windows and do some housekeeping.
>
> Any ideas what that might be?
>
> *From:*delphi-bounces at listserver.123.net.nz 
> <mailto:delphi-bounces at listserver.123.net.nz> 
> [mailto:delphi-bounces at listserver.123.net.nz 
> <mailto:delphi-bounces at listserver.123.net.nz>] *On Behalf Of *Kyley Harris
> *Sent:* Tuesday, 9 April 2013 11:35 p.m.
>
>
> *To:* NZ Borland Developers Group - Delphi List
> *Subject:* Re: [DUG] TListitems disappearing and reappearing causing 
> access violations
>
> If that was the case.. then its unlikely to happen midstream during a 
> very small short procedure call. Especially if that procedure call is 
> a user initiated one.
>
> if that is the case.. its extremely simple to test this with remote 
> desktop and some logging of the construction/destruction of the list 
> items.
>
> On Tue, Apr 9, 2013 at 11:29 PM, Ross Levis <ross at stationplaylist.com 
> <mailto:ross at stationplaylist.com>> wrote:
>
> I've had someone suggest this elsewhere...
>
> /The user connects a monitor to a laptop, or connects remotely via
> terminal services.
> Basically, anything that changes the display resolution has that kind of
> consequences./
>
> I have seen a TeamViewer in one of the many screen shots.  So I guess 
> Windows is recreating the windows and allocating new handles to the 
> list items as I thought.  I'll check with them if the crashes coincide 
> with use of TeamViewer.
>
> Ross.
>
> *From:*Ross Levis [mailto:ross at stationplaylist.com 
> <mailto:ross at stationplaylist.com>]
> *Sent:* Tuesday, 9 April 2013 11:17 p.m.
> *To:* 'NZ Borland Developers Group - Delphi List'
> *Subject:* RE: [DUG] TListitems disappearing and reappearing causing 
> access violations
>
> The list is populated by the software.  It's still in Delphi 7.
>
> No threads are deleting any items.  Only the main thread adds and 
> removes items.
>
> There is no one procedure this has occurred in.  It can work for 2 
> days and suddenly this happens in a random procedure that accesses a 
> list item.
>
> In this particular case, it is in a procedure where one specific 
> listitem is sent as a parameter.
>
> Here are some of the relevant lines of code in the procedure being 
> executed.
>
> if Item <> nil then
>
> begin
>
>       if Item.Selected then UpdateButtons;
>
> ...
>
>       Item.ImageIndex := 8;
>
>   end;
>
> There are no deletions in the procedure.
>
> The Item.Selected test works fine but Item.ImageIndex := 8 crashes at 
> TListItem.SetImage with an access violation.
>
> The item existed and then no items exist based on the screen shot.
>
> I've been having to put validations all over the place like this...
>
> if ListView.Items.IndexOf(Item) >= 0 then Listitem.ImageIndex := 8.
>
> This user has had a crash where it does this validation up the 
> procedure somewhere which validated, but further down it will be 
> accessing Item.Index and this crashes.
>
> It's a nightmare.  I'm wondering if it could be corrupt RAM in the PC 
> or something.
>
> Cheers,
>
> Ross.
>
> *From:*delphi-bounces at listserver.123.net.nz 
> <mailto:delphi-bounces at listserver.123.net.nz> 
> [mailto:delphi-bounces at listserver.123.net.nz] *On Behalf Of *Kyley Harris
> *Sent:* Tuesday, 9 April 2013 10:33 p.m.
> *To:* NZ Borland Developers Group - Delphi List
> *Subject:* Re: [DUG] TListitems disappearing and reappearing causing 
> access violations
>
> without seeing the 10lines above, and whats inbetween (if you were 
> being literal) its very hard to say.
>
> The only time I've ever had something dissapear from a list is when I 
> deleted it though a callback, method, thread etc.. or freeing something.
>
> what version of delphi is the code now? How does the list get 
> populated or edited by the application..
>
> I'd start by looking at how many locations of code insert or delete 
> the list items, and verify none are being called while your procedure 
> is executing its for-loop, (assuming the access violation is an index 
> based one because of the list count change)
>
> On Tue, Apr 9, 2013 at 10:21 PM, Ross Levis <ross at stationplaylist.com 
> <mailto:ross at stationplaylist.com>> wrote:
>
> Wondering if anyone has any ideas.
>
> I've had this problem a long time from when I started writing an app 
> about 7 or 8 years ago, but it happens so rarely it's not usually an 
> issue. But one user in particularly is regularly sending me MadExcept 
> reports which either have access violation errors or "the application 
> appears to be frozen". In all cases it's during an access of a 
> TListItem which was perfectly valid 10 lines of code up a procedure 
> but suddenly doesn't exist.
>
> The screenshot created at the same time shows the ListView has no 
> visible items, but I know for a fact there are 30 or more items in the 
> list. I believe sometimes the items visually disappear and reappear 
> shortly afterwards, like a Desktop refresh.
>
> I think I've heard something about Windows recreating the window 
> handles or some such thing. I don't understand why it would do so. 
> There are no changes to the listview that would require re-creating 
> the window.
>
> Any ideas?
>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at listserver.123.net.nz <mailto:delphi at listserver.123.net.nz>
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at listserver.123.net.nz 
> <mailto:delphi-request at listserver.123.net.nz> with Subject: unsubscribe
>
>
>
>
> -- 
> Kyley Harris
> Harris Software
> +64-21-671-821
>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at listserver.123.net.nz <mailto:delphi at listserver.123.net.nz>
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at listserver.123.net.nz 
> <mailto:delphi-request at listserver.123.net.nz> with Subject: unsubscribe
>
>
>
>
> -- 
> Kyley Harris
> Harris Software
> +64-21-671-821
>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at listserver.123.net.nz <mailto:delphi at listserver.123.net.nz>
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at listserver.123.net.nz 
> <mailto:delphi-request at listserver.123.net.nz> with Subject: unsubscribe
>
>
>
>
> -- 
> Kyley Harris
> Harris Software
> +64-21-671-821
>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at listserver.123.net.nz <mailto:delphi at listserver.123.net.nz>
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at listserver.123.net.nz 
> <mailto:delphi-request at listserver.123.net.nz> with Subject: unsubscribe
>
>
>
>
> -- 
> Kyley Harris
> Harris Software
> +64-21-671-821
>
>   
>   
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post:delphi at listserver.123.net.nz  <mailto:delphi at listserver.123.net.nz>
> Admin:http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email todelphi-request at listserver.123.net.nz  <mailto:delphi-request at listserver.123.net.nz>  with Subject: unsubscribe
>
> -- 
> /Fortune/ favours the *brave*
>
>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at listserver.123.net.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with Subject: unsubscribe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20130411/cd30e58d/attachment-0001.html 


More information about the Delphi mailing list