Re: Device implementation problems

2017-11-04 Thread Pyyhtiä Christer via use-livecode
Jacqueline,

this something I suspect as well.

As there are a zillion different Android devices with different performance 
capabilities one has to use the belt and suspenders. In January I will be 
trying with iOS as well, and see if there is a difference.

In the longer term a solution could be an extension to LC, "go to card xyz with 
/ without waiting"; or making a docuentative recommendation being aware this 
possible issue.  And it is not yet excluded that I will find a typo or some 
illegal way of coding in my app.

christer

Message: 22
Date: Fri, 3 Nov 2017 22:44:21 -0500
From: "J. Landman Gay" mailto:jac...@hyperactivesw.com>>
To: How to use LiveCode mailto:use-livecode@lists.runrev.com>>
Subject: Re: Device implementation problems
Message-ID: mailto:d0ef401f-b0c1-93a9-85a1-6058181fb...@hyperactivesw.com>>
Content-Type: text/plain; charset=utf-8; format=flowed

On 11/3/17 12:55 AM, Pyyhti? Christer via use-livecode wrote:
> When I issue the "go" and let the script run, many of the objects won't get 
> done completely, for example card background, button or field colouring gets 
> only partially done.  However, if I either add "lock screen" before the "go" 
> statement, or issue "wait 100 milliSeconds" after the "go", everything is OK.

It almost sounds like LC has finished issuing all the commands to redraw 
the screen but the graphics card or the CPU on the device is slow to 
respond. So LC thinks it is finished and moves on to the next line of 
the script while the hardware is still catching up.

I'm not even sure that's possible but that's what it sounds like.

-- 
Jacqueline Landman Gay | jac...@hyperactivesw.com 
<mailto:jac...@hyperactivesw.com>
HyperActive Software   | http://www.hyperactivesw.com 
<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: Device implementation problems

2017-11-04 Thread Pyyhtiä Christer via use-livecode
That is true.  However, just adding the single command "lock screen" before the 
"go card xyz" removes the problem.  I have tried to understand what could be 
"illegal" in the target device point of view in the script code following, but 
so far haven't figured it out.  Actually the script runs until the end, and 
does not exit.  The process this happens is rescaling all the cars of the 
stack, from figuring out the screenRect and then calculating how everything 
would fit on the virtual paper in the optimal way.  If the script is allowed to 
run without locking the screen, filling the background and fields is completed 
only partially, but simultaneously setting the loc seems to work ok.

What I observe is that the colouring of the background & the fill of those 
objects stops randomly as the next object size setting starts.  I do hope I 
will find out a typo, which could be referring to another object - but why then 
lock screen or wait for x milliSeconds would remove the problem?

When you say exit to the top, wouldn't it mean that the stack script execution 
stops?

christer


I've seen this happen when something goes wrong in the code and in a standalone 
that can fail silently. If it does, the engine exits to top and that is why 
things get left undone. 

Bob S


> On Nov 2, 2017, at 22:55 , Pyyhti? Christer via use-livecode 
> mailto:use-livecode@lists.runrev.com>> wrote:
> 
> A few days ago I raised the question on how the device behaviour differs from 
> how it is in the IDE environment.  The question posed was if there is a 
> command
> 
>   go card "xyz"
> 
> and the script continues to run immediately, would there be interference in 
> terms of "getting the go done".
> 
> Interpreting a couple of answers, thank you, I understood that it would not 
> cause problems.
> 
> However, there can be interference, and I could prove it and repeat it.  As 
> follows.
> 
> - The target is Android device (I am using an old Samsung Galaxy S4 
> thanks to its screen pixel size (and despite of having dropped it both on 
> concrete and in a lake quite a few times still does great job)
> 
> - In the app there is a virtual screen (card is larger then the # of 
> pixels on the physical screen), and there are about 100 objects on it.  The 
> card is resized based on the screenRect parameters in several sets of 
> different objects, the amount of code running through is maybe > 1000 lines 
> of LC.
> 
> - When I issue the "go" and let the script run, many of the objects won't 
> get done completely, for example card background, button or field colouring 
> gets only partially done.  However, if I either add "lock screen" before the 
> "go" statement, or issue "wait 100 milliSeconds" after the "go", everything 
> is OK.  And all of this can be repeated.  The Android device is kept off 
> other duties, so that it is not getting vast amount of interruts.
> 
> Now, the above method helps me to solve the problem, but would there be any 
> other methods to avoid such an implementation issues?
> 
> Anyone else had similar experience?


___
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: Device implementation problems

2017-11-03 Thread J. Landman Gay via use-livecode

On 11/3/17 12:55 AM, Pyyhtiä Christer via use-livecode wrote:

When I issue the "go" and let the script run, many of the objects won't get done completely, for example card 
background, button or field colouring gets only partially done.  However, if I either add "lock screen" before the 
"go" statement, or issue "wait 100 milliSeconds" after the "go", everything is OK.


It almost sounds like LC has finished issuing all the commands to redraw 
the screen but the graphics card or the CPU on the device is slow to 
respond. So LC thinks it is finished and moves on to the next line of 
the script while the hardware is still catching up.


I'm not even sure that's possible but that's what it sounds like.

--
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: Device implementation problems

2017-11-03 Thread Bob Sneidar via use-livecode
I've seen this happen when something goes wrong in the code and in a standalone 
that can fail silently. If it does, the engine exits to top and that is why 
things get left undone. 

Bob S


> On Nov 2, 2017, at 22:55 , Pyyhtiä Christer via use-livecode 
>  wrote:
> 
> A few days ago I raised the question on how the device behaviour differs from 
> how it is in the IDE environment.  The question posed was if there is a 
> command
> 
>   go card "xyz"
> 
> and the script continues to run immediately, would there be interference in 
> terms of "getting the go done".
> 
> Interpreting a couple of answers, thank you, I understood that it would not 
> cause problems.
> 
> However, there can be interference, and I could prove it and repeat it.  As 
> follows.
> 
> - The target is Android device (I am using an old Samsung Galaxy S4 
> thanks to its screen pixel size (and despite of having dropped it both on 
> concrete and in a lake quite a few times still does great job)
> 
> - In the app there is a virtual screen (card is larger then the # of 
> pixels on the physical screen), and there are about 100 objects on it.  The 
> card is resized based on the screenRect parameters in several sets of 
> different objects, the amount of code running through is maybe > 1000 lines 
> of LC.
> 
> - When I issue the "go" and let the script run, many of the objects won't 
> get done completely, for example card background, button or field colouring 
> gets only partially done.  However, if I either add "lock screen" before the 
> "go" statement, or issue "wait 100 milliSeconds" after the "go", everything 
> is OK.  And all of this can be repeated.  The Android device is kept off 
> other duties, so that it is not getting vast amount of interruts.
> 
> Now, the above method helps me to solve the problem, but would there be any 
> other methods to avoid such an implementation issues?
> 
> Anyone else had similar experience?
> 
> rgds
> 
> Christer Pyyhtiä
> chris...@mindcrea.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