[DUG] TListitems disappearing and reappearing causing access violations

Thu Apr 11 15:55:29 NZST 2013

I believe they are networked files, but I don't see that being responsible
for Windows deleting all the listitems.

From: delphi-bounces at listserver.123.net.nz
[mailto:delphi-bounces at listserver.123.net.nz] On Behalf Of David O'Brien
Sent: Thursday, 11 April 2013 10:07 a.m.
To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] TListitems disappearing and reappearing causing access
violations

Are the tracks on a networked drive, or local? Sounds like a hardware
(drive) problem to me.

From: 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 11:24 p.m.
To: 'NZ Borland Developers Group - Delphi List'
Subject: Re: [DUG] TListitems disappearing and reappearing causing access
violations

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] 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] 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>
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] 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>
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] 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>
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] 
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] 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>
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
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to 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
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to 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
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to 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
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
Subject: unsubscribe

-- 
Kyley Harris
Harris Software
+64-21-671-821 

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