I am developing an add in that needs to have some custom data management functionalities. In addition to this, I have designed a custom progress window that needs to be updated as progress is made. This requires more information and interface to display it than what can be achieved with the progressor classes available in the ArcGIS.Desktop.Framework.Threading.Tasks Namespace.
What I have built:
I built a custom ProWindow UI that allows the user to view detailed information about data loading progress. For example, something I might do is copy all of the records in one feature class to another in an enterprise geodatabase using table and column mappings from a configuration. I have implemented an observer pattern where my data loading manager class handles registering and executing data loads via another data loader object. My GUI is then subscribed to public actions from my data load manager and when these actions are triggered, methods in my viewmodel update properties that are bound to my UI using the dispatcher to make sure that it happens on the GUI thread. This is working decently and my intended functionalities are working and updating the GUI. However most of the ribbon in Pro is disabled and even my cancel button for the process is getting disabled.
The Problem:
Because I am using API methods throughout that are required to execute on the MCT, I need to use QueuedTask.Run during long running operations. This ends up disabling many UI items in pro for much longer than I would like and it doesn't yield the best user experience. I would prefer if it was running in a background thread that did not block the GUI at all, but certain things necessarily have to run on the MCT and I fear there is no way around this.
What would be the best approach to develop something like this this, so it is not having such an impact on my pro user experience? I have considered that potentially using a custom geoprocessing service and polling for update information might be an option, although it certainly complicates things more. I am just curious if anyone else has encountered this same type of issue and if there are any examples or things I could be looking into to overcome this? Have I hit a limitation of the API ?
Solved! Go to Solution.
Hi @Aashis thank you yes, I am familiar with these documents and asynchronous programming in general. Although after your suggestion I did revisit them just to make sure I hadn't missed something...and you know what.. I think I might have.
So I had not previously known about BackgroundTask. After reading more, it seems this might be fitting for my application since it really should not affect the state of Pro or require user input (other than if they elect to cancel) once started.
Thank you I will look into this further and see if it will fit my implementation.
Have you looked into the Working with Multithreading in ArcGIS Pro and Asynchronous Programming in ArcGIS Pro for patterns on how Esri’s APIs and threading model should be used?
Hi @Aashis thank you yes, I am familiar with these documents and asynchronous programming in general. Although after your suggestion I did revisit them just to make sure I hadn't missed something...and you know what.. I think I might have.
So I had not previously known about BackgroundTask. After reading more, it seems this might be fitting for my application since it really should not affect the state of Pro or require user input (other than if they elect to cancel) once started.
Thank you I will look into this further and see if it will fit my implementation.