Neven wrote: > Thats why I though a Items.BeginUpdate would suppress events > on the strings > Usually as someon else posted, if this is a problem they may have a > preceding event
Yeah. I saw that. I haven't checked the VCL source but I suspect even calling BeginUpdate will likely still involve the Items TStrings wrapper trying to talk to the dead COMBO to ask it to not repaint as items messages are sent. Catch 22. The destructor is obviously too late to talk to Items on a Tcombo (at least, unless you hold your mouth right). That's the problem with leaky abstractions (i.e. wrappers) and mismatched lifetimes. The VCL can only hide so much behind it's skirt whilst still tring to leverage the Windows builtins. Don't get me wrong. Borland did a pretty amazing job, but I sometimes wonder why they spent so much time cleverly wrapping the nasty windows builtins and replicating the faulty dialog manager design. I suppose it all looked like a good idea when they started. i.e. first 90% done, only remaining 90% left to go. But using TCombo replacements written in pure Delphi would have been so much simpler as a design model. It sure would have obviated the Kylix/CLX deadend for Borland, but anyway, that boat has already sailed. Or you can go and build your own boat :-) Did Bristol ever get into shipbuilding? <Insert analogy here> TTFN, Paul. _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
