Re: Windows startup issue

[J. Landman Gay via use-livecode]

I just saw your execution error image, I haven't seen an empty dialog 
before. Did you include a prompt?


I'll try a test tomorrow.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On November 11, 2020 12:55:22 AM "J. Landman Gay via use-livecode" 
 wrote:



Sorry, I meant execution errors. You're supposed to read my mind. I keep
telling my husband that but he doesn't always get it either. ;)

I've used the built-in error reporting mechanism in the past and it worked
well; I usually choose the email option and it works on both deaktop and
mobile. I wasn't aware it was broken. I think it would be difficult to
include that automatically since it requires some input, at least an email
address and ideally a prompt. I suppose a default file could be generated
but the user wouldn't know it unless they were notified.


Lately I've been catching the errorDialog message and handling it myself.
But thinking back to the built-in method, I think it did include the
definitions. It's been a while since we got one of those, but I vaguely
recall reading an email and understanding the problem without needing to
look up any numbers. In that case we just need to include error handling in
standalone settings, which apparently adds the definitions to the app.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On November 10, 2020 8:34:57 PM Richard Gaskin via use-livecode
 wrote:


Compiler errors or execution errors?





___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode





___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Windows startup issue

[J. Landman Gay via use-livecode]

Sorry, I meant execution errors. You're supposed to read my mind. I keep 
telling my husband that but he doesn't always get it either. ;)


I've used the built-in error reporting mechanism in the past and it worked 
well; I usually choose the email option and it works on both deaktop and 
mobile. I wasn't aware it was broken. I think it would be difficult to 
include that automatically since it requires some input, at least an email 
address and ideally a prompt. I suppose a default file could be generated 
but the user wouldn't know it unless they were notified.



Lately I've been catching the errorDialog message and handling it myself. 
But thinking back to the built-in method, I think it did include the 
definitions. It's been a while since we got one of those, but I vaguely 
recall reading an email and understanding the problem without needing to 
look up any numbers. In that case we just need to include error handling in 
standalone settings, which apparently adds the definitions to the app.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On November 10, 2020 8:34:57 PM Richard Gaskin via use-livecode 
 wrote:


Compiler errors or execution errors?





___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Windows startup issue

[Richard Gaskin via use-livecode]

Paul Dupuis wrote:

> I imagine that they could be added to the Inclusions - if on
> automatic, use of the "scriptExecutionErrors" in your code
> would lead to automatic inclusion. If on manual, you get to
> include them or not.

FWIW it's only 29k uncompressed, 7k compressed.

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Windows startup issue

[Richard Gaskin via use-livecode]

J. Landman Gay jacque wrote:

> On 11/10/20 3:28 PM, Richard Gaskin via use-livecode wrote:
>> But at the time it seemed to me the tool was for edge cases where one
>> might encounter raw error data with no UI.  It never occurred to me
>> to ship an application without error handling, and
>> back then I'd never used LC's so I just assumed it was at least as
>> good as my own.
>
> We shouldn't confuse our own error handling with compiler errors. I
> include extensive logging and error reporting when "the result" or
> something similar in my scripts fail. As developers,
> it's our job to do that.

Of course, which is why I've not been able to find the recipe for seeing 
these lists of error info people keep mentioning here and in the forums.


But given the number of times they're cited, it's clear a lot of people 
are encountering them unexpectedly.



> The cryptic numbers only occur when a compiler error happens. A well-
> tested stack won't have many of those by the time it's distributed.
> The one in question here is an odd one-off which only happened for
> one user.

Compiler errors or execution errors?

If this is limited to compiler errors I'm wondering what went wrong 
earlier in the workflow that so many people are able to close their 
scripts and move on without noticing that the Script Editor has been 
trying to get their attention, and that the scripts don't run at all 
until they're compiled.


The Dictionary says compilation errors are only reported in "the result" 
after an unsuccessful attempt to set the script of an object (apparently 
the old scriptParsingError message is no longer sent, though oddly 
enough a handler for it remains in the IDE).


Do we have that many people writing self-modifying code?


Execution errors are what I was referring to in my last post.

As thorough as we may be, in any sufficiently complex code base there's 
likely to be some error condition we didn't explicitly code for.


