-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dropping last character in QEntryElement fields #13
Comments
Hey Dylan,
I blame this on Apple :). Upgrading the iOS should not break an app! The
upgrade from 13.x to 14.x also wreaked havoc on the text fields. I can’t
recall what I did to fix it. (Maybe just a recompile). I’m traveling until
about April 5, but I will take a look at my notes when I get back and see
if I can’t do the same fix for iOS 15.x
- Regan
…On Tue, Mar 22, 2022 at 10:22 AM DylanSchertz ***@***.***> wrote:
When I picked up Park Observer again for surveys this year I noticed a
weird glitch on some of the iPads. It will often drop the last character
provided to a text field (QEntryElement). This happens most frequently on
the first time you enter data into a field, if you go back and edit a field
it typically keeps that data. So far I have been able to troubleshoot this
down to a change between the iOS versions we were running last year (14.4.2
- 14.5.1) and the iOS we're running on the updated iPads now (15.4).
To reproduce the problem:
Use an iPad running iOS 15.4 with Park Observer on it (either 2.0.0 or
2.0.1).
Start a new survey for any obsprot (so far I have tested it on the Sample
Survey, ARCN Bears, Sheep Short, Spring Moose, and Muskox. I don't believe
this step matters but if it does I would be happy to send you obsprots to
try).
In a text field (on the mission properties or while recording a point)
enter some test data (EX: "TEST") then either tap on the map or tap "Save".
Tap on the point you created, the symbol separating the tracklog, or the
weather icon to review the data you entered.
It should have the data you entered minus the last character. (EX: "TES")
Another interesting note: When you have a list of properties long enough
to scroll down and back up (this does not happen on the sample obsprot
because you cannot scroll) if you enter data, then scroll down to the
bottom then scroll back up to the top the data will often completely
disappear immediately. Then if you tap on the map or "Save" then come back
to the form the data will be back except it will still be missing one
character in most cases.
I have some iPads that have not been updated yet and are still running iOS
14.5 and 14.4.2 and they do not have this issue, it's just happening on the
iPads we updated to iOS 15.4. I have tried installing Park Observer 2.0.0
and 2.0.1 and it seems unrelated to that version difference. It also
appears unrelated to the obsprot (at least among the five I have tried so
far), however it could be they all have the same problem. This only occurs
in the fields that are entered using QEntryElement, I looked at some data
using QSegmentedElement, QRadioElement, and QMultilineElement and those
seemed to be fine.
No pressure to take a look at this issue but thank you in advance if you
do!
—
Reply to this email directly, view it on GitHub
<#13>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAECBKDBLNMRWL2R2FLDKL3VBH6WDANCNFSM5RLQM4OQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Hey Regan, I completely agree that upgrading the iOS should not break an app but that is the most likely culprit. Thank you in advance for taking a look at it! When you get to it let me know if you want any help with testing or if there's anything I can do. -Dylan |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When I picked up Park Observer again for surveys this year I noticed a weird glitch on some of the iPads. It will often drop the last character provided to a text field (QEntryElement). This happens most frequently on the first time you enter data into a field, if you go back and edit a field it typically keeps that data. So far I have been able to troubleshoot this down to a change between the iOS versions we were running last year (14.4.2 - 14.5.1) and the iOS we're running on the updated iPads now (15.4).
To reproduce the problem:
Use an iPad running iOS 15.4 with Park Observer on it (either 2.0.0 or 2.0.1).
Start a new survey for any obsprot (so far I have tested it on the Sample Survey, ARCN Bears, Sheep Short, Spring Moose, and Muskox. I don't believe this step matters but if it does I would be happy to send you obsprots to try).
In a text field (on the mission properties or while recording a point) enter some test data (EX: "TEST") then either tap on the map or tap "Save".
Tap on the point you created, the symbol separating the tracklog, or the weather icon to review the data you entered.
It should have the data you entered minus the last character. (EX: "TES")
Another interesting note: When you have a list of properties long enough to scroll down and back up (this does not happen on the sample obsprot because you cannot scroll) if you enter data, then scroll down to the bottom then scroll back up to the top the data will often completely disappear immediately. Then if you tap on the map or "Save" then come back to the form the data will be back except it will still be missing one character in most cases.
I have some iPads that have not been updated yet and are still running iOS 14.5 and 14.4.2 and they do not have this issue, it's just happening on the iPads we updated to iOS 15.4. I have tried installing Park Observer 2.0.0 and 2.0.1 and it seems unrelated to that version difference. It also appears unrelated to the obsprot (at least among the five I have tried so far), however it could be they all have the same problem. This only occurs in the fields that are entered using QEntryElement, I looked at some data using QSegmentedElement, QRadioElement, and QMultilineElement and those seemed to be fine.
No pressure to take a look at this issue but thank you in advance if you do!
The text was updated successfully, but these errors were encountered: