-
Content count
8140 -
Joined
-
Last visited
Single Status Update
-
OK well I should probably explain a bit right? The framework sends messages to windows that have already been deleted. It does this constantly. It even does it WHILE the destructor sequence is in progress. The above is a log file showing accesses I have detected to the freed memory which, if allowed to go unchecked, cause access violations.code:
Array
The only solution I can come up with so far is to throw closing forms on a "destroyed forms" set and then check everywhere that matters if the form is on that list. If it is, I issue the message and then get the hell out. Seems to work pretty well, as far as gross-hack workarounds go.- Show previous comments 4 more
-
-
Technician said:
Damn, I though you said VLC. That shit clashes on me like a plane full Arabs.
Heh. Yeah, VCL == Visual Component Library. It's Borland's attempt at a competitor for Microsoft's MFC, supposedly oriented toward RAD, though I don't see how it helps rapidly develop anything frankly.
I guess they mean rapidly develop a bunch of forms and have them crash on you til you code elaborate workarounds that track deleted pointers and disable event handlers until the constructor sequence has finished. And not to mention the fact that listviews commit access violations if their contents are changed while the control isn't visible. This makes tab and page controls really nice to deal with - in the program's main toolbar there is a timer control with which all filtered list views have to register themselves when they want to refresh. That timer will check every 250 ticks for filters that want a refresh, test if they're visible, and refresh them if they are. If not, it's back into the queue!
It would take several years of development time to get all that right, I think. Probably why this system, developed in 2001, only just got fixes for some of them after I arrived 3 months ago ;) -