Our choices are to handle those ourselves with an errorDialog handler, 
or remember to click the checkbox in the Standalone Builder to use LC's 
Execution Error reporting stack.


If you don't do either, errors fail silently (at least when I just 
tested it here with a simple test stack).


But oddly, when I include LC's Execution Error dialog, the result was, 
shall we say, not as expected:

http://fourthworld.net/lc/lc-err-dialog.png

That's in v9.6.1. Their exec err stack used to work. I wonder when it broke.


So for exec errors, at a minimum it would be very helpful to have the 
Execution Error reporting window option set to be included by default in 
new standalones, so that it can become possible for folks to know what 
happened when behavior starts getting wonky.


Later on I have a wish list of improvements for that dialog, but having 
some means of knowing when an error occurs in a form suitable for 
end-users seems a reasonable minimum to expect.



Hard to say what's in play in this thread (and perhaps others like it) 
where the only reported symptom is a list of error info, since Marty's 
description was:


   "The errors show up in a dialog window."

Is that an answer dialog?  Is that an LC lib that does that, something 
Marty wrote, or...?


How can I get a standalone to show me a list of error info like that?

Whatever that recipe is, that's the thing we'll want to fix.



> So it sounds like you're asking LC to translate its compiler errors
> in standalones. These are infrequent enough for me that the numbers
> aren't much of a concern; they largely happen during development and
> those are translated for us. But Paul's suggestion that standalones
> include the entire error list isn't a bad one, though I'd like it to
> be optional.

It looks they did that some time ago - kinda.  The revIDELookupError 
function in "revIDELibrary" includes this tantalizing line:


get line tCode of the scriptExecutionErrors

So it looks like a built-in function now, right?

Not quite: doesn't work in a standalone.

I'm guessing they copy the latest value that returns into their 
Execution Error dialog when you add that checkbox, so custom things can 
do the same. Still an extra step, but much easier than the old method we 
used to use of having to remember which custom property - and before 
that, which hidden field -- of which stack that list was stored in.


But that's for seasoned pros willing to roll their own.

First we need to figure out how people are unexpectedly seeing lists of 
raw error info and turn that into a more useful experience.


Then we can look at enhancing LC's Execution Error dialog, and have the 
default be on rather than off.


After that there are a hundred other paper cuts, but let's see if we can 
knock these off first.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.Fourth

Re: Windows startup issue

[Paul Dupuis via use-livecode]

On 11/10/2020 7:45 PM, J. Landman Gay via use-livecode wrote:
But Paul's suggestion that standalones include the entire error list 
isn't a bad one, though I'd like it to be optional. Users don't care 
what the descriptions are and I can look them up, but some might want 
those included. 


I imagine that they could be added to the Inclusions - if on automatic, 
use of the "scriptExecutionErrors" in your code would lead to automatic 
inclusion. If on manual, you get to include them or not.



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Windows startup issue

[J. Landman Gay via use-livecode]

On 11/10/20 3:28 PM, Richard Gaskin via use-livecode wrote:
But at the time it seemed to me the tool was for edge cases where one might encounter raw error 
data with no UI.  It never occurred to me to ship an application without error handling, and 
back then I'd never used LC's so I just assumed it was at least as good as my own.



We shouldn't confuse our own error handling with compiler errors. I include extensive logging 
and error reporting when "the result" or something similar in my scripts fail. As developers, 
it's our job to do that.


The cryptic numbers only occur when a compiler error happens. A well-tested stack won't have 
many of those by the time it's distributed. The one in question here is an odd one-off which 
only happened for one user.


So it sounds like you're asking LC to translate its compiler errors in standalones. These are 
infrequent enough for me that the numbers aren't much of a concern; they largely happen during 
development and those are translated for us. But Paul's suggestion that standalones include the 
entire error list isn't a bad one, though I'd like it to be optional. Users don't care what the 
descriptions are and I can look them up, but some might want those included.



--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: The Most Stupid Question Ever?

[Bob Sneidar via use-livecode]

