Latest Contributions by dotMorten_esri

WPF's drag events applies to classes that inherits from UIElement, which Graphic does not, so you can't really use those events to drag the graphics themselves. You can read more about WPF's drag/drop API here: Drag and Drop Overview | Microsoft Docs  You could probably use that to "fake" the effect of dragging a graphic to another window. ... View more

It's interesting you only see if on your build server. Are the Visual Studio versions significantly different? Are you building in release locally as well? It seems some sort of corruption is happening so it's calling into the wrong methods. ... View more

Yup that works. You can also use the shorthand feat.Attributes["OBJECTID"] ... View more

Could you share some more information about this? What does you app do, what platform and device is it running, do you have a full output log etc? ... View more

> it seems so odd that functionality like Identifying/Querying Map Layers is only available on the MapView  This is fair criticism, but something to keep in mind is that Identify is a very UI-centric thing. It (typically) deals with the user actually clicking on the view, it's inputs are actual screen coordinates (not map unit coordinates), and the hit test is done based on the rendering of the features (so a large point symbol will still get found even if you don't click exactly at the center of the point). You could instead do a spatial query of features based on map geometry directly against the layers without the view, but that's not really "identify" in the usual respect. There really is only two operations directly on the view: The various Identify and SetViewpoint* operations, which all are very specific to working with the view. Pretty much everything else is tucked into objects you can put in your view model, like the Map, GraphicsOverlay, the location datasource, editor etc. A good equivalent is the ScrollViewer/ListViews: They have view-specific operations for scrolling to a certain item/offset, and very much akin to the SetViewpoint method, and clicking an item is very much identical to the identify operation. None of these you can't really do without some view specific stuff. Also one thing to consider: IMHO the purist MVVM approach where absolutely no code-behind can ever exist isn't really true to what MVVM is saying. You can have code-behind, as long as that code-behind is view-specific. For example a click handler that performs the identify, and then forwards the result to the view model is still completely ok and within MVVM. Sure you can do all sorts of tricks and jumps to mask that code into various attached properties etc, but you're just adding an enormous amount of complexity only to pretend you moved your view code out of your code behind, when really all you did is move your view code into some other view code, and in the process made your code much harder to follow and understand. It might make sense to do these tricks if you have any different views and want to reuse that same logic over and over again, but always I'd say to weigh the added complexity with the cost. ... View more

I doubt the clean cache would help. Some system info could be useful. Also try to see if you reproduce the problem on a different PC. It would be good if we could narrow down what causes this problem to happen just for you. ... View more

I'm not aware of any - it's most likely a Xamarin problem so their forums would be good to reach out in. The fact that a new app doesn't exhibit this behavior indicates something in the project/device has gone wrong for that app. You could move the code over the functioning project instead? Does this problem also happen if you deploy to a different device? ... View more

The ESRI.ArcGISRuntime.dll is actually only this big because it has the .so file packaged inside it (that's how Xamarin.Android packages native libraries with .NET class libraries). Once you compile and link your app that problem should go away. Did you use the Xamarin linker options and compile for release builds? See more about the linker options here: Linking on Android - Xamarin | Microsoft Docs  ... View more

Thank you for sharing that. For what it's worth, the app works on my machine, so we're most likely looking at some system configuration thing here (any detail you can share here would be useful too - like system info, is it a VM and what kind, graphics hardware, is it remote desktop etc). The minidump is really only helpful in the sense that I can see it happens while creating the native underlying MapView's background, but no clear indication why it's failing (a full dump might tell us more). To trouble shoot a little, could you try naming the MapView "mapView" in xaml, and then add this to code-behind right after initializecompont: mapView.BackgroundGrid.IsVisible = false; mapView.BackgroundGrid.GridLineWidth = 0; mapView.BackgroundGrid.GridLineColor = System.Drawing.Color.Black; mapView.BackgroundGrid.Color = System.Drawing.Color.Black; mapView.BackgroundGrid.GridSize = 2; If that does resolve the problem, try narrowing down which of the above lines fixes it. That might give us a little more to go on. > BTW, is there any public symbol server available offering the *.pdb files for the published ArcGIS Runtime versions? We're still working on publishing Update 6 symbols, and a blogpost will go out soon describing how to use them. I do believe it'll just be the WPF symbols in the first round (I'll look into the status/plans for UWP symbols).. ... View more

It's not a whole lot to go on. Do you have a small sample you can share that reproduces this problem?  Also enabling mixed debugging in the project settings will give you a better stacktrace you can share and at least a little more to go on (but a reproducer would be the best) ... View more

It should be. I haven't seen a case where the underlying Forms renderers aren't hooked up at that point. ... View more

A slightly different/simpler approach is just to wait for the Page.OnAppearing event to fire. This event ensures the Xamarin.Forms renderers are correctly hooked up to the native underlying view. Generally I'd recommend to wait with doing too much to the MapView until this event fires. Currently LocationDisplay isn't settable, which prevents us from linking it to the native view until that link has been established (we're hoping to make it settable so this specific change in behavior could go away). It was, believe it or not, a bug that there was an underlying native view prior to the appearing event, which caused a slew of life-cycle issues. that we now addressed in Update 6. Unfortunately you might see a couple of these behavioral changes due to us fixing this problem. Good feedback that we should have documented this change in behavior. We'll try and get that addressed. ... View more

It's had to say without seeing your code, but typically, all you need to do is call base.UpdateLocation(...) with the new location. I wonder if there's something on the location you're sending that is throwing it off or making it not work (like invalid values, ie NaN, negative speed, invalid course etc - those things should be handled or throw argument exceptions, but could be it gets swallowed or something). ... View more