I’m in the process of updating a very large project to API 2.0, which has become more necessary now that in 2024 things like Popovers exist and they can only be opened by DesktopUIControls and not the legacy RectControls.
The structure of my project is a series of various UI classes that are EmbeddedContainerControls. The view hierarchy sometimes is 3 or 4 levels deep of embedded containers inside of embedded containers, etc.
In API 1.0, the code in a RectControl could refer to the Window property to get the container that contains the RectControl. The control could then easily iterate over the Controls list and do things with its peer RectControls. If the RectControl needed the top-level window it belongs to, it could use TrueWindow. Pretty straightforward.
In API 2.0, the code in a DesktopUIControl can get the top-level window it belongs to using Window instead. This appears to simply be a renaming of the old TrueWindow. But how do we get the window that our DesktopUIControl belongs to? It seemed obvious that the Parent property would do this, but alas, it appears that Parent points to the object one level up the the hierarchy that owns the embedded window, and not the embedded window itself.
In other words, my question is – How does a DesktopUIControl that is in an embedded window get a pointer to the embedded window itself so it can iterate over the list of Controls that reside in the same container? The Parent property does not point to the embedded window. Instead it points to an object in the view hierarchy one above the DesktopUIControl, which isn’t particularly useful, as there appears to be no elegant way to get back to the actual embedded window that API 1.0 used to simply provide as Window.
8 posts - 3 participants
