|
POST
|
Preeti, You're my hero, this is perfect. Just putting in the initial extent of the map as SearchArea makes this perform exactly as I would expect, with the same quickness and robust search behavior as Pro. Thank you for bearing with me through this whole process! Thank you!
... View more
05-22-2019
09:08 PM
|
0
|
0
|
1505
|
|
POST
|
Mike, Just wanted to provide some further information, it appears using SuggestAsync on a composite locator that contains a locator created with the new geoprocessing tool of any kind causes this crash.
... View more
05-22-2019
08:25 AM
|
0
|
0
|
9126
|
|
POST
|
Thanks as always Preeti. I've seen some other threads that mention bug reports and being able to provide your customer number for your organization to be attached to a case and it becomes trackable in My Esri. Kimberly McCarty recently described this process in a separate thread. No worries if you don't have the capability or it's going to cause a bunch of work.
... View more
05-21-2019
05:52 PM
|
0
|
2
|
1505
|
|
POST
|
Brad, Having reviewed the Pro SDK information and looking at some basic information in the underlying calls, it's clear that ArcGIS Pro and ArcGIS Runtime SDK are using two completely different methods for getting suggest results from a Locator. It doesn't even appear that ArcGIS Pro relies on a call into RuntimeCore in order to grab the suggestions, thus comparing results from the two is meaningless. Just to clarify, I was referring to ArcGIS Runtime SDK in my previous post, not the ArcGIS Pro SDK. Thanks for your help, but unless there's a way to integrate the Pro components into a WPF app without actually using Pro at all (which, even if possible, I'm guessing would be a violation of ESRI's EULA), I'm going to have to rely on the Runtime team to figure out why there's a difference in suggesting an intersection in Runtime vs Pro using the same Locator and same input text.
... View more
05-21-2019
05:40 PM
|
0
|
0
|
2620
|
|
POST
|
Brad, Thanks for the info. This is probably a long shot but I was wondering if it was possible if the Pro team could share some information on what they're doing under the hood in the Locate process, and if any of this is potentially available to people on the SDK side. Not looking for code or anything, just a vague outline of the calls the locator makes when looking for suggestions.
... View more
05-21-2019
06:04 AM
|
0
|
2
|
2620
|
|
POST
|
Preeti Maske, Just wanted to check in and see if this has been looked at yet, and if it's possibly been declared a bug with a case number I could be assigned to for tracking purposes. I also might reach out to the Pro team to see if there's any insight they can share on what they're doing internally when they make the locate call.
... View more
05-21-2019
06:01 AM
|
0
|
4
|
3437
|
|
POST
|
Michael Branscomb Preeti Maske Hate to do it but have one last question on this. Everything seems to be working with the exception of intersections, passing the / or & character in the SDK to SuggestAsync appears to be completely ignored. Whereas in the screenshot above, I'm able to find an intersection E 49 PL & S 90 E Ave in Pro simply by putting in 49/90, no combination of input seems to work in SDK.
... View more
05-15-2019
06:30 PM
|
0
|
6
|
3437
|
|
POST
|
Preeti, I must admit I'm a bit shell shocked right now. I replaced the Telerik RadAutoCompleteBox with a simple TextBox/ListBox combination and the behavior seems to work perfectly as exacted now, putting in 100 Main now for instance pulls up all of the 100 N/E/S/W Main(s) as desired. I have no idea why the RadAutoCompleteBox was causing different behavior, I can only guess that SearchText is behaving differently than Text does on a normal text input element. Also, on the KeyUp routine, I was using that basically as a last resort. It's checking for the Enter key, not a text change, and if there are no suggestions it's trying to geocode what is typed in the box as a last resort. Thank you very much!
... View more
05-14-2019
08:21 AM
|
0
|
7
|
3437
|
|
POST
|
Just wanted to further clarify, this does not seem to have anything to do with MMPKs specifically, just locators. I tried loading the .loc file directly using LocatorTask.CreateAsync and got the same exact behavior.
... View more
05-07-2019
07:07 AM
|
0
|
9
|
3437
|
|
POST
|
Any ideas on this? The behavior in Pro is absolutely perfect for what I'm trying to accomplish, but if there's no way to replicate the behavior in Runtime then I'm going to have to go a different route such as querying the feature layer, which may be what Pro is falling back to behind the scenes, just need to know.
... View more
05-03-2019
08:27 AM
|
0
|
2
|
3437
|
|
POST
|
It's great that ESRI may have this issue fixed for you, and I'm sure there's likely a reason that you're having to do this in the first place, but I have to say that running a WPF application in an RDP environment has just historically been a very bad experience. You will see performance problems and crashes that you will never get running the app on the machine directly. I would say if there's any way possible to find a way to get the app out of the RDP environment.
... View more
05-02-2019
09:21 AM
|
0
|
0
|
2756
|
|
POST
|
I'm seeing a difference in the way the suggestion/geolocation functionality works in ArcGIS Pro compared to Runtime. I've finally come up with a locator that works the way I want it to in pro, but it does not work the same way in runtime. Search in Pro: Search in Runtime: If I put 9 E Broad in the locator search in runtime, it turns up a result, but that's exactly what I'm trying to avoid. As far as I understand, I'm using the same exact locator in both Pro and Runtime. Please tell me I'm missing something obvious here! Repro Project: https://helpdesk.alertts.com/content/ArcGISApp1.7z Edit: Just FYI, this is a Street Address Locator created in ArcGIS Pro 2.3.2 being consumed by Runtime SDK 100.5.
... View more
04-30-2019
02:19 PM
|
0
|
13
|
5241
|
|
POST
|
Shana, This is helpful, and I think I've gotten the behavior of the locator to where I want it, the problem then becomes the output. It seems as though the input and output are completely tied together. So if I map just the From/To Address Numbers and Street Name in the Field Mapping, I'm able to enter 3113 HOW and get back 3113 S Howard Ave as an example. The problem is, there's seemingly no way to customize the output. The label I get back in both ArcGIS Pro and ArcGIS Runtime is 3113 HOWARD, USA. How does a locator determine what to send back as the suggest "label"? I can't even figure out where it's getting USA as I'm not mapping country anywhere. Is this where the Custom Output Fields come into play? Thanks! Edit: I think I'm at the point where I have to put this back into the hands of the runtime team, although I'm still fundamentally lost on how the output of the locator is built. https://community.esri.com/message/849365-mmpk-locator-discrepency-between-pro-and-runtime
... View more
04-30-2019
11:15 AM
|
0
|
6
|
2620
|
|
POST
|
Shana, Thanks for the suggestion, that's actually exactly what I'm using. The new Create Locator tool is great, it fixed the long running issue with range address locators suggesting street numbers that don't exist, unfortunately I don't see an obvious solution to the predirection/postdirection issue. I tried creating a composite locator with varying levels of mapped information, but it's causing a crash in the runtime that's noted here: https://community.esri.com/thread/232024-access-violation-in-runtime-1005-with-mmpk-containing-composite-locator I'll try playing around with Create Locator and the field mappings to see what I can come up with without creating a composite. Thanks!
... View more
04-26-2019
04:59 AM
|
0
|
8
|
2620
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 06-28-2019 09:01 AM | |
| 2 | 05-05-2020 01:06 PM | |
| 2 | 12-23-2019 01:35 PM | |
| 1 | 12-23-2019 02:06 PM | |
| 1 | 04-15-2019 08:53 AM |
| Online Status |
Offline
|
| Date Last Visited |
08-05-2025
08:44 AM
|