I vaguely remember long time, many moons, this came up. The upshot of the 
conversation is that because the message box is a stack file in it’s own right, 
certain features would only work this way, or it would interfere with other 
things if it didn’t work this way. I dunno, it was all all so hazy back then, 
what with having to watch for dinosaurs and large predators with teeth like 
swords. 

Bob S


> On Nov 10, 2020, at 12:03 PM, Bob Sneidar via use-livecode 
>  wrote:
> 
> Ah! That would have to mean that script interaction with the message box is 
> using send in time!
> 
> Bob S
> 
> 
> On Nov 10, 2020, at 10:58 AM, Craig newman via use-livecode 
> mailto:use-livecode@lists.runrev.com>> wrote:
> 
> Not stupid. Wierder than you think.
> 
> Substitute "field 1" for the message box. Works just fine, like it ought to.
> 
> Craig
> 
> -Original Message-
> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf 
> Of Bob Sneidar via use-livecode
> Sent: Monday, November 09, 2020 12:04 PM
> To: How to use LiveCode 
> mailto:use-livecode@lists.runrev.com>>
> Cc: Bob Sneidar 
> mailto:bobsnei...@iotecdigital.com>>
> Subject: Re: The Most Stupid Question Ever?
> 
> I have seen this sort of thing before with the wait command. Very 
> frustrating. Apparently Livecode is not *strictly* single threaded.
> 
> Bob S
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

RE: The Most Stupid Question Ever?

[Craig newman via use-livecode]

"Send in time". Hmmm

So the line "put start"  is actually delayed until after the wait command,
er, starts,  and gets stuck there?

And if one uses "wait with messages" that stuck command can worm its way out
and  back into play?

So then LC knows when the message box is about to be the target, and
therefore acts differently than with any other container. The actual already
executed  command "put" is left stranded, unrequited, because the next line
in sequence, not yet executed,  has foreknowledge that the upcoming target
is the message box, and is girding itself to access it?? 

Odd.

Craig

-Original Message-
From: Craig newman [mailto:cr...@starfirelighting.com] 
Sent: Tuesday, November 10, 2020 5:35 PM
To: 'How to use LiveCode' 
Subject: RE: The Most Stupid Question Ever?

I am switching between the forum discussion about this and here.

The plain old wait command, (without "with messages") works fine when the
target field is on another stack. So it not the fact that the field is not
"local". There is something about the message box itself, ostensibly just a
stack, that matters. This is not the first time that msg has been caught
acting oddly.

 I am actually gratified to know that LC works "normally", as long as msg is
not in the mix.

Craig

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Roger Guay via use-livecode
Sent: Tuesday, November 10, 2020 3:55 PM
To: How to use LiveCode 
Cc: Roger Guay 
Subject: Re: The Most Stupid Question Ever?

Weirder of Weider???

R

> On Nov 10, 2020, at 12:03 PM, Bob Sneidar via use-livecode
 wrote:
> 
>  Wierder than you think.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

RE: The Most Stupid Question Ever?

[Craig newman via use-livecode]

I am switching between the forum discussion about this and here.

The plain old wait command, (without "with messages") works fine when the
target field is on another stack. So it not the fact that the field is not
"local". There is something about the message box itself, ostensibly just a
stack, that matters. This is not the first time that msg has been caught
acting oddly.

 I am actually gratified to know that LC works "normally", as long as msg is
not in the mix.

Craig

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Roger Guay via use-livecode
Sent: Tuesday, November 10, 2020 3:55 PM
To: How to use LiveCode 
Cc: Roger Guay 
Subject: Re: The Most Stupid Question Ever?

Weirder of Weider???

R

> On Nov 10, 2020, at 12:03 PM, Bob Sneidar via use-livecode
 wrote:
> 
>  Wierder than you think.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Windows startup issue

[Richard Gaskin via use-livecode]

Yes, I had my part of the code handy from my custom error handling.

But at the time it seemed to me the tool was for edge cases where one 
might encounter raw error data with no UI.  It never occurred to me to 
ship an application without error handling, and back then I'd never used 
LC's so I just assumed it was at least as good as my own.


Since then I've learned that providing any UI for error handling at all 
is turned OFF by default.


Off.

As in, "Let's make providing a near-useless solution the thing we guide 
new developers to deliver to their customers."


