Thanks! I saw it happen with a trace as well so assume it also affects shape too.
By no means a roadblock, but found while testing WF against Collect - the combined minimal columns-n / minimal autocomplete columns-n appearance will only render a single column in Webforms.
The feature matrix is 
for each individually, but there isn't a special row for the status of various combinations of appearances that are possible in Collect.
I was surprised to read that minimal might combine with columns-n in Collect so I tried it out. It seems to partially work but in my simple form select_apps.xlsx (9.5 KB) labels aren't displayed correctly. I think it might be be a bit of an accidental feature. I've always thought of minimal as "taking over" and leading to other appearances other than autocomplete being ignored. That's not from the documentation or anything, just my own assumptions!
In Web Forms, minimal choices are in a drop down. What kind of presentation would you expect? Still a dropdown but multiple choices on each row? What's the use case?
This is an ongoing challenge that goes beyond appearances! So many form definition features can combine in interesting and sometimes surprising ways. We try to test as many combinations as we can but we definitely have gaps. We appreciate everyone reporting combinations that don't work as expected!
Related to this issue #892, I'm hitting a similar problem, where I am calculating text field content into another field, but the calculation has a once() as I don't want to wipe any existing content from it.
No matter how fast I mash the keyboard, I can only ever get the first character into the next field, unless I paste text into it. Ideally the calculation would trigger after finishing typing and leaving the field and not immediately on first keypress.
For now I'm trying an alternate expression that doesn't rely on once()
ODK Web Forms works differently to Enketo and Collect in that it updates the value and triggers the calculations every time a letter is typed into a text field. This has some benefits like being able to update constraint messages as soon as the text is valid, but it will mean your once function is executed earlier than you expect.
To help us understand your workflow can you give more information about how you're using once? Why is it important for your use case to stop the calculation from updating field if the user modifies the original value later?
I ended up with other issues with this combined "lookup existing value vs prefill from another field but don't clear entered content" and wound back the complexity as i don't think the workflow is optimal.
So this behaviour isn't a blocker for me currently.
background-geopoint is missing from the question matrix (start-geopoint is present)
It also cannot be triggered in WF and forms with it will not load.
the docs example has it triggered, and you can't even upload a form without a trigger or you get:
The XLSForm could not be converted: [row : 2] For 'background-geopoint' questions, the 'trigger' column must not be empty.
but when a form that does have the trigger is attempted to be opened this error occurs
An error occurred while loading this form
Unsupported trigger value type: geopoint
use the example form here and change the geopoint to background-geopoint.
While #849 has been resolved and repeat instances aren't deleted with repeat count, clicking ā® then Remove will instantly remove the instance without a confirmation dialogue. Enketo & Collect both have a confirmation to prevent an accidental deletion.
Hi @ahblake, the background-geopoint and start-geopoint use the same setgeopoint action; it's just that each uses different events:
- start-geopoint:
<odk:setgeopoint ref="/data/start_location" event="odk-instance-first-load"/> - background-geopoint:
<odk:setgeopoint ref="/data/name_location" event="xforms-value-changed"/>
These should be available in the previous release. Could you try these minimal forms?
startgeopoint.xlsx (5.9 KB)
backgroundgeopoint.xlsx (5.9 KB)
Yes, this was intentionally designed this way to keep things simple. Since it already takes two steps: tap the menu, then tap the "remove" option, we thought the action would be intentional and that adding a third step could feel annoying. However, we're looking for feedback. Have you heard of any complaints about accidental deletes from users in the field?
This does indeed work in WF 1.0.3, while the form I linked to in my post still throws this error on load;
An error occurred while loading this form
Unsupported trigger value type: geopoint
I stripped the form I linked to down bit by bit until it almost matched yours exactly but it still errored. And then realised I had text in the label field for background-geopoint. This is what is causing the error on load in WebForms. Clearing the label for it let the form load and work.
No I haven't to date, I only mentioned it as the other have confirmation warnings.