Adding Text Content element in Beta Map popup removes all data from display in Field Map

897
3
02-23-2021 02:58 PM
MikeSlattery
Occasional Contributor

Hi Community,

If I configure my popup to have one (or more) text content elements, that text is all the popup content I get to see when I view a point in Field Maps app on iOS.    If I remove the Text content element from the popup, the popup data will appear on the FM app popup, but not grouped or ordered.

The form based on the converted popup still works in Field Maps with all the collapsible groupings and headings. (That config was saved before adding the text and never changed.)  But you can't see the data in the initial popup.

I can create different Fields content groups on the map without Text content elements, and the popup data will appear on FM, but not grouped or ordered.

Apologies in advance if this was already reported.   If so, please point me to the proper thread. 

EDIT:  This answer by @AaronPulver  tells me that the beta popup isn't supported in the field maps, which is good to know. 

But it would be great if FM would still show the fields in the order that was organized for web popups, so I'll leave this unsolved in case someone from esri can tell us if there will be a stripped version of the pop in the iOS before some fuller support is available.

For now, I think I need to create one map to use FM on the web and another for iOS.  Good thing a 'Save As' brings the form with it!

0 Kudos
3 Replies
KevinBurke
Esri Contributor

Hi @MikeSlattery 

Just wanted to follow-up to first check if you're still running into this issue and second if you are, could you please share a screenshot of what the popup looks like in Field Maps?

 

Thanks

-Kevin

0 Kudos
MikeSlattery
Occasional Contributor

@KevinBurke thanks -  Two updates:  current behavior is the same.  Media elements work fine but the attributes get wiped when text elements are added in the Beta popup. 

The second update is that it seems like the FM app looks at any presence of a "text" element in the popup, then operates in 'custom attribute display' mode using the old standard handler, expecting the first rich content element it processes to contain the complete display. 

So in my case, the text fields are headers and have no {substitutions} so the code accurately shows the single string and that's it.   

That clue came from @AaronPulver 's answer in the OP that the popups are handled with older code.  I opened the beta map in the standard viewer expecting to see the popup treated as unconfigured.   Instead I saw that the popup was listed as having the custom attribute display, with the ability to edit that first rich content element.

0 Kudos
MikeSlattery
Occasional Contributor

Sorry for the delay - I hope to test this out soon!

0 Kudos