There is no WPF control at 10.1, and no plans to include one at this time through the ArcObjects API. Support for WPF continues by using the WindowsFormsHost control as it did at 10.0.
If it critical to use a native WPF control you should look into the ArcGIS Runtime SDK for WPF as a possible solution.
What is the road map for ArcObjects API? Will it eventually be replaced by ArcGIS Runtime? We may need to stay ArcObjects for a few years since most of our clients are still heavily relied on ArcGIS Desktop.
Best regards,
Fayu Lai Principal Software Engineer
Innovyze 618 Michillinda Ave, Tel: +1 626 568 6605 Suite 200 Fax: +1 626 568 6870 Arcadia, CA 91007 USA
There is no WPF control at 10.1, and no plans to include one at this time through the ArcObjects API. Support for WPF continues by using the WindowsFormsHost control as it did at 10.0.
If it critical to use a native WPF control you should look into the ArcGIS Runtime SDK for WPF as a possible solution.
Hi Fayu, That�??s a good question. I think it is important to note that the ArcGIS Runtime is not a replacement for ArcGIS Engine. Those Engine developers who have built solutions with Engine should not be concerned as to the status and future of Engine. Think of the Runtime as another option that a Desktop Developer can use to build their focused GIS solutions with.
We built the Runtime because many customers were trying to build lightweight GIS solutions using local data and were using Engine to do this. They ran into problems because ultimately Engine is not really a lightweight solution. At the same time because the Runtime is a new Architecture we could fix many of the issues that customers have had with Engine, such as giving them a simplified modular deployment, not forcing them to be bound the version of other Esri products, and simplifying the API.
As far as the future, ArcObjects and Engine will be around for a long time, and migration to the Runtime is really not possible for many solutions built on Engine. In time the ArcGIS Runtime functionality will grow and more and more Engine developers may find it a more viable solution. Existing and new Engine Developers who are looking to build lightweight GIS solutions should take a look at the functionality that Runtime provides and see if fits their need.
Hi Ralf,
Thank you for your message.
What is the road map for ArcObjects API? Will it eventually be replaced by ArcGIS Runtime? We may need to stay ArcObjects for a few years since most of our clients are still heavily relied on ArcGIS Desktop.
Best regards,
Fayu Lai Principal Software Engineer
Innovyze 618 Michillinda Ave, Tel: +1 626 568 6605 Suite 200 Fax: +1 626 568 6870 Arcadia, CA 91007 USA
By the way, is ArcObjects still a COM based technology in 10.1 so that you still have to use Winform instead of WPF?
Can you also look at my question in ArcGIS Runtime API for WPF? We need to make some important business decisions on which technology we will adopt these days.
Again, thanks for all of your efforts.
Fayu Lai Principal Software Engineer
Innovyze 618 Michillinda Ave, Tel: +1 626 568 6605 Suite 200 Fax: +1 626 568 6870 Arcadia, CA 91007 USA
Hi Fayu, That�??s a good question. I think it is important to note that the ArcGIS Runtime is not a replacement for ArcGIS Engine. Those Engine developers who have built solutions with Engine should not be concerned as to the status and future of Engine. Think of the Runtime as another option that a Desktop Developer can use to build their focused GIS solutions with.
We built the Runtime because many customers were trying to build lightweight GIS solutions using local data and were using Engine to do this. They ran into problems because ultimately Engine is not really a lightweight solution. At the same time because the Runtime is a new Architecture we could fix many of the issues that customers have had with Engine, such as giving them a simplified modular deployment, not forcing them to be bound the version of other Esri products, and simplifying the API.
As far as the future, ArcObjects and Engine will be around for a long time, and migration to the Runtime is really not possible for many solutions built on Engine. In time the ArcGIS Runtime functionality will grow and more and more Engine developers may find it a more viable solution. Existing and new Engine Developers who are looking to build lightweight GIS solutions should take a look at the functionality that Runtime provides and see if fits their need.
Yes ArcObjects is still COM based; there will be no changes there. I'm not sure what you mean by using a Winform instead of WPF. You can use a MapControl on a WindowsFormsHost in a WPF application. There just isn't a WPF native control for Engine. There shouldn't be any problems with using WPF forms as an extension to a desktop application that I am aware of.
Hopefully playing with the Runtime and comparing it to Engine will help you decide what technology is the best fit for the solution you are building.
