Latest Contributions by EricBader

Thanks Boris. I'm sorry for the disconnect and for the lag time in getting back with you. This is critical, I do understand. The team is currently looking into this as we speak. Thank you for your information! We will try to update you regarding this as soon as we can. ... View more

Ok. Yes, I can confirm that this seems to be a bug we are trying to track down. Apologies for the delayed response to this. ... View more

Hello Boris: Is there a public URL that you can share, so that we can have a look at what is going on? ... View more

In this specific case, as you described, you should be OK if your Runtime App uses DirectX. It may not work that well with OpenGL. ... View more

Ok. Here is an update. Yes, using the JEditToolsPicker as-is with your own HitTestOverlay can cause conflicts. Since the source code for this toolkit component is provided, you could edit and recompile it for your own purposes to make this work. The out-of-the-box components are really intended for simple editing workflows. I hope this is useful information. ... View more

Hi David: Yes, this is a very popular request. As it stands right now, there isn't a way to support custom geotransformations in the ArcGIS Runtime SDK for Java. We hope to explore the possibility of adding that capability in a future release. ... View more

Hi Quentin: This sounds like a good question for the "ArcObjects - All Development Languages" forum: http://forums.arcgis.com/forums/20-ArcObjects-All-Development-Languages Have you also posted there? ... View more

Well, you wouldn't necessarily have to, or want to, call Package Map script from a Runtime app. You can run Python on Linux, so turning your MXDs into MPKs is supported there, as long as you have ArcGIS Engine or Server on the Linux machine you are running on. These products come with Python and ArcPy. ... View more

Actually, in the 10.1.1 version coming in December (the next release), this behavior seems to improve. However, there are still some exceptions being thrown when you want to use a HitTestOverlay concurrently with the JEditToolsPicker's edit vertices tool activated. Looking into this. ... View more

This is a good catch. I, too, can reproduce this scenario. There "might" be a workaround, but we are looking into it. Sorry for the inconvenience, but just wanted to let folks know that we are looking. ... View more

It looks like MXD needs to be converted into MPK first before it can be added as a local layer.  Not sure what GP function that could be called to do that conversion and at the same time the function is supported in ArcGIS Runtime. Hi David: You can either create the MPK from the MXD in ArcMap, or you can run some ArcPy scripting to create the MPK from an MXD. http://resources.arcgis.com/en/help/main/10.1/#/Package_Map/0017000000q5000000/. Haven't tried creating a peoprocessing package from a script that calls this function from a Runtime App, but it might work. I hope this helps! ... View more

That is interesting. Do you have ArcMap? Can you see your multipoint features in ArcMap? Can you share a code example? I can use a Graphics Layer with a MultiPoint, no problem. ... View more

Wow. Thank you for posting your findings! I also noticed that if a field has all null values, it won't show up either. Thanks again! ... View more

Hi Donald. Actually, in this case, I think you do need to maintain the data in 2 places. Here is the reason why: In Windows, your data is accessed through a file path that looks like this: "\\NAS1\arcgisdata". But your Linux Server will never be able to make sense of a file path like that. Linux must see the share as: "/array0/dist/docs/arcgisdata". The software looks at these paths explicitly. Therefore, when you try to publish from ArcMap with "'Same as publisher folder path'", it will not work. You will need to copy the data to the Linux machine and tell the Server (during the publish process) to translate the path as it is seen from Windows to a Path that Linux will understand. Alternatively, you can package the data with the Service and not have to worry about it. But still, you will end up with 2 versions of the data either way: one version on Windows, one version on Linux. Does this make sense? ... View more

Yes! This is a very interesting thread, and I hope I can help. Thanks for asking about Runtime vs. Engine: when to go with what. Runtime is certainly the future direction for native, standalone or embedded application development of Apps that work with the ArcGIS System. It addresses many of the "problems" that ArcObjects developers had with Engine, though Engine is a fantastic product, capable of just about anything. Engine is, of course, founded upon ArcObjects. Very, very powerful, but also very heavy and not too modular. 32-bit only. Runtime is not based on ArcObjects. It provides the majority of capabilities that Engine users need, but of course not all. It is very light-weight, registry-free, a bit more modular, easier to deploy, and native 64-bit. Also, could be more cost-effective for deployments. So, think about this. ArcGIS Engine development is your best bet if your application needs to support the following functionality: 3D visualization Heavy "local" data management (lots of shapefiles and ad-hoc data sources) Content Authoring Complex geodatabase feature types Custom ArcObjects Extensions, such as custom datasources and custom renderers, etc. Now, the story is slightly different with Java Engine. Esri would like for Engine Java developers to make their migration plans to Runtime Java as soon as they can. This is the recommended path. If there are hurdles to this effort today, Esri would love to hear about these hurdles and engage with those folks to see where guidance can be provided. The reason for this is, the Esri Java Engine folks are focusing their best work and development efforts into the ArcGIS Runtime SDK for Java. I hope this is helpful! ... View more