ArcGIS ProWindow binding child view to viewmodel through datatemplate

[AzharIbrahim]

I did a test project with a main window, and changing out the content based on the selected viewmodel. This worked fine using data templates and binding content to the viewmodel.

I created an ArcGIS Pro addin using ProWindow. This window is using the main view model fine. If I add a view to the xml directly and set the data context of this view to the child view model, this displays fine. If I try to use a datatemplate for the viewmodel to bind to the view, I only see the name of the viewmodel class.

Since the ProWindow, does not create the app.xaml, I can't add the datatemplate to the app.resources, but have added it to the prowindow.resources. I'm not sure what else to try.

Adding the datatemplate worked fine in my other project, so I'm not sure what may be going on. I was using a bindable base class implementing INotifyPropertyChanged for all of my view models. I switched it over to the ESRI framework version just in case, with no change in outcome. I am new to WPF which is why I tested it separately from the ArcGIS Addin project first.

[Wolf]

Can you attach a sample solution (a simple add-in with your ProWindow) that includes your issue?   Our ProWindow item template doesn't support MVVM out of box.

[AzharIbrahim]

I have my current version that I'll attach. a main view with a content control bound to a view model. If I actually replace the content control with the view and set the data context to the view model it's fine. I want to be able to switch out views though during the pre-processing of input data. I've tried putting the data template inside the resource dictionary with no change. I've only added a single property to test the bindings

[AzharIbrahim]

Should I switch over to dockpane instead? My workflow will be to preprocess the camera/frame data before adding frame camera data to a mosaic dataset. I was planning on several views to handle the inputs, etc.

[Wolf]

Sorry about the delay but we started with the 2.7 Pro & Pro SDK release, so we were very busy for the last few days.  

Regarding your UI design, I would definitely go with a Dockpane.  Dockpanes are singletons and can be docked or can be floating, they will also open automatically if Pro was closed with a dockpane open, making it the better choice.  

As for the ProWindow, there is a MVVM samples available here: arcgis-pro-sdk-community-samples/Framework/ProWindowMVVM at master · Esri/arcgis-pro-sdk-community-s... Regarding the approach you took with the solution you attached, you cannot use any ArcGIS Pro components (like ProWindow, Dockpane) unless the component is part of either an 'Add-in Module' or a 'Managed Configuration'.  Both (add-ins and configurations) are run from within ArcGIS Pro as extensions and they cannot be run from standalone WPF applications.  Pro SDK UI components require the UI Framework that is built into ArcGIS Pro.  

You can look through our samples to get an idea of what is possible with the Pro SDK UI.  Most samples have a few screen shots attached to the documentations, like for example here (scroll to the bottom of the page to get the description on how to use the app):  arcgis-pro-sdk-community-samples/Map-Exploration/BingStreetside at master · Esri/arcgis-pro-sdk-comm...

I hope this helps.

[AzharIbrahim]

For the sample I attached, it was an ArcGIS pro module with the pro window added as an ArcGIS component. I'm currently testing options for the UI, before I start on the view models. If the bindings don't work the same way that they did in my standard wpf project, I'll need to sort this out first.

I was trying to bind the view to the current view model as a way to switch views for the pre-processing of different input data. I tried using the dockpane today, and it had the same issue with binding the view to the selected view model. I may have to just set up all of my views for the different parts of my tool and set the data context from the view. I prefer the other way.

I would rather the tool only open if the user clicks the button and not remain open, which is why I went with the ProWindow.

I'll take a look at the links you supplied.

Thank you for your feedback.

[Wolf]

Under the Pro UI Framework the data context is set using the className attribute of the dockpane tag from the config.daml.  In the config.daml snippet below, the DataContext is set to FlightDataViewModel for the FlightDataView view class.  This is done when the Dockpane is activated for the first time.

<dockPane id="xxxx" caption="..." className="FlightDataViewModel" dock="bottom">
  <content className="FlightDataView" />
</dockPane>

 In order to show/hide a dockpane you can use this code:

string _dockPaneID = "xxxx";  // DockPane ID from config.daml above
DockPane pane = FrameworkApplication.DockPaneManager.Find(_dockPaneID);
// pane not found
if (pane == null) return null;
// pane is already displaying
if (pane.IsVisible) return pane;
// activate (show) the pane, Activate method has optional focus parameter
pane.Activate();

// or hide the pane
pane.Hide();

[AzharIbrahim]

I  did some more testing today and was able to get my child views working as expected. I just have a couple of very simple child views to verify that the datatemplate binding is working correctly.  I started over with the ProWindow, but may switch over to dockpane later.. I like that the pro window viewmodel is separate from the view. I think I'll be able to separate out the pre-processing steps to different views and it will work better for the end user.

Is there a way to pass a parameter to the RelayCommand? I would like to have a single command for changing the view model and pass it a string value.

Nevermind--I found the override on the constructor to pass in a parameter. Nice to simplify to a single change view method.

[Wolf]

Yes you can pass parameters. If you search for CommandParameter in the XAML for this sample: ProWindow MVVM you can find an example of RelayCommand parameters.

[AzharIbrahim]

Thank you--I found the constructor override just a bit ago. I didn't have an issue on the xaml side. It was figuring out the constructor for RelayCommand that would accept a type. I didn't realize I would have to add all of the other parameters even though I'm not using them.

ArcGIS Pro 2.7 API Reference Guide - RelayCommand Constructor(Action<Object>,Func<Object,Boolean>,Bo...

Thank you again for your help. It's a big change switching from winform/arc objects to wpf/arcgis pro.