I was brainstorming with Mark Wieder a few weeks ago about adding static 
analysis to IDE error reporting, aiming for something closer to the 
helpful guidance Clang provides.  Even if we did little more than show 
the var values causing something to trip up, it would save tremendous 
time. Aiming higher seems useful. Other tools are getting better all the 
time.


And that's for just the IDE. If LC devs are comfortable with 
state-of-the-art-circa-2003, what we have in the IDE is at least adequate.


For end-users, though, that's where we really want to shine. It's where 
we NEED to shine.


We want new devs picking up LC to look like heroes, and to deliver that 
high-quality experience with less effort than they'd put in with other 
tools.


That's the point. That's why we use LC.

If we can't do that, why are we here?

Everything is undergoing perpetual change. With products there's new 
customer acquisition on the one side, and attrition on the other. As 
long as change is happening, why not direct some of it? Why not aim a 
little higher, to reduce attrition while attracting new users? Sure, 
we'd all like to see that happen, but a hundred paper cuts unattended 
undermine that goal.


And as paper cuts go, error handling cuts deep. It only happen when 
something went wrong. It's an especially sensitive moment in the user 
journey.  We can either lose the user's trust, or retain it.  So much 
about the confidence end-users have in our work hinges on how we handle 
when things go wrong.


Why not aim higher than the least useful experience?

Or to put this more clearly:

254,11,34
301,2,43
262,67,1
12,22,1
132,1,44
73,68,1
241,67,1
353,0,0
433,2,0
201,0,0
88,3,22
322,4,20
568,22,0

--
 Richard Gaskin
 Fourth World Systems



J. Landman Gay wrote:

On 11/10/20 1:14 AM, Richard Gaskin via use-livecode wrote:

J. Landman Gay wrote:

 > On 11/9/20 3:54 PM, Richard Gaskin via use-livecode wrote:
 >> And WTH happened to LC's error reporting dialog?
 >
 > Standalones have always reported this way on both desktop and mobile.
 > It is up to the developer to include the translated references if
 > they want to see those. Generally I don't bother, I provide the
 > optional built-in ability to send email to support or save a file.
 > I can translate the numbers myself since the meanings usually mean
 > nothing to the end-user anyway.

I've been using my own error-reporting for so long I can't recall seeing the default standalone 
handling.


I have made a couple of quickies where I just used LC's error reporting, but clumsy as that 
design is at least the output from the "Send Report" button is more useful than the raw list of 
triplet integers. >

How has such ungraceful error handling become acceptable?

Why is the least useful thing the easiest for new developers to do?

Shouldn't it be easy for LC devs to deliver a great application experience?



I can't remember a time when it *didn't* report the triplets outside of the IDE. That's why you 
and I wrote the Error Lookup stack. ;)


--
Jacqueline Landman Gay | jacque at hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Windows startup issue

[Paul Dupuis via use-livecode]

On 11/10/2020 2:14 AM, Richard Gaskin via use-livecode wrote:

J. Landman Gay wrote:

> On 11/9/20 3:54 PM, Richard Gaskin via use-livecode wrote:
>> And WTH happened to LC's error reporting dialog?
>
> Standalones have always reported this way on both desktop and mobile.
> It is up to the developer to include the translated references if
> they want to see those. Generally I don't bother, I provide the
> optional built-in ability to send email to support or save a file.
> I can translate the numbers myself since the meanings usually mean
> nothing to the end-user anyway.

I've been using my own error-reporting for so long I can't recall 
seeing the default standalone handling.


I have made a couple of quickies where I just used LC's error 
reporting, but clumsy as that design is at least the output from the 
"Send Report" button is more useful than the raw list of triplet 
integers.


How has such ungraceful error handling become acceptable?

Why is the least useful thing the easiest for new developers to do?

Shouldn't it be easy for LC devs to deliver a great application 
experience?




One big thing that LC could do to let developer's improve error handling 
and standalone troubleshooting would be to include the 
"scriptExecutionErrors" in Standalones. I know it is along list, but 
would it really add that many more bytes to Standalones relative to the 
current engine size?


