MapView.GetOverlayControls returns wrappers instead of added controls

100
3
Jump to solution
05-07-2019 03:34 AM
Highlighted
Occasional Contributor II

Let's see an example:

var mapToolsOverlayControl = new MapToolsOverlayControl
{
DataContext = new MapToolsOverlayControlViewModel()
};

MapView.Active.AddOverlayControl(mapToolsOverlayControl);‍‍‍‍‍‍

Then if I call MapView.Active.GetOverlayControls(), I'll get objects of these types:

ArcGIS.Desktop.Internal.Mapping.Controls.MapCreditsControl
ArcGIS.Desktop.Internal.Mapping.Controls.AirspaceControlWrapper

Where is my MapToolsOverlayControl?

Inspecting things with reflection I found that GetOverlayControls returns UIElements that has UserControl property. So I'm able to find my control with reflection. But why it is wrapped to some internal class (AirspaceControlWrapper)? It's not what user expects from AddOverlayControl.

If you need to wrap added control for some reason, please return new object from AddOverlayControl and give a remark in docs with snippet of how to get a control after it's added on map.

Tags (2)
Reply
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Esri Contributor

So Max, I have looked closely at this and discussed with the original developer.This is designed behavior.

Please use GetOverlayControls to examine which controls are already on the overlay. The returned UIElements can then be queried for their size and placement information [on the overlay]. For example, perhaps you have a preferred placement and prior to adding your control you want to detect if a control (perhaps placed by Pro or another add-in) already occupies that "space". Based on your examination of the existing overlay controls, your logic could adjust your default position accordingly, alter ZOrder, etc.

It is not intended that you cast the controls to their underlying type. Simply use them "as" UIElement. Cast to FrameworkElement also, if needed.

If you do need reference to your control "later on" you should hold a reference to it.

We will update the API reference for AddOverlayControl and GetOverlayControls for 2.4

View solution in original post

Reply
0 Kudos
3 Replies
Highlighted
Esri Contributor

Max, this could be a bug. I'll look into it.

Reply
0 Kudos
Highlighted
Occasional Contributor II

Any news?

Reply
0 Kudos
Highlighted
Esri Contributor

So Max, I have looked closely at this and discussed with the original developer.This is designed behavior.

Please use GetOverlayControls to examine which controls are already on the overlay. The returned UIElements can then be queried for their size and placement information [on the overlay]. For example, perhaps you have a preferred placement and prior to adding your control you want to detect if a control (perhaps placed by Pro or another add-in) already occupies that "space". Based on your examination of the existing overlay controls, your logic could adjust your default position accordingly, alter ZOrder, etc.

It is not intended that you cast the controls to their underlying type. Simply use them "as" UIElement. Cast to FrameworkElement also, if needed.

If you do need reference to your control "later on" you should hold a reference to it.

We will update the API reference for AddOverlayControl and GetOverlayControls for 2.4

View solution in original post

Reply
0 Kudos