wrenczes@gmail.com 60078c34c7 Additional fix to go along with r2834 - the previous fix revealed an ugly interdependency between CardView and MTGCardInstance. Neither object owns the other, but they each have a pointer reference to each other, which is a recipe for disaster if not managed correctly. I had fixed half of the problem, where the status of a CardView being destroyed wasn't reflected in the MTGCardInstance; meanwhile, it introduced another problem where if the MTGCardInstance was destroyed first, the CardView would crash when trying to do the cleanup. ...

This is a classic example of why naked pointers suck!  The right way to fix an interdependency would be to have these objects hold onto weak references to each other. But that's way too big a change at this point in time, so I've added this ugly hack instead.

This will fix an intermittent crash when either accessing the library or exiting a match.

2010-12-16 21:17:18 +00:00

..

mtg

Additional fix to go along with r2834 - the previous fix revealed an ugly interdependency between CardView and MTGCardInstance. Neither object owns the other, but they each have a pointer reference to each other, which is a recipe for disaster if not managed correctly. I had fixed half of the problem, where the status of a CardView being destroyed wasn't reflected in the MTGCardInstance; meanwhile, it introduced another problem where if the MTGCardInstance was destroyed first, the CardView would crash when trying to do the cleanup.

2010-12-16 21:17:18 +00:00