I know you can replicate having the error text present by copying the 
scriptExecutionErrors to a custom property in your standalone, but then 
you have to be sure to update it with each engine release. To just have 
it included when you build a standalone would be much better.



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: The Most Stupid Question Ever?

[Roger Guay via use-livecode]

Weirder of Weider???

R

> On Nov 10, 2020, at 12:03 PM, Bob Sneidar via use-livecode 
>  wrote:
> 
>  Wierder than you think.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Windows startup issue

[J. Landman Gay via use-livecode]

On 11/10/20 1:14 AM, Richard Gaskin via use-livecode wrote:

J. Landman Gay wrote:

 > On 11/9/20 3:54 PM, Richard Gaskin via use-livecode wrote:
 >> And WTH happened to LC's error reporting dialog?
 >
 > Standalones have always reported this way on both desktop and mobile.
 > It is up to the developer to include the translated references if
 > they want to see those. Generally I don't bother, I provide the
 > optional built-in ability to send email to support or save a file.
 > I can translate the numbers myself since the meanings usually mean
 > nothing to the end-user anyway.

I've been using my own error-reporting for so long I can't recall seeing the default standalone 
handling.


I have made a couple of quickies where I just used LC's error reporting, but clumsy as that 
design is at least the output from the "Send Report" button is more useful than the raw list of 
triplet integers. >

How has such ungraceful error handling become acceptable?

Why is the least useful thing the easiest for new developers to do?

Shouldn't it be easy for LC devs to deliver a great application experience?



I can't remember a time when it *didn't* report the triplets outside of the IDE. That's why you 
and I wrote the Error Lookup stack. ;)


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: The Most Stupid Question Ever?

[Bob Sneidar via use-livecode]

Ah! That would have to mean that script interaction with the message box is 
using send in time!

Bob S


On Nov 10, 2020, at 10:58 AM, Craig newman via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

Not stupid. Wierder than you think.

Substitute "field 1" for the message box. Works just fine, like it ought to.

Craig

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of 
Bob Sneidar via use-livecode
Sent: Monday, November 09, 2020 12:04 PM
To: How to use LiveCode 
mailto:use-livecode@lists.runrev.com>>
Cc: Bob Sneidar 
mailto:bobsnei...@iotecdigital.com>>
Subject: Re: The Most Stupid Question Ever?

I have seen this sort of thing before with the wait command. Very frustrating. 
Apparently Livecode is not *strictly* single threaded.

Bob S

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

RE: The Most Stupid Question Ever?

[Craig newman via use-livecode]

Not stupid. Wierder than you think.

Substitute "field 1" for the message box. Works just fine, like it ought to.

Craig

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of 
Bob Sneidar via use-livecode
Sent: Monday, November 09, 2020 12:04 PM
To: How to use LiveCode 
Cc: Bob Sneidar 
Subject: Re: The Most Stupid Question Ever?

I have seen this sort of thing before with the wait command. Very frustrating. 
Apparently Livecode is not *strictly* single threaded. 

Bob S


> On Nov 8, 2020, at 22:31 , Roger Guay via use-livecode 
>  wrote:
> 
> Thank you, Mark. You’re very kind! And very helpful. I do remember now how 
> one needs to wait with messages.
> 
> Roger
> 
>> On Nov 8, 2020, at 9:05 PM, Mark Wieder via use-livecode 
>>  wrote:
>> 
>> On 11/8/20 8:02 PM, Mark Wieder via use-livecode wrote:
>>> On 11/8/20 6:57 PM, Roger Guay via use-livecode wrote:
 Please tell me why this doesn’t work:
>> 
>> ...and that is, btw, hardly a stupid question.
>> You want stupid you'll have to get in line after me.
>> 
>> -- 
>> Mark Wieder
>> ahsoftw...@gmail.com
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Ideas on iOS GPS tracking needed

[Graham Samuel via use-livecode]

Just a little more info for those that are interested. 

In general, it is extremely frustrating having to recreate a solution to a 
problem which has clearly been solved already many times. I can list several 
iOS apps which I use personally that appear to give reasonably accurate 
measures of how far someone has walked, run or cycled. Yet I still have not 
cracked the problem of inaccuracy which essentially causes all the trouble. 
Still trying, obviously.

