Correct me, if I'm wrong, but in XE8'th flavour of FMX, Freeing component implicitly cause all its children (i.e. Components, to which the one, being deleted, is Parent) to be freed as well? Even if these ones are owned by some other component...

-
Correct me, if I'm wrong, but in XE8'th flavour of FMX, Freeing component implicitly cause all its children (i.e. Components, to which the one, being deleted, is Parent) to be freed as well? Even if these ones are owned by some other component... 
What a twist!
http://www.youtube.com/watch?v=4LGu1sOvxYs
http://www.youtube.com/watch?v=4LGu1sOvxYs

Comments

  1. Chris RollistonMay 26, 2015 at 7:01 AM

    If you're referring to what I think you are referring to, that's been there from the off, and follows the VCL (assuming you're talking about desktop/non-ARC)...

    ReplyDelete
  2. Всеволод ГромовMay 26, 2015 at 7:04 AM

    Hm, I thought, that ownership chain ruled the object instances lifetime, not Parent-Children relations.

    ReplyDelete
  3. Chris RollistonMay 26, 2015 at 7:07 AM

    Всеволод Громов both do - the VCL behaviour follows similar logic for windows (HWNDs) at the API level.

    ReplyDelete
  4. David MillingtonMay 26, 2015 at 8:10 AM

    Chris Rolliston How does the parent-child relationship control TComponent descendants' lifetimes?  I also thought it was ownership, always.  I know in the VCL HWND changes require recreation of underlying resources, but not recreation of objects...

    ReplyDelete
  5. Jeroen Wiert PluimersMay 26, 2015 at 8:26 AM

    Chris Rolliston but these handles are being recreated at need.

    ReplyDelete
  6. Asbjørn HeidMay 26, 2015 at 9:11 AM

    Parent can be different from Owner. Last time I checked, which admittedly is ages ago, they were independent.

    ReplyDelete
  7. Всеволод ГромовMay 26, 2015 at 10:08 AM

    What's peculiar here, in FMX, if control C is owned by A, and parented by B, and B is being deleted, it will delete C as well (see DeleteChildren in pas source code).
    I've encountered another side-effect of this approach, while working with third-party control. As soon as actual unparenting and deletion is (I think) delayed in FMX, I got strange situation, in which, despite C->Parent is assigned 0 before B is deleted, the deletion of B results in deletion of C anyway. But only if code is executed normally. If I set code breakpoint right at C->Parent = 0 line, then subsequent deletion of B does not result in deletion of C.
    FMX sometimes is really annoying in side effects, caused by miscellaneous delayed operations executed in unexpected order.

    ReplyDelete
  8. Chris RollistonMay 26, 2015 at 10:35 AM

    David Millington , Jeroen Wiert Pluimers  - I didn't claim the VCL follows the API 'logic' because it has to, just that it follows the same pattern: when a parent control is destroyed, it frees all its child controls irrespective of whether the child has an owner or not (see the implementation of TWinControl.Destroy); likewise, when a parent HWND is destroyed, it destroys all its child HWNDs.

    My guess is that the VCL designers were intentionally following the API pattern (perhaps recreating HWNDs at will wasn't implemented at that point in the pre-release code?), but that's just a guess. Personally I'd rather the behaviour wasn't like this (it still catches me out every so often), but that particular ship sailed 20 years ago...

    ReplyDelete
  9. Chris RollistonMay 26, 2015 at 10:42 AM

    Всеволод Громов - interesting, while I very much agree with your general point about side effects from out-of-order operations, I haven't actually seen your concrete example before though (so far as I know explicit unparenting operations don't ever get delayed, but I may be wrong). Do you have a test case?

    ReplyDelete
  10. Всеволод ГромовMay 26, 2015 at 7:45 PM

    I've tried to create sample, closely mimicking the 3-rd party control usecase. Unfortunately, 'feature' refuses to reproduce there.

    ReplyDelete

Post a Comment