What I *THINK* is happening is this: (Please note I did test things and I'm 100% sure what I'm saying is true on my D7 system, but, as I remamber corectly, you're on D6).
You are using the windows-provided PageControl and the MultiLine property on this object is actually mapped to the TCS_MULTILINE style flag used with CreateWindowEx, so this style only has effect when the page control's window handle is created. When you change the MultiLine property at run-time Delphi needs to re-create the window handle for the PageControl so it can specify / remove the TCS_MULTILINE flag. This is a feature of Delphi, not a bug; The alternative would be raising an exception saying "the multiline property can no longer be changed after it's window handle has been created". (i.e: the OS-provided PageControl you see in all windows applications does not provide a way of changing it's multiline style at runtime!) Next, when the page control window handle is destroyed, all it's childrens window handles will be destroyed, and that unfortunatelly includes the TlistView. When the ListView handle is destroyed the underlying object starts issuing OnDelete's (because, as far as the microsoft-provided ListView is concerned, it is being destroyed so it needs to delete all it's items!). After the page control handle has been re-created, the ListView handle will also be recreated and re-populated, so all your TTestObjects get re-inserted, only the have all been freed, so this time they're "zobies". Your next call to free, or your next refference on those objects will result in an AV. This behaviour IS consistent and you'll also see it with TComboBox and other windows-provided controls; This behaviour will not be apparent on 100% native VCL components. Your best option would be re-considering the design and using a different memory-management technique. Ex: use a TObjectList (ex: Dummy:TObjectList) to hold all references to objects that need to be released. After you call ListView1.Clear also call Dummy.Clear! > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:delphi-talk- > [EMAIL PROTECTED] On Behalf Of Richard R > Sent: Friday, December 09, 2005 2:30 PM > To: 'Delphi-Talk Discussion List' > Subject: found a bug and a solution > > Hello, you may recall my previous email that I stated that I get a lot of > access violation errors in a TListView when a pagecontrol's multiline > property is changed. Well here's a test to prove the bug and the solution > to > work around it. > > The bug > > Add a TPageControl on a form and insert a few pages. Add a TListView > inside > one of the pages. Add 3 buttons to the form. Add a OnDeletion event to the > TListView. Use this code for the test. > > TtestObj = class(TObject) > end; > > Implementation > > procedure someOnClickProcedure1(Sender: TObject); > var > i: integer; > begin > for i:= 1 to 10 do > ListView1.AddItem(Format('test%d', [i]), TtestObj.Create); > end; > > procedure someOnClickProcedure2(Sender: TObject); > begin > PageControl1.Multiline:= not PageControl1.Multiline; > end; > > procedure someOnClickProcedure3(Sender: TObject); > begin > ListView1.Clear; > end; > > procedure ListView1Deletion(Sender: TObject; Item: TListItem); > begin > TtestObj(Item.Data).Free; > end; > > Ok by looking at this code, there is no problem right? The OnDeletion code > clears up the memory that was allocated with the AddItem function. No > memory > leaks, every thing is fine. However, setting the Multiline property, when > the TListView is inside the TPageControl, some how activates the > OnDeletion > event. This is the bug, it shouldn't do that, it's not logical. Now to fix > this problem, we simply need a flag to prevent an unlawful deletion. Add a > global or local variable called isDeleting of type boolean. Now we simply > adjust the code like this > > procedure someOnClickProcedure3(Sender: TObject); > begin > isDeleting:= True; > ListView1.Clear; > isDeleting:= False; > end; > > procedure ListView1Deletion(Sender: TObject; Item: TListItem); > begin > if isDeleting then > TtestObj(Item.Data).Free; > end; > > voila! problem solved. > __________________________________________________ > Delphi-Talk mailing list -> [email protected] > http://www.elists.org/mailman/listinfo/delphi-talk __________________________________________________ Delphi-Talk mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi-talk
