|
POST
|
If you're validating more than one survey question you'll want to store the pulldata results in a hidden question, then extract answers from the JSON object it returns in your "constraint" column, something like: . >= pulldata("@json", ${previous_survey}, "attributes.meter_level") Or whatever your field names are, you get the idea.
... View more
03-20-2025
01:07 PM
|
0
|
0
|
2208
|
|
POST
|
You can combine the pulldata("@layer") function with some additional URL parameters such as orderByFields to sort the results appropriately. That way the data you pull (which is the first record returned by the query) will have the previous results, which you can extract with further pulldata calls and stuff into your comparison functions.
... View more
03-20-2025
12:53 PM
|
0
|
5
|
2240
|
|
POST
|
Unless something's gone sideways, closing the widget should trigger a re-render, which passes the updated state into the widget. Try adding an effect that has props.state as a dependency and it should only fire when that changes. If you need to explicitly look for a change instead of blind-firing on a certain state you can try something like this SO post.
... View more
03-20-2025
12:46 PM
|
0
|
0
|
3432
|
|
POST
|
Ah, found it, it's props.state which is a member of the WidgetState enum. To illustrate what a mess finding this was: functional/pure widgets have no state beyond what you define, what's yoinked from a data store, or what's passed down through the props. All standard widgets take an AllWidgetProps object, which is the sum of WidgetProps and WidgetInjectedProps<T> (where T is the config object?). Buried in the injected props is the RuntimeInfo object which is where the state is stored, presumably because all of this info is coordinated by ExB and drilled into the widgets to keep a nice state tree. So yeah, easy, all you have to do is keep half of the jimu-core types in your head and you can find anything!
... View more
03-20-2025
11:45 AM
|
0
|
4
|
3453
|
|
POST
|
ExB widgets aren't unmounted when you close the widget, they're just hidden. This is normally where I would say how to get that state but the API reference makes it incredibly difficult. You might be able to crawl through this example widget to find an answer, although I think this is more concerned with checking other widgets' states through the redux store.
... View more
03-20-2025
10:57 AM
|
1
|
7
|
3479
|
|
POST
|
The hidden geopoint should be a distinct question, then a separate question has the pulldata call to extract whatever info you need. Note that if you're trying to get the polygon data from the parks to use as your form's spatial data, you'll also have to bind the hidden geopoint to the "null" esri type, otherwise you'll get errors due to the multiple spatial questions.
... View more
03-19-2025
02:26 PM
|
0
|
0
|
2378
|
|
POST
|
Ah, that makes sense. Add a hidden geopoint to your form to capture the user's location, then use the getRecordAt or getValueAt modes of pulldata to select the park that way (the docs have more details).
... View more
03-19-2025
12:57 PM
|
1
|
2
|
2387
|
|
POST
|
At first glance your form looks configured correctly: the user picks a park from the list of possible parks and the pulldata call grabs the exact geometry of that park. Are you trying to do something else? It's not clear what the issue is from how you've written your question.
... View more
03-19-2025
12:46 PM
|
0
|
4
|
2391
|
|
POST
|
Assuming you save the device ID in the results, you can pull data from the previously submitted surveys using the pulldata function to see if the device has a survey logged. In theory you can pull the entire previous survey into a set of fields, then use another set of fields to coalesce that with the current answers to get the final question set, but this will make the survey much more difficult to maintain so you'll have to weigh the pros and cons.
... View more
03-13-2025
03:22 PM
|
1
|
0
|
1093
|
|
POST
|
What is the profiler showing as your hot spots? If the lion's share of the time is spent in rendering-related code you might be out of luck if you want an immediate render using world-space data. Building a full list of graphics elements before adding them to the overlay might help here; you can even try building them in a thread or async task that you cancel on each event to avoid blasting graphics at the map when the user makes quick adjustments. If the bottleneck is constructing the zigzags themselves, two things you can try are: Hoist as many reusable heap-allocated objects out of the function as possible, the less garbage your zigzags accumulate the better. Do all calculations in the map's current coordinate system and try to use the GeometryEngine extension methods to do as much of the math as possible to avoid coordinate errors. This eliminates any reprojection between your graphics and the map.
... View more
03-13-2025
10:54 AM
|
1
|
0
|
3511
|
|
POST
|
It's a bit tricky to see what's going on without proper code formatting but it looks like you're rebuilding the IS layer every loop. Does the tool work correctly if you give each layer a new name every loop? Alternatively, can you hoist the layer out of the loop and build it without an extent? Or do you need to define a layer with a limited extent to ensure the clip works?
... View more
03-13-2025
10:29 AM
|
0
|
0
|
1021
|
|
POST
|
If the incoming data f isn't already a number, you can triage null values like so: Iif(IsEmpty(f), null, Number(f)).
... View more
03-13-2025
08:05 AM
|
0
|
1
|
2747
|
|
POST
|
EGDBs group versioned edits into "states", where the state is chosen based on things like creating new versions, adding a replica etc. If you have something that's expecting to talk to a specific state then that state can't be removed, which means the related edits have to stay in the delta tables. I don't know exactly how things work but if you have no child versions, no replicas and no other connections to the database then a compress should clear out the delta tables. Unless a state entry is "stuck" in the system tables, that's what support can walk you through.
... View more
03-12-2025
02:07 PM
|
0
|
0
|
2109
|
|
POST
|
Record compression (how much is in the business table vs the A/D delta tables) is orthogonal from how many active versions you have. It's possible for a table with only 1 version to still have data in the delta tables because the SDE tables have determined some of those edits belong to an active "state" and shouldn't be relocated. Start by ensuring there are no active connections to the database aside from the one you're running the Compress tool from. If you still have data in the delta tables then contact your support rep and work with them to clear out the stuck states, this'll involve making direct edits to SDE tables and runs the risk of EGDB corruption but there is a process to do this safely.
... View more
03-12-2025
11:03 AM
|
0
|
2
|
2139
|
|
POST
|
To add on to this, if you need to pull one related record to update another, you can try something like this example to update another record.
... View more
03-11-2025
02:43 PM
|
1
|
0
|
1465
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 2 weeks ago | |
| 1 | 2 weeks ago | |
| 2 | 3 weeks ago | |
| 1 | 3 weeks ago | |
| 1 | 07-16-2026 11:42 AM |
| Online Status |
Offline
|
| Date Last Visited |
a week ago
|