I did come across an interesting document, an MSc thesis by Benjamin Bennett, a 
graduate student at the University of Oregon, written in 2018, entitled 
"Accurate Distance Calculation Using GPS While Performing Low Speed Activity “. 

https://scholarsbank.uoregon.edu/xmlui/bitstream/handle/1794/23827/Bennett_oregon_0171N_12262.pdf?sequence=1&isAllowed=y
 


Bennett used Android devices, using of course GPS coords, including speed. His 
preoccupations with walking and cycling were very relevant. He himself found 
that the raw GPS point-to-point calculation was pretty good, but I am having a 
really good look at his other methods. His use of speed is interesting: in 
general the speed data gave terrible results, except that it was a very 
accurate way of assessing that the user had stopped moving! This is needed 
because if you simple keep the phone stationary and measure successive GPS 
readings, the GPS inaccuracies cause variations which falsely add to the 
distance calculation. So it would be good to include “idling” detection, which 
he did.

[BTW, you can get the speed from the GPS in iOS in LC via mobileSensorReading, 
although it’s only mentioned in a footnote in the LC Dictionary. It’s an array 
element with the expected key “speed”. Minor update to the Dictionary needed.]

Sorry if all this seems tedious. Despite the frustrations, I still find it 
fascinating.

Graham

PS Kevin Willett did answer me, but he wasn’t very forthcoming about exactly 
how he filters out inaccuracies. Of course he was under no obligation to do so!

> On 4 Nov 2020, at 23:57, Graham Samuel  wrote:
> 
> Thanks Alan and Bob - I was beginning to think I was alone on this one…
> 
> Yes, I do look at horizontal accuracy. I found out the following using my 
> iPhone XS.
> 
> 1. Horizontal accuracy tends to be rather poor for the first 10 to 20 
> readings after activation, typically 65 metres. In context, a test walking 
> round my garden, which is about 110 x 60 meters, can quite often be woefully 
> inaccurate at the beginning.
> 
> 2. Even when has settled down it is still  quite variable, but tends to 
> settle to an average less than 10 metres after a time.
> 
> 3. Occasionally it throws colossal anomalies, like 5000 metres, with a 
> corresponding crazy waypoint taking someone on foot right out of the park.
> 
> Of course I can catch the really big ones and ignore them, especially as they 
> are infrequent (maybe two or three in an hour’s walk); but on my tests, the 
> issue is the points that are a bit out, which can be fairly subtle - I mean 
> if you draw them on a map, they are obvious to the human eye, but detecting 
> them is quite difficult. For those, Bob’s idea is a good one, though of 
> course it works best after the trip has been going for while. Anyway, thanks, 
> I'm planning to use it. I agree seconds is the way to go - especially if the 
> app doesn’t know the intended speed (it might be walking, cycling or driving 
> for example). You can tell the user what you’re doing (some apps do this) but 
> I prefer not to ask the user to make that choice.
> 
> I just bought a little app from the App Store, GPSOdometer by Kevin Willett. 
> This does more or less what I want my app to do (it’s cosmetically quite 
> different), and it offers a “Filter Level” setting, which effectively allows 
> the user to decide how much horizontal (in)accuracy to accept. The level 
> varies between 0.05 and 2.00, where a higher number means a larger tolerance 
> of inaccuracies. I’ve written to Kevin to ask for a little more detail - of 
> course he doesn’t have to reply, but I hope he does.
> 
> I will come back to the list to say how I got on. You never know, this may 
> help others eventually.
> 
> Graham
> 
> PS The only test data I have been able to find for the XCode Simulator is a 
> bike ride in California which runs along giving a succession of GPS . It is 
> quite useful, but naturally it doesn’t involve anomalies.
> 
> 
>> On 3 Nov 2020, at 23:55, Bob Sneidar via use-livecode 
>> mailto:use-livecode@lists.runrev.com>> wrote:
>> 
>> Seems to me if you are tracking linear movement, you need to average the 
>> trending values, say the last 5 or 10 reads, against a time base, and reject 
>> the ones outside an acceptable tolerance. You may reject some good data here 
>> and there, but something grossly outside tolerance should be pretty easy to 
>> gr