Re: valueDiff for arrays?

2018-08-04 Thread Monte Goulding via use-livecode


> On 5 Aug 2018, at 11:59 am, Monte Goulding via use-livecode 
>  wrote:
> 
> Just to throw it out there I still want to add `each` to filter one day. So 
> in this case I think it would be:
> 
> filter keys of tArray1 with expression \
>  each is among the keys of tArray2 and \
>  tArray1[each] is not tArray2[each]


Given I have been wanting to do ^ for a couple of years I decided to just go 
ahead and do it… might be a while before we have time to bikeshed the syntax 
though.

https://github.com/livecode/livecode/pull/6626 


Examples:
local tFoo,tBar
put "foo" into tFoo[1]
put "bar" into tFoo[2]
put "baz" into tBar[1]
put "bar" into tBar[2]
filter keys of tFoo with expression tFoo[each] is tBar[each]
— tFoo now has one key 2 which is `bar`

put “yes,foo” & return & “no,bar” into tFoo
filter lines of tFoo with expression item 1 of each is “yes”

We could feasibly not use `with|without` for this forcing the expression to 
return true to filter. If we went that way then perhaps `where` would be nicest?

filter lines of tFoo where item 1 of each is “yes”

Cheers

Monte

___
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: valueDiff for arrays?

2018-08-04 Thread Brian Milby via use-livecode
I have not been able to locate the earlier conversation on pass by
reference vice value.  I did a quick test and it took 100,000 loops to be
able to get a difference that was obvious.  My test was to construct simple
functions that took 1 to 3 parameters.  3 functions used all pass by value,
3 functions used all pass by reference.  Code inside the function added 1
to each parameter and returned the first.  The pass by reference function
was consistently around 40ms faster than the matching value function.
Making the functions private made them slightly faster but the delta was
about the same.  All of the values in this test were numeric.  Those
differences seem smaller that I recall, so I will do some additional test
with arrays and strings.
___
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: valueDiff for arrays?

2018-08-04 Thread Mark Wieder via use-livecode

On 08/04/2018 12:20 PM, J. Landman Gay via use-livecode wrote:

On 8/4/18 12:41 PM, Mark Waddingham via use-livecode wrote:

Can you immediately see the error?


Who, me? LOL. Well, I did find the line that was different. Brian and 
others who can read this stuff did better. But I did get the gist of 
your post and feel sufficiently smug now.


Careful with that. Smugness is the main way those things get messed up 
in the first place.


--
 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


Re: datagrid scrolling question

2018-08-04 Thread J. Landman Gay via use-livecode
I was thinking the same thing. I think the critical distinction is that 
datagrids are primarily display mechanisms, not really intended to be read 
directly. It's much easier to parse the original input data than to try to 
traverse the grid itself, which uses some tricks to appear as a continuous 
single control.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On August 4, 2018 6:54:21 PM James At The Hale via use-livecode 
 wrote:



I am a little lost here as to why this is a DG question as such.
Certainly being able to dynamically fill data within a row is a great UI 
feature when the user is directly interacting with a row.
But it seems you wish to completely fill particular values in all the rows 
from outside the DG.
In this case, why not operate directly on the DGdata, loop through the 
array, fill in all the required values and then send the whole array back 
to the DG?


___
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: valueDiff for arrays?

2018-08-04 Thread Mark Wieder via use-livecode

On 08/04/2018 07:11 PM, Brian Milby via use-livecode wrote:

I think Mark's code had a typo (left returned too many keys), but even when
corrected it takes half the time as a pure LCS solution.  Here's my
modification:


Quite right. Good catch.

--
 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


Re: valueDiff for arrays?

2018-08-04 Thread Brian Milby via use-livecode
I think Mark's code had a typo (left returned too many keys), but even when
corrected it takes half the time as a pure LCS solution.  Here's my
modification:

function bwmValueDiff pLeft, pRight
   local tResult
   intersect pLeft with pRight into tResult["1"]
   repeat for each key tKey in tResult["1"]
  if pLeft[tKey] is pRight[tKey] then
 delete variable tResult["1"][tKey]
  end if
   end repeat
   intersect pRight with tResult["1"] into tResult["2"]
   return tResult
end bwmValueDiff


On Sat, Aug 4, 2018 at 9:01 PM, Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 08/04/2018 04:45 PM, Mark Waddingham via use-livecode wrote:
>
> The other place this could come to bear is making the S/B (or some variant
>> there-of) not only work to produce an application, but also a
>> 'component/extension' - i.e. a distributable 'compiled' (in some sense)
>> form of a collection of script only stacks which were much more easily
>> distributable.
>>
>
> Hmmm... a 'bundle' of script-only stacks as a text file, especially if I
> could attach it as a substack is very appealing. This is certainly a need
> for stacks I distribute as stacks... for example, you can't use revOnline
> for script-only stacks or for LCB code.
>
> Hehe - well it is a working day for me today, and tomorrow and the next
>> week - I'm currently in Dallas, Texas, for FileMaker DevCon.
>>
>
> My condolences 
>
> --
>  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


Re: valueDiff for arrays?

2018-08-04 Thread Mark Wieder via use-livecode

On 08/04/2018 04:45 PM, Mark Waddingham via use-livecode wrote:

The other place this could come to bear is making the S/B (or some 
variant there-of) not only work to produce an application, but also a 
'component/extension' - i.e. a distributable 'compiled' (in some sense) 
form of a collection of script only stacks which were much more easily 
distributable.


Hmmm... a 'bundle' of script-only stacks as a text file, especially if I 
could attach it as a substack is very appealing. This is certainly a 
need for stacks I distribute as stacks... for example, you can't use 
revOnline for script-only stacks or for LCB code.


Hehe - well it is a working day for me today, and tomorrow and the next 
week - I'm currently in Dallas, Texas, for FileMaker DevCon.


My condolences 

--
 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


Re: valueDiff for arrays?

2018-08-04 Thread Monte Goulding via use-livecode
Just to throw it out there I still want to add `each` to filter one day. So in 
this case I think it would be:

filter keys of tArray1 with expression \
  each is among the keys of tArray2 and \
  tArray1[each] is not tArray2[each]

> On 5 Aug 2018, at 11:23 am, Brian Milby via use-livecode 
>  wrote:
> 
> Here is code that only uses LCS to accomplish the goal (only returning the
> keys where they exist in both arrays but the values are different).  This
> is made to be similar to the way the existing functions work (with the
> option to mutate).
> 
> command valueDiff @pDestinationA, @pLeftA, pRightA
>   local tMutate, tLeft, tRight, tNewRight
>   if the paramCount is 3 then
>  put false into tMutate
>  put pLeftA into tLeft
>  put pRightA into tRight
>   else
>  put true into tMutate
>  put pDestinationA into tLeft
>  put pLeftA into tRight
>   end if
>   repeat for each key tKey in tLeft
>  if tKey is among the keys of tRight and \
>tLeft[tKey] is not tRight[tKey] then
> put tRight[tKey] into tNewRight[tKey]
> next repeat
>  end if
>  delete variable tLeft[tKey]
>   end repeat
>   if tMutate then
>  put tLeft into pDestinationA
>  put tNewRight into pLeftA
>   else
>  put tLeft into pDestinationA["1"]
>  put tNewRight into pDestinationA["2"]
>   end if
> end valueDiff
> 
> My question from an engine perspective is whether it would be faster to
> just generate both arrays instead of removing keys from tLeft.  I decided
> to build the tNewRight to avoid iterating the keys of tRight.
> 
> I'd be pretty confident that Mark's solution will be faster, even with 3
> iterations over the keys.
> 
> On Sat, Aug 4, 2018 at 6:52 PM, Mark Waddingham via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> On 2018-08-04 21:00, Richard Gaskin via use-livecode wrote:
>> 
>>> Mark Waddingham wrote:
>>> 
>>> Yes - so come up with LCS handlers which do that, share them, let's
 work together to make them as efficient in LCS as possible and then
 see what we can do in the engine to improve their performance (which
 I'm guessing is as much the purpose for the proposition as the
 syntax).
 
>>> 
>>> It is, primarily.  The minor convenience is nice too, but you know how
>>> much I love to see performance enhancements in the engine.
>>> 
>>> As for implementation, Mark Wieder's looks good:
>>> http://lists.runrev.com/pipermail/use-livecode/2018-August/248862.html
>>> 
>> 
>> One important point here (which I think is something which is often
>> overlooked in LC as it is just something we deal with implicitly case by
>> case)...
>> 
>> In your use-case for 'valueDiff' - do you need to tell the difference
>> between a key value being the empty string and a key value not being
>> present at all?
>> 
>> [ i.e. using an array key absence to emulate 'nothing': meaning you are
>> actually storing nothing or a value (even the empty string). ]
>> 
>> It might seem like a minor detail, but does change the operation somewhat
>> (and potential implementations).
>> 
>> Warmest Regards,
>> 
>> Mark.
>> 
>> --
>> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
>> LiveCode: Everyone can create apps
>> 
>> ___
>> 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: valueDiff for arrays?

2018-08-04 Thread Brian Milby via use-livecode
Here is code that only uses LCS to accomplish the goal (only returning the
keys where they exist in both arrays but the values are different).  This
is made to be similar to the way the existing functions work (with the
option to mutate).

command valueDiff @pDestinationA, @pLeftA, pRightA
   local tMutate, tLeft, tRight, tNewRight
   if the paramCount is 3 then
  put false into tMutate
  put pLeftA into tLeft
  put pRightA into tRight
   else
  put true into tMutate
  put pDestinationA into tLeft
  put pLeftA into tRight
   end if
   repeat for each key tKey in tLeft
  if tKey is among the keys of tRight and \
tLeft[tKey] is not tRight[tKey] then
 put tRight[tKey] into tNewRight[tKey]
 next repeat
  end if
  delete variable tLeft[tKey]
   end repeat
   if tMutate then
  put tLeft into pDestinationA
  put tNewRight into pLeftA
   else
  put tLeft into pDestinationA["1"]
  put tNewRight into pDestinationA["2"]
   end if
end valueDiff

My question from an engine perspective is whether it would be faster to
just generate both arrays instead of removing keys from tLeft.  I decided
to build the tNewRight to avoid iterating the keys of tRight.

I'd be pretty confident that Mark's solution will be faster, even with 3
iterations over the keys.

On Sat, Aug 4, 2018 at 6:52 PM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2018-08-04 21:00, Richard Gaskin via use-livecode wrote:
>
>> Mark Waddingham wrote:
>>
>> Yes - so come up with LCS handlers which do that, share them, let's
>>> work together to make them as efficient in LCS as possible and then
>>> see what we can do in the engine to improve their performance (which
>>> I'm guessing is as much the purpose for the proposition as the
>>> syntax).
>>>
>>
>> It is, primarily.  The minor convenience is nice too, but you know how
>> much I love to see performance enhancements in the engine.
>>
>> As for implementation, Mark Wieder's looks good:
>> http://lists.runrev.com/pipermail/use-livecode/2018-August/248862.html
>>
>
> One important point here (which I think is something which is often
> overlooked in LC as it is just something we deal with implicitly case by
> case)...
>
> In your use-case for 'valueDiff' - do you need to tell the difference
> between a key value being the empty string and a key value not being
> present at all?
>
> [ i.e. using an array key absence to emulate 'nothing': meaning you are
> actually storing nothing or a value (even the empty string). ]
>
> It might seem like a minor detail, but does change the operation somewhat
> (and potential implementations).
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> ___
> 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: valueDiff for arrays?

2018-08-04 Thread Mark Waddingham via use-livecode

On 2018-08-04 21:00, Richard Gaskin via use-livecode wrote:

Mark Waddingham wrote:


Yes - so come up with LCS handlers which do that, share them, let's
work together to make them as efficient in LCS as possible and then
see what we can do in the engine to improve their performance (which
I'm guessing is as much the purpose for the proposition as the
syntax).


It is, primarily.  The minor convenience is nice too, but you know how
much I love to see performance enhancements in the engine.

As for implementation, Mark Wieder's looks good:
http://lists.runrev.com/pipermail/use-livecode/2018-August/248862.html


One important point here (which I think is something which is often 
overlooked in LC as it is just something we deal with implicitly case by 
case)...


In your use-case for 'valueDiff' - do you need to tell the difference 
between a key value being the empty string and a key value not being 
present at all?


[ i.e. using an array key absence to emulate 'nothing': meaning you are 
actually storing nothing or a value (even the empty string). ]


It might seem like a minor detail, but does change the operation 
somewhat (and potential implementations).


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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: datagrid scrolling question

2018-08-04 Thread James At The Hale via use-livecode
I am a little lost here as to why this is a DG question as such.
Certainly being able to dynamically fill data within a row is a great UI 
feature when the user is directly interacting with a row.
But it seems you wish to completely fill particular values in all the rows from 
outside the DG.
In this case, why not operate directly on the DGdata, loop through the array, 
fill in all the required values and then send the whole array back to the DG?

___
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: valueDiff for arrays?

2018-08-04 Thread Brian Milby via use-livecode
On Sat, Aug 4, 2018 at 6:14 PM, Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 08/04/2018 11:55 AM, Mark Waddingham via use-livecode wrote:
>
> Remember that this isn't a unique problem to LiveCode - script only stacks
>> (particularly how we've grown to use them) are akin to C source files /
>> projects (mainly because that is abstractly what they are /
>>
>
> I do realize that. But now that we've opened that can of worms I don't
> think we can just go on ignoring it. And the difference between LC
> script-only stacks and C source files is that you don't get to distribute a
> single compiled object in LC... you end up with a mainstack and several
> text files to distribute, and they need to stay together and in the same
> relative position. It's messy.


I don't think it has to be this way.  It would not be that difficult to
script the integration of all included behaviors into buttons of a resource
substack or even as substacks.  I actually envision something along these
lines for my Script Tracker as a way to include external library code in a
single file stack yet still have it be managed outside of the stack (my
code would sync the actual library code with a button that the stack would
use as the library or behavior). One advantage is that name resolution of
the behaviors would then be automatic.

One thing I'd like, since you're asking (place this in the 'watch what you
> ask for' category) is to be able to use script-only stacks as substacks.
>

Script Tracker could allow something like this now.  The substacks would
not be script only, but the exported script would look just like one.

And I've looked at how Trevor is having Sublime Text notify LiveCode that a
stack has been saved and believe that the same sort of thing is possible
with Atom.  Also, the code he uses to update a script only stack inside the
IDE could also be used in a folder watch script to do the same thing
without running a server process.  I'm sure that at a certain point the
number of files/folders watched would make it better to use his approach.

And I'm still looking for the code examples checking parameters.  I must
have deleted my stack since I don't see it.

Brian
___
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: valueDiff for arrays?

2018-08-04 Thread Mark Waddingham via use-livecode

On 2018-08-05 01:14, Mark Wieder via use-livecode wrote:

I do realize that. But now that we've opened that can of worms I don't
think we can just go on ignoring it. And the difference between LC
script-only stacks and C source files is that you don't get to
distribute a single compiled object in LC... you end up with a
mainstack and several text files to distribute, and they need to stay
together and in the same relative position. It's messy.


Yes - however, as @Brian already pointed out in another message which 
distracted me in terms of a technical point of performance rather than 
the more important' high-level point he made...


Perhaps 'Show IDE Stacks in lists' (or whatever it is called) has 
become far far too blunt an instrument...


What I was thinking.
For example, the PB could offer a new 'top-level' - which is project. 
A project being defined by a set of stacks which share a common name 
prefix...


Well, when the PB was first proposed, that's where I thought this was 
heading.


Yes - 'projects' are a concept which LiveCode needs - although like lots 
of things its a case of 'when' rather than 'if' (even if the 'when' has 
been and still is measured in rather long timecales!).



One thing I'd like, since you're asking (place this in the 'watch what
you ask for' category) is to be able to use script-only stacks as
substacks. That way I could edit them with a text editor and still
work with only a single unified object. And the PB would hide the
component stacks within the mainstack until I chose to examine them,
the same way that substacks now work. Obviously there are script-only
stacks that would not need to be substacks, but that's no different
from the way stacks and substacks work now.


I think modifications to the PB and a stricter naming convention for 
stacks could solve most of the problems which do exist here.


After all it doesn't matter if (in memory) all stacks are in a 'flat' 
list (its up to the engine to optimize lookup) really - what matter is 
the view of them which is presented in the IDE - which is almost purely 
a PB concern.


The other side of this, is what Brian hinted at - when building for 
distribution script-only stacks which are essentially 'children' of some 
component should be built into a single stack with substacks.


This is essentially what scriptification and descriptification do: we 
have code for this in the repository... For example, there is an 
embedded UI stack in the engine which deals with licensing (the one 
which really does anything is in the livecode-private - which you all 
never see as that's the commercial side of the code). The environment 
stack (whether public or private) exists as a collection of script-only 
stacks and a single binary stack which holds the UI in the github 
repository, and when building the engine those collection of files get 
turned into a single mainstack.


This could be done for all the IDE components which are composed in this 
way at the point we build the distribution - it would cut down the 
number of mainstacks considerably, and again perhaps mean 'show LiveCode 
UI elements' actually does the same as it did before things started to 
be scriptified.


The other place this could come to bear is making the S/B (or some 
variant there-of) not only work to produce an application, but also a 
'component/extension' - i.e. a distributable 'compiled' (in some sense) 
form of a collection of script only stacks which were much more easily 
distributable.


The only thing we would lose by using this kind of process on the IDE 
would be the easy ability to 'monkey-hack' the IDE - although not 
significantly - it would just be slightly harder to pull out the changes 
to submit as a PR if you wanted too...


However, that being said - we then just add a way you could just pull 
the IDE repository and have it use an engine from a pre-installed 
distribution.


Internally we tend to edit the IDE from engines built from the engine 
repository - there's various redirection logic in the IDE and engine, so 
that when a 'build-from-source' engine is run, it looks to see if it is 
a github checkout, and if so loads and runs the IDE from the IDE 
submodule checkout.


So upshot - in reality - we have most of the code and mechanisms already 
to at least get a long way to the ideal (which is a much more 
structured, built-in component architecture), it is 'just' a case of 
plumbing it in in some of the ways outlined above. Admittedly, not a 
small project, but certainly not one which would needed to be started 
from ground-zero.



And btw, thanks for your input on this list. On a Saturday even. Much
appreciated.


Hehe - well it is a working day for me today, and tomorrow and the next 
week - I'm currently in Dallas, Texas, for FileMaker DevCon.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___

Re: Move command on iOS

2018-08-04 Thread J. Landman Gay via use-livecode
I did leave the group set to dynamic, actually. When I'm done tinkering 
with rotation adjustments I'll see if that helps. Thanks.


On 8/4/18 4:06 PM, Randy Hengst via use-livecode wrote:

Did you leave the controls on dynamic? I found leaving them at static helped.

be well,
randy
www.classroomFocusedSoftware.com


On Aug 4, 2018, at 3:00 PM, J. Landman Gay via use-livecode 
 wrote:

I did tinker with accleratedRendering when the problem first appeared. I turned 
it off before the move command and back on afterward, but it didn't help. I 
also changed the time so that the move was slower, but that didn't work either.

Panos seems to have identified the reason for the failure in my case, though I'm not 
sure it is applicable everywhere. It's posted in the bug report 
. Would this situation 
apply to your stack(s)?

I don't quite know why my stack ran okay on Monte's phone, and my stripped-down 
test with the same code ran okay in the simulator, but my real stack failed. 
Weird.


On 8/4/18 8:07 AM, Randy Hengst via use-livecode wrote:
Sorry I’m a bit late to this strand, but yes, I’ve seen what you’re describing 
Jacque. I’ve seen it in the simulator and when loaded on the iPad.
Have you tried turning off acceleratedRendering and setting to static? As I 
shared earlier with the list, the problem I’m seeing includes slowdowns of the 
movements.
I’ve read on in the strand… and I’m using move to …. without waiting. The move 
for me always includes two buttons… sometimes five depending on the context of 
the call.
I was also seeing some issues with the acceleratedRendering/dynamic in the IDE.
be well,
randy
www.classroomFocusedSoftware.com

On Aug 3, 2018, at 4:53 PM, J. Landman Gay via use-livecode 
 wrote:

Anyone else having trouble with the move command on iOS? I'm sliding a group 
into view, which works the first time, and after that it starts to move and 
then immediately jumps to its destination without any animation. It works fine 
in the IDE.

AccleratedRendering is true and the group layermode is "dynamic". I don't have 
an actual phone to try it on, so maybe this is a simulator problem?

--
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

___
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



--
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

___
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




--
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: Move command on iOS

2018-08-04 Thread J. Landman Gay via use-livecode

On 8/4/18 5:11 PM, Monte Goulding via use-livecode wrote:

So I guess ensuring it is positioned correctly for the device before the first 
move and the hide move hides the whole thing would be a good place to start.


I saw that, just fixed it today. This stack was made 6 years ago before 
we had fullscreenMode and rather than re-doing all the layouts to 
accomodate, I'm manually placing everything (my god I wish we'd had that 
earlier, half the scripts deal with placement, text size and height, and 
rotation.) I missed that one.


But the fact that in spite of the initial bad placement the group still 
animated correctly makes me wonder what's different.


--
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: datagrid scrolling question

2018-08-04 Thread Brian Milby via use-livecode
My question is why use the button? Loop through the data in the grid and make 
the tsnet call manually for each line. If the button is calling a script 
outside of the DG, then you can use the same call. Then you don’t have to do 
any of those things to figure out the name of the row group.
On Aug 4, 2018, 5:39 PM -0500, Douglas Ruisaard via use-livecode 
, wrote:
> I sent a badly constructed message with this content (more or less) a few 
> days ago. I am re-posting it in the hope that anyone who tried to decipher 
> those two messages will give this another consideration.
>
> So pardon the repeat, but I'm quite sure someone from this group can lend me 
> a hand on this issue.
>
> Using LC v8.1.9 on Windows 7 pro
>
> Using a datagrid form, each row has 1 checkbox, 3 fields and 2 buttons.
>
> One of the buttons (the one I need assistance with), named "Query" calls the 
> "tsnet" library to query a remote WiFi module (esp8266) which returns the 
> status of one of its IO pins. Works like a charm on ALL rows, scrolled or 
> not... because (I reckon) the button is actually *IN* the grid, so there's no 
> issue with the group name (as will become clear in a moment).. it is always 
> "me".
>
> I also want to "automate" the queries (there are 8 such wifi modules 
> involved). So I have a button outside of the datagrid which selects each row 
> of the populated datagrid in a "repeat" statement and sends a "mouseUp" 
> message to the datagrid.
>
> What I discovered is that (apparently) I have to "manufacture" the group name 
> of each row to which I want to send the "mouseUp" message. So as I progress 
> through the populated rows of the grid the "pseudo" group name of each row 
> basically becomes the row number along with a prefix of "Row Template"... 
> i.e. row 1's group name/label is "Row Template 0001", row 2 is "Row Template 
> 0002", etc.
>
> Great... but once the grid starts to scroll, strange things start to happen. 
> The pseudo-group name will "wrap"... and where it wraps depends on the number 
> of rows which are initially visible on the grid.
>
> For example, if there are 8 populated rows and the DataGrid is sized to only 
> show 3 rows at a time, upon the initialization of the Datagrid, the "pseudo" 
> Row templates groups are named:
>
> row 1: "Row Template 0001"
> row 2: "Row Template 0002"
> row 3: "Row Template 0003"
> row 4: "Row Template 0004"
> row 5: "Row Template 0005"
> row 6: "Row Template 0001"
> row 7: "Row Template 0002"
> row 8: "Row Template 0003"
>
> this is demonstrated by putting a "put me" in the Behavior Script within the 
> MouseUp handler to which I am sending the "mouseUp" message in order to 
> "process" that row's content... i.e.
>
> on mouseUp
> put me
> ...do something
> end mouseUp
>
> What is interesting (and confusing at the same time), if I use a specific 
> "wrapping pattern" (such as the one described above) and mutually "wrap" the 
> name of the group to which I am about to send the "mouseUp" message, it 
> works! ... i.e. from within the button outside of the datagrid:
> ... (in this example, the serverList array holds the 8 wifi module names I 
> need to query with tsnet)
>
> put "" into pad
> put 0 into q
> repeat with y = 1 to (the number of lines in the keys of serverList)
> set the dgHilitedLines of group "DataGrid 1" to y
> add 1 to q
> if q > 5 then put 1 into q
> put char 1 to (4 - length(q)) of pad & q into z
> put char 1 to (4 - length(y)) of pad & y into z
> put "Row Template " & z into z
> send "mouseUp" to button "Query" of group z
> end repeat
>
> THIS is confusing because, although I am sending the same message to what 
> appears to be the same pseudo-group name, once the grid scrolls beyond row 5, 
> LC manages to know that I am actually referencing another grid row than the 
> one(s) with the same pseudo-group names.
>
> To scroll the grid, programatically, I used:
> set the dgHilitedLines of group "DataGrid 1" to y
> to accomplish this.
>
> I also tried the more "seemingly appropriate":
> dispatch "ScrollLineIntoView" to group "DataGrid 1" with pLine"
>
> but this command changes the highlight of one of my fields which I have 
> customized to have red text in case of an error. Regardless, using either 
> method for scrolling does NOT seem to have any effect on the wrapping of the 
> pseudo group name.
>
> Since this "wrap-point" changes based on the "amount" of the datagrid I 
> "expose", this doesn't lend itself to portable or supportable code.
>
> If I don't "wrap" my group names according to this sort of pattern, once my 
> code reaches the 6th line (in my example), I get a:
> " ... Chunk: can't find background), char 1 " error ... because "Row Template 
> 0006" does not exist... it is "Row Template 0001"
>
> No doubt I'm approaching this wrong but I'm trying to teach myself datagrids 
> and it's a struggle for this old brain!
> Is there another method for sending a "mouseUp" to a button on a datagrid 
> form row?
>
> Douglas Ruisaard
> 

Re: valueDiff for arrays?

2018-08-04 Thread Mark Wieder via use-livecode

On 08/04/2018 11:55 AM, Mark Waddingham via use-livecode wrote:

Remember that this isn't a unique problem to LiveCode - script only 
stacks (particularly how we've grown to use them) are akin to C source 
files / projects (mainly because that is abstractly what they are /


I do realize that. But now that we've opened that can of worms I don't 
think we can just go on ignoring it. And the difference between LC 
script-only stacks and C source files is that you don't get to 
distribute a single compiled object in LC... you end up with a mainstack 
and several text files to distribute, and they need to stay together and 
in the same relative position. It's messy.


Perhaps 'Show IDE Stacks in lists' (or whatever it is called) has become 
far far too blunt an instrument...


What I was thinking.

For example, the PB could offer a new 'top-level' - which is project. A 
project being defined by a set of stacks which share a common name 
prefix...


Well, when the PB was first proposed, that's where I thought this was 
heading.


One thing I'd like, since you're asking (place this in the 'watch what 
you ask for' category) is to be able to use script-only stacks as 
substacks. That way I could edit them with a text editor and still work 
with only a single unified object. And the PB would hide the component 
stacks within the mainstack until I chose to examine them, the same way 
that substacks now work. Obviously there are script-only stacks that 
would not need to be substacks, but that's no different from the way 
stacks and substacks work now.


And btw, thanks for your input on this list. On a Saturday even. Much 
appreciated.


--
 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


Re: Getting Started with DataGrid and another datagrid form

2018-08-04 Thread Douglas Ruisaard via use-livecode


The more you understand a task, the more versatile and appropriate any given 
tool becomes.

I think the biggest struggle for me is finding examples which are "close" to my 
own goal.  I have no problem reverse engineering code... I've done it for a 
very long time.  But unless the outcome closely approximates my need, such an 
exercise can be frustrating.  In addition LC (which I very much like) has its 
own quirks regarding datagrids which are VERY confusing to the datagrid 
newbie... see my most recent issue with scrolling, for example.

To provide a more effective and cumulative wishlist of suggestions, 
expectations and content, I really need to go back and (re-)employ your tool 
with my (now) somewhat fuller understanding of how to define and manipulate 
datagrids.

I will do so in the near future and get back to you.  I suspect that one just 
has to have a certain amount of base-level understanding of the datagrid 
components and behaviours in order to use datagrids.  It's the old boot-strap 
problem.



> Subject: Re: Getting Started with DataGrid and another datagrid form
>   question
> 
> Dear Douglas,
> 
> Thanks for your interesting feedback about your attempt to use DGH for the
> first time, with creating a datagrid form.
> 
> All the properties for customizing the datagrid apart, I've created the
> form template area (the way to custom the content of a row with controls
> such as image, buttons, etc) with the following objectives:
> - in the standard way to customize a datagrid template, we have to open the
> row template group inside the template card. In DGH all this group is
> copied inside a "visual" area we can manipulate
> - when dropping some controls in the template area, with the datagrid, you
> are alone with the required script for managing all these controls. DGH, at
> the condition to respond to the right dialog, is building a minimal script
> depending of the kind of controls you added. Unfortunately this is
> difficult to cover all the needs, because they are all specific depending
> of the developer and what he want to do. But at least the goal of the
> installed script is to give you the keys and philosophy to understand what
> it is required for the controls.For a button, how to perform an action, for
> a checkbox, how to check or uncheck it, for an image how to display it, to
> click it, etc
> - one of the recurrent difficulties for users was to understand the
> datagrid rows remains empty until you have populate it. And because it is
> empty you will never see the beautiful button or image you have added if
> you have not at least a row data. This is why in DGH, upper the template
> area, we have a datagrid preview, to see immediately the control we have
> added.
> 
> Your comment make me realize that it is not enough when you are beginning
> with form template. One of my unexploited idea was to add kind of presets
> template with for example a text on the left and four checkboxes on the
> right, etc so the developper could start with ready to use templates to add
> to his datagrid. The problem of the approach is covering needs, I can't
> anticipate.
> 
> What might have you expected from DGH in this task? More tutorial
> explaining how the template area is working?, more lessons?, contextual
> help in DGH to help you to start? Something else? Feel free to expand, I'm
> always interested in approachs or ways I could try to implement in the goal
> to improve DGH.
> 
>

Douglas Ruisaard
Trilogy Software
(250) 573-3935




___
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: LCB - Text entry/edit in a widget

2018-08-04 Thread Monte Goulding via use-livecode
There is still some work needed to be done in order for widgets to get keyboard 
focus and handle key events. A much simpler and available alternative though is 
to create and delete a field on top of the widget as required.

> On 5 Aug 2018, at 2:08 am, pink via use-livecode 
>  wrote:
> 
> What I would like to make is a widget that essentially functions as a multi
> field form. 
> 
> I know how to add text to a widget, but how can I make editable by the user?
> 
> Essentially, how can I create one or more "fields" in a widget?
> 
> 
> 
> -
> ---
> Greg (pink) Miller
> mad, pink and dangerous to code
> --
> Sent from: 
> http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html
> 
> ___
> 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


datagrid scrolling question

2018-08-04 Thread Douglas Ruisaard via use-livecode
I sent a badly constructed message with this content (more or less) a few days 
ago.  I am re-posting it in the hope that anyone who tried to decipher those 
two messages will give this another consideration.

So pardon the repeat, but I'm quite sure someone from this group can lend me a 
hand on this issue.

Using LC v8.1.9 on Windows 7 pro

Using a datagrid form, each row has 1 checkbox, 3 fields and 2 buttons.

One of the buttons (the one I need assistance with), named "Query" calls the 
"tsnet" library to query a remote WiFi module (esp8266) which returns the 
status of one of its IO pins.  Works like a charm on ALL rows, scrolled or 
not... because (I reckon) the button is actually *IN* the grid, so there's no 
issue with the group name (as will become clear in a moment).. it is always 
"me".

I also want to "automate" the queries (there are 8 such wifi modules involved). 
 So I have a button outside of the datagrid which selects each row of the 
populated datagrid in a "repeat" statement and sends a "mouseUp" message to the 
datagrid.

What I discovered is that (apparently) I have to "manufacture" the group name 
of each row to which I want to send the "mouseUp" message.  So as I progress 
through the populated rows of the grid the "pseudo" group name of each row 
basically becomes the row number along with a prefix of "Row Template"... i.e. 
row 1's group name/label is "Row Template 0001", row 2 is "Row Template 0002", 
etc.

Great... but once the grid starts to scroll, strange things start to happen.  
The pseudo-group name will "wrap"... and where it wraps depends on the number 
of rows which are initially visible on the grid.

For example, if there are 8 populated rows and the DataGrid is sized to only 
show 3 rows at a time, upon the initialization of the Datagrid, the "pseudo" 
Row templates groups are named:

row 1:  "Row Template 0001" 
row 2:  "Row Template 0002"
row 3:  "Row Template 0003"
row 4:  "Row Template 0004"
row 5:  "Row Template 0005"
row 6:  "Row Template 0001"
row 7:  "Row Template 0002"
row 8:  "Row Template 0003"

this is demonstrated by putting a "put me" in the Behavior Script within the 
MouseUp handler to which I am sending the "mouseUp" message in order to 
"process" that row's content... i.e.

on mouseUp
put me
...do something
end mouseUp

What is interesting (and confusing at the same time), if I use a specific 
"wrapping pattern" (such as the one described above) and mutually "wrap" the 
name of the group to which I am about to send the "mouseUp" message, it works!  
... i.e. from within the button outside of the datagrid:
... (in this example, the serverList array holds the 8 wifi module names I need 
to query with tsnet)

put "" into pad
put 0 into q
repeat with y = 1 to (the number of lines in the keys of serverList)
   set the dgHilitedLines of group "DataGrid 1" to y
   add 1 to q
   if q > 5 then put 1 into q
   put char 1 to (4 - length(q)) of pad & q into z
   put char 1 to (4 - length(y)) of pad & y into z
   put "Row Template " & z into z
   send "mouseUp" to button "Query" of group z
end repeat

THIS is confusing because, although I am sending the same message to what 
appears to be the same pseudo-group name, once the grid scrolls beyond row 5, 
LC manages to know that I am actually referencing another grid row than the 
one(s) with the same pseudo-group names.

To scroll the grid, programatically, I used:
   set the dgHilitedLines of group "DataGrid 1" to y  
to accomplish this.

I also tried the more "seemingly appropriate":
   dispatch "ScrollLineIntoView" to group "DataGrid 1" with pLine" 

but this command changes the highlight of one of my fields which I have 
customized to have red text in case of an error.  Regardless, using either 
method for scrolling does NOT seem to have any effect on the wrapping of the 
pseudo group name.

Since this "wrap-point" changes based on the "amount" of the datagrid I 
"expose", this doesn't lend itself to portable or supportable code.

If I don't "wrap" my group names according to this sort of pattern, once my 
code reaches the 6th line (in my example), I get a:
" ... Chunk: can't find background), char 1 " error ... because "Row Template 
0006" does not exist... it is "Row Template 0001"

No doubt I'm approaching this wrong but I'm trying to teach myself datagrids 
and it's a struggle for this old brain!
Is there another method for sending a "mouseUp" to a button on a datagrid form 
row?

Douglas Ruisaard
Trilogy Software
(250) 573-3935



Douglas Ruisaard
Trilogy Software
(250) 573-3935




___
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: Move command on iOS

2018-08-04 Thread Monte Goulding via use-livecode



> On 5 Aug 2018, at 5:00 am, J. Landman Gay via use-livecode 
>  wrote:
> 
> I don't quite know why my stack ran okay on Monte's phone, and my 
> stripped-down test with the same code ran okay in the simulator, but my real 
> stack failed. Weird.

When I said it worked ok here I should have probably been a bit more specific. 
It seemed to work as scripted. I tested on a mini. The first move the group 
came up on an angle from bottom left. Cancel would move it straight down about 
half way then hide it. Presenting it again moved it straight up. Cancel again 
moved it straight down and hid.

So I guess ensuring it is positioned correctly for the device before the first 
move and the hide move hides the whole thing would be a good place to start.

Cheers

Monte
___
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: Move command on iOS

2018-08-04 Thread Randy Hengst via use-livecode
Did you leave the controls on dynamic? I found leaving them at static helped. 

be well,
randy
www.classroomFocusedSoftware.com

> On Aug 4, 2018, at 3:00 PM, J. Landman Gay via use-livecode 
>  wrote:
> 
> I did tinker with accleratedRendering when the problem first appeared. I 
> turned it off before the move command and back on afterward, but it didn't 
> help. I also changed the time so that the move was slower, but that didn't 
> work either.
> 
> Panos seems to have identified the reason for the failure in my case, though 
> I'm not sure it is applicable everywhere. It's posted in the bug report 
> . Would this situation 
> apply to your stack(s)?
> 
> I don't quite know why my stack ran okay on Monte's phone, and my 
> stripped-down test with the same code ran okay in the simulator, but my real 
> stack failed. Weird.
> 
>> On 8/4/18 8:07 AM, Randy Hengst via use-livecode wrote:
>> Sorry I’m a bit late to this strand, but yes, I’ve seen what you’re 
>> describing Jacque. I’ve seen it in the simulator and when loaded on the iPad.
>> Have you tried turning off acceleratedRendering and setting to static? As I 
>> shared earlier with the list, the problem I’m seeing includes slowdowns of 
>> the movements.
>> I’ve read on in the strand… and I’m using move to …. without waiting. The 
>> move for me always includes two buttons… sometimes five depending on the 
>> context of the call.
>> I was also seeing some issues with the acceleratedRendering/dynamic in the 
>> IDE.
>> be well,
>> randy
>> www.classroomFocusedSoftware.com
>>> On Aug 3, 2018, at 4:53 PM, J. Landman Gay via use-livecode 
>>>  wrote:
>>> 
>>> Anyone else having trouble with the move command on iOS? I'm sliding a 
>>> group into view, which works the first time, and after that it starts to 
>>> move and then immediately jumps to its destination without any animation. 
>>> It works fine in the IDE.
>>> 
>>> AccleratedRendering is true and the group layermode is "dynamic". I don't 
>>> have an actual phone to try it on, so maybe this is a simulator problem?
>>> 
>>> -- 
>>> 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
>> ___
>> 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
> 
> 
> -- 
> 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
___
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: Data Persistence

2018-08-04 Thread J. Landman Gay via use-livecode

On 8/4/18 2:27 PM, John McKenzie via use-livecode wrote:

  Thank you to the additional people who welcomed me. I contrast this
with the time I asked a question on Usenet about a scripting language I
was learning and the first reply told me I was awful (true, which is
why I was asking questions) and to come back and only ask questions
when I have the script I posted working.


Well that's a Catch-22 now, isn't it. We like to think we're better than 
that. Please feel free to ask anything, even if you think it's stupid. 
We've all been there. And besides, any mocking on the list usually turns 
into a bad joke thread you'll be sorry you started. Conf.: "brains".



  Would having the app place something into the field put focus on the
field?

  What I am really wondering is when it comes to the buttons can I leave
them be because the text fields have code to save their info when the
focus leaves or should I add code to the buttons to tell them after
placing the info into the text field, save same info to an array?


Text-related field messages generally only trigger when a user 
physically types into a field. Script-inserted text does not generate 
those. You'll need to do a save after your handler changes the text, 
which isn't a problem because you know when the script does it.


--
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: Data Persistence

2018-08-04 Thread Mike Bonner via use-livecode
Putting text into a field pro-grammatically doesn't fire the openfield and
closefield handlers so yes, you'd need to add code to your button.  You can
either write the code directly, or you can use send (or dispatch) and have
the field do it.. IE send "closefield" to field "whateverfield"...   But if
it were me, I'd just add the code to the button itself.

Actually, I'd probably have the code once, in the card or stack script that
accepts parameters like the long id of the field, data to be saved and
whatever else so that you have a single handler that will work for all of
your saves.

Something like

on saveIt pLongId,pText
-- code to save pText and associate it with control pLongId
end saveIt

Then you can do..
on closefield
 saveit (the long id of me),(the text of me)
end closefield

Or in a button..
on mouseup
put "Whatever text" into field "myField"
saveit (the long id of field "myField"),the text of field "myField"
end mouseup

Just some thoughts.





On Sat, Aug 4, 2018 at 1:28 PM John McKenzie via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
>  A little less busy now so I can look at my app some more. As you mat
> recall I was asking about data persistence.
>
>  Thank you to the additional people who welcomed me. I contrast this
> with the time I asked a question on Usenet about a scripting language I
> was learning and the first reply told me I was awful (true, which is
> why I was asking questions) and to come back and only ask questions
> when I have the script I posted working.
>
>  As for contributing brains. Yeah... I supposed I could fake
> that part for awhile. Just do not ask for kidneys as you will get
> nowhere there.
>
>  Klaus thank you for mentioning closefield. Did not notice it before
> and it seems like it would be just the thing for me. The data is
> simple, so I think I will start out by trying to save it all in an
> array and doing so every time there is an entry or change to an entry
> using closefield.
>
>  And that brings me to today's follow up question. In some cases I have
> a button that when pressed put the time inside the neighbouring text
> field. So when a plane lands I pressed the button labelled "ATA" and it
> puts the current time into a text field next to the ATA button. How
> would that count as focus?
>
>  Would having the app place something into the field put focus on the
> field?
>
>  What I am really wondering is when it comes to the buttons can I leave
> them be because the text fields have code to save their info when the
> focus leaves or should I add code to the buttons to tell them after
> placing the info into the text field, save same info to an array?
>
>  Thanks.
>
>
> ___
> 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: valueDiff for arrays?

2018-08-04 Thread Mark Waddingham via use-livecode

On 2018-08-04 21:51, Mark Waddingham via use-livecode wrote:

one don't even realize - but find out pretty quickly about then their


That should be 'when they' - not then their.

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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: valueDiff for arrays?

2018-08-04 Thread Mark Waddingham via use-livecode

On 2018-08-04 21:20, J. Landman Gay via use-livecode wrote:

On 8/4/18 12:41 PM, Mark Waddingham via use-livecode wrote:

Can you immediately see the error?


Who, me? LOL. Well, I did find the line that was different. Brian and
others who can read this stuff did better. But I did get the gist of
your post and feel sufficiently smug now.


Well you can share your smugness with all Python, JavaScript, Java, C#, 
BASIC variants, and pretty much every other programmer who has chosen a 
high-level language (in terms of ones which takes away the need to think 
about memory management) as their main tool - at least in this regard. 
(Here by 'high-level' I mean one which abstracts away memory management 
and pointer manipulation entirely from your normal concerns).


However, I'd like to think that LiveCode actually sits in a slightly 
better class... It does not rely on a 'garbage collector' - all memory 
management is explicit - its just the engine does all the explicit work 
for you. It manages high-level safety without resorting to what is 
essentially a 'panic' solution to solving the problem (which actually 
has profound and rather unpleasant side-effects and edge cases in all 
kinds of ways most programmers who are used to relying on one don't even 
realize - but find out pretty quickly about then their fail 
catastrophically) ;)


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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: valueDiff for arrays?

2018-08-04 Thread Mark Waddingham via use-livecode

On 2018-08-04 21:00, Richard Gaskin via use-livecode wrote:

Mark Waddingham wrote:


Yes - so come up with LCS handlers which do that, share them, let's
work together to make them as efficient in LCS as possible and then
see what we can do in the engine to improve their performance (which
I'm guessing is as much the purpose for the proposition as the
syntax).


It is, primarily.  The minor convenience is nice too, but you know how
much I love to see performance enhancements in the engine.


:)

The important thing you have to remember is that you only get a 
performance advantage for hand-coding code like that in the engine *if* 
the overhead of dispatching script dominates the processing being done. 
That can actually be really hard to determine from inspection.


Especially if things require hash-key lookups (i.e. name creation) - 
then you might find you get a speed up for things involving small 
numbers of keys - but virtually none for large numbers of keys 
(particularly as the key size goes up).


So you then have to balance whether its 'worth it' from a C++ code 
maintenance point of view.


Certainly, I guess a metric could be 'how much is a particularly utility 
function used'. i.e. If a utility function gets into a common library, 
and we find that it is used 'all the time' across many different 
projects *then* it should probably be put on the list for being 
implemented in the engine (and deserve English-like syntax in the 
process!).




As for implementation, Mark Wieder's looks good:
http://lists.runrev.com/pipermail/use-livecode/2018-August/248862.html

Thinking about performance, I wonder if there's anything from some of
the changes that have boosted PHP 7's performance so far above its
earlier versions which may be relevant for LC:
https://www.reddit.com/r/PHP/comments/3q2brz/how_is_php_7_twice_as_fast/


I'd actually be really interested in a direct speed comparison between 
exactly equivalent operations in PHP7 and LC.


The reason is that (from my previous relatively terse, admittedly, 
review of PHP7's implementation details) LC actually does mostly the 
same things - and has done since 7. All of it related to the 
introduction of libfoundation (which I actually started designing, and 
started implemented about 7/8 years ago - long before it appeared in a 
release - although the seeds for it were planted long before - 
namification of handler names, and literals in the engine at version 5 
or 6 being a key precursor).


There is actually (and always has been) quite a long list of things 
which I've always wanted to do with libfoundation to improve its 
performance vastly - pleasingly many of those ideas are more than 
validated by PHP7 (as it actually does them!). However, most of them 
have a huge ripple effect on a substantial portion of the code - and 
that's a significant issue.


For example - MCNameRef which is a 'uniqued string' (IS_STR_INTERNED in 
PHP7 speak) used for all literals, handler names, array keys etc. is a 
separate value type to MCString. This was a design error (born of the 
previous rendering of MCNameRefs pre-7) with hindsight - it should have 
been a kind of MCString.


Similarly, integer array keys should be integers - and not rendered as 
strings at all unless needed.


These two things are relatively easy to do at the libfoundation level, 
but they require a significant API change - which I don't think can be 
made backwards compatible which means updating all uses. None the 
updating work is necessarily hard - but it needs to be done carefully 
and needs to be exceptionally well planned so it can be done rapidly and 
all in one go as it would be really difficult to maintain two separate 
branches whilst it was being done (honestly 7 was a complete nightmare 
from that point of view - I don't even want to think about the amount of 
man hours that went into just keeping the 6 and develop-7 branches in 
sync!!).


Other things (like storing short strings in the value memory block, 
rather than in a separate array) I think could be done without any 
changes to the libfoundation API.


I also experimented with (small) integers being 'tagged pointers' at one 
point - which would eliminate the overhead of most integer operations. 
However, as it turned out the idea on its own didn't really make a great 
deal of difference - what did make a difference was a value pool 
allocator - number values 'live fast and die young' which means that if 
you cache the most recently freed number value, and re-use that you 
eliminate their overhead. That same pattern worked exceptionally well 
for other values too (short strings, for example).


Of course, tagged integers would probably make a substantial difference 
if array keys didn't have to be names - the performance of even 
hash-table based sequences would be far faster.


Anyway, I could probably go on at length about this but will stop there.

As a point of comparison, the reason why PHP7 has these things and LC 
does 

Re: Data Persistence

2018-08-04 Thread John McKenzie via use-livecode


 A little less busy now so I can look at my app some more. As you mat
recall I was asking about data persistence.

 Thank you to the additional people who welcomed me. I contrast this
with the time I asked a question on Usenet about a scripting language I
was learning and the first reply told me I was awful (true, which is
why I was asking questions) and to come back and only ask questions
when I have the script I posted working.

 As for contributing brains. Yeah... I supposed I could fake
that part for awhile. Just do not ask for kidneys as you will get
nowhere there.

 Klaus thank you for mentioning closefield. Did not notice it before
and it seems like it would be just the thing for me. The data is
simple, so I think I will start out by trying to save it all in an
array and doing so every time there is an entry or change to an entry
using closefield.

 And that brings me to today's follow up question. In some cases I have
a button that when pressed put the time inside the neighbouring text
field. So when a plane lands I pressed the button labelled "ATA" and it
puts the current time into a text field next to the ATA button. How
would that count as focus?

 Would having the app place something into the field put focus on the
field?

 What I am really wondering is when it comes to the buttons can I leave
them be because the text fields have code to save their info when the
focus leaves or should I add code to the buttons to tell them after
placing the info into the text field, save same info to an array?

 Thanks.


___
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: valueDiff for arrays?

2018-08-04 Thread J. Landman Gay via use-livecode

On 8/4/18 12:41 PM, Mark Waddingham via use-livecode wrote:

Can you immediately see the error?


Who, me? LOL. Well, I did find the line that was different. Brian and 
others who can read this stuff did better. But I did get the gist of 
your post and feel sufficiently smug now.


--
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: valueDiff for arrays?

2018-08-04 Thread Mark Waddingham via use-livecode

On 2018-08-04 21:00, Brian Milby via use-livecode wrote:

Plugins should probably be de-scriptified for distribution for this
reason.  A similar argument could be made for some IDE library code 
too.  I
have to wonder if there is any performance impact to the number of 
stacks

the IDE has to deal with now that so much is scriptified.  (The list of
stacks is a linked list and finding a stack by name goes through the 
list

at least in one spot.).  I've been thinking of how to test this sort of
thing to measure it


Indeed that would be interesting - I think @Monte proposed a patch to 
make stack-by-filename lookups hash-table based recently (it was attempt 
to fix an unrelated thing which was more important - and I'm not sure 
the speed improvement necessarily justified the extra code complexity - 
until we can abstract the whole caching things logic to a common 
pattern). Certainly making the stack list hash-by-name (like control 
id's per stack) would probably help. Although there are a few salient 
details which make them quite a bit more complex than the id case - e.g. 
substacks can have the same name as a mainstack.



It would be similar to how copy-on-write does incur a small amount of
overhead when compared to pass-by-reference that was demonstrated in an
earlier discussion.  The result there was that if you need to optimize 
for

speed, reference is still helpful.  If you are purely concerned about
memory usage, then it isn't needed.


Again - interesting - can you pull out that exact case, it is a little 
surprising (which makes me wonder whether there are some specific 
details it which are actually exceptionally important). For example:


on foo @xValue
  return xValue[5]
end foo

on bar pValue
  return pValue[5]
end bar

on testFoo pArray
  put "baz" into pArray[1][2][3][4]
  repeat 1 times
foo pArray[1][2][3][4]
  end repeat
end testFoo

on testBar pArray
  put "baz" into pArray[1][2][3][4]
  repeat 1 times
bar pArray[1][2][3][4]
  end repeat
end testBar

You should find that whilst these two things do exactly the same thing 
that testFoo will be a lot slower than testBar.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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: valueDiff for arrays?

2018-08-04 Thread Mark Waddingham via use-livecode

On 2018-08-04 20:37, Mark Wieder via use-livecode wrote:

On 08/04/2018 11:19 AM, Mark Waddingham via use-livecode wrote:

Basically these lower-level platform specific operations can be used 
to create a mobile handler script library, which would be a 
script-library in the open source repository - which can contain the 
cross-platform 'mobile' implementations.


It makes it visible, accessible and something which is much easier for 
people to contribute to - or copy, rename and modify as they need to 
for their specific project.


Got it. And yes, that speaks directly to my point, so we're on the
same page. Whew! Email is sometimes not the easiest way to
communicate, even when both sides are speaking the (more or less) same
language.


Heh - indeed - the thought in my mind was always that it would be a 
common script-library - however, looking back I never actually 
articulated that.


By the way @Richard - my suggestion for 'valueDiff' (or whatever variant 
comes out of any discussion) was that after some fettling over the 
details - such things like that could, too, become part of a common 
'utility' script library in the engine repository (or a set of utility 
libraries, after all not every project needs everything).


Indeed, internally we have already been building such a thing (for 
various reasons - although mainly because I got bored hand-coding the 
same lines of code again and again - which I'm sure we all do!) - its 
not ready for public release yet, but we fully intend to do so when 
we've dotted a few i's and crossed a few t's. (We need to support it 
after all if it is the main repository - so I want to make sure it is in 
a supportable state when it debuts).


One of the most useful things it has are LiveCode implementations of the 
Python path functions - and, oh my god, do they make any code which 
manipulates files s much easier.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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: Move command on iOS

2018-08-04 Thread J. Landman Gay via use-livecode
I did tinker with accleratedRendering when the problem first appeared. I 
turned it off before the move command and back on afterward, but it 
didn't help. I also changed the time so that the move was slower, but 
that didn't work either.


Panos seems to have identified the reason for the failure in my case, 
though I'm not sure it is applicable everywhere. It's posted in the bug 
report . Would this 
situation apply to your stack(s)?


I don't quite know why my stack ran okay on Monte's phone, and my 
stripped-down test with the same code ran okay in the simulator, but my 
real stack failed. Weird.


On 8/4/18 8:07 AM, Randy Hengst via use-livecode wrote:

Sorry I’m a bit late to this strand, but yes, I’ve seen what you’re describing 
Jacque. I’ve seen it in the simulator and when loaded on the iPad.

Have you tried turning off acceleratedRendering and setting to static? As I 
shared earlier with the list, the problem I’m seeing includes slowdowns of the 
movements.

I’ve read on in the strand… and I’m using move to …. without waiting. The move 
for me always includes two buttons… sometimes five depending on the context of 
the call.

I was also seeing some issues with the acceleratedRendering/dynamic in the IDE.


be well,
randy
www.classroomFocusedSoftware.com



On Aug 3, 2018, at 4:53 PM, J. Landman Gay via use-livecode 
 wrote:

Anyone else having trouble with the move command on iOS? I'm sliding a group 
into view, which works the first time, and after that it starts to move and 
then immediately jumps to its destination without any animation. It works fine 
in the IDE.

AccleratedRendering is true and the group layermode is "dynamic". I don't have 
an actual phone to try it on, so maybe this is a simulator problem?

--
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


___
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




--
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: valueDiff for arrays?

2018-08-04 Thread Richard Gaskin via use-livecode

Mark Waddingham wrote:

> Yes - so come up with LCS handlers which do that, share them, let's
> work together to make them as efficient in LCS as possible and then
> see what we can do in the engine to improve their performance (which
> I'm guessing is as much the purpose for the proposition as the
> syntax).

It is, primarily.  The minor convenience is nice too, but you know how 
much I love to see performance enhancements in the engine.


As for implementation, Mark Wieder's looks good:
http://lists.runrev.com/pipermail/use-livecode/2018-August/248862.html

Thinking about performance, I wonder if there's anything from some of 
the changes that have boosted PHP 7's performance so far above its 
earlier versions which may be relevant for LC:

https://www.reddit.com/r/PHP/comments/3q2brz/how_is_php_7_twice_as_fast/

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

___
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: valueDiff for arrays?

2018-08-04 Thread Brian Milby via use-livecode
Plugins should probably be de-scriptified for distribution for this
reason.  A similar argument could be made for some IDE library code too.  I
have to wonder if there is any performance impact to the number of stacks
the IDE has to deal with now that so much is scriptified.  (The list of
stacks is a linked list and finding a stack by name goes through the list
at least in one spot.).  I've been thinking of how to test this sort of
thing to measure it

It would be similar to how copy-on-write does incur a small amount of
overhead when compared to pass-by-reference that was demonstrated in an
earlier discussion.  The result there was that if you need to optimize for
speed, reference is still helpful.  If you are purely concerned about
memory usage, then it isn't needed.

On Sat, Aug 4, 2018 at 1:41 PM, Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 08/04/2018 11:23 AM, Mark Waddingham via use-livecode wrote:
>
> However, over time I'd suggest we look at it sitting in a
>> mobile-permissions script library. Given the dynamic nature of handler
>> dispatch in LC, there's all kinds of things we can do to make it really
>> easy to adapt for particular projects.
>>
>
> Although I do have to bemoan the proliferation of script stacks in the
> Project Browser list. This especially became onerous when the Navigator
> plugin started using script-only stacks. It's a pain having to scroll
> through all those stacks that I'm never going to edit, and it's a pain
> having to remove the plugin each time a new build comes out so that I don't
> have to scroll through them just to work on system stacks.
>
> --
>  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


Re: valueDiff for arrays?

2018-08-04 Thread Mark Waddingham via use-livecode

On 2018-08-04 20:41, Mark Wieder via use-livecode wrote:

On 08/04/2018 11:23 AM, Mark Waddingham via use-livecode wrote:

However, over time I'd suggest we look at it sitting in a 
mobile-permissions script library. Given the dynamic nature of handler 
dispatch in LC, there's all kinds of things we can do to make it 
really easy to adapt for particular projects.


Although I do have to bemoan the proliferation of script stacks in the
Project Browser list. This especially became onerous when the
Navigator plugin started using script-only stacks. It's a pain having
to scroll through all those stacks that I'm never going to edit, and
it's a pain having to remove the plugin each time a new build comes
out so that I don't have to scroll through them just to work on system
stacks.


So - what can we do to solve that?

The IDE script libraries at least use a very strict naming convention - 
if we can encourage others to do the same, then there's all kinds of 
filtering options we can do quite easily.


Remember that this isn't a unique problem to LiveCode - script only 
stacks (particularly how we've grown to use them) are akin to C source 
files / projects (mainly because that is abstractly what they are / 
represent). You get a similar problem managing the complexity of that in 
any large scale native project - look at the LiveCode main xcodeproj for 
an example of that.


Perhaps 'Show IDE Stacks in lists' (or whatever it is called) has become 
far far too blunt an instrument...


For example, the PB could offer a new 'top-level' - which is project. A 
project being defined by a set of stacks which share a common name 
prefix...


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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: valueDiff for arrays?

2018-08-04 Thread Mark Wieder via use-livecode

On 08/04/2018 11:23 AM, Mark Waddingham via use-livecode wrote:

However, over time I'd suggest we look at it sitting in a 
mobile-permissions script library. Given the dynamic nature of handler 
dispatch in LC, there's all kinds of things we can do to make it really 
easy to adapt for particular projects.


Although I do have to bemoan the proliferation of script stacks in the 
Project Browser list. This especially became onerous when the Navigator 
plugin started using script-only stacks. It's a pain having to scroll 
through all those stacks that I'm never going to edit, and it's a pain 
having to remove the plugin each time a new build comes out so that I 
don't have to scroll through them just to work on system stacks.


--
 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


Re: valueDiff for arrays?

2018-08-04 Thread Mark Wieder via use-livecode

On 08/04/2018 11:19 AM, Mark Waddingham via use-livecode wrote:

Basically these lower-level platform specific operations can be used to 
create a mobile handler script library, which would be a script-library 
in the open source repository - which can contain the cross-platform 
'mobile' implementations.


It makes it visible, accessible and something which is much easier for 
people to contribute to - or copy, rename and modify as they need to for 
their specific project.


Got it. And yes, that speaks directly to my point, so we're on the same 
page. Whew! Email is sometimes not the easiest way to communicate, even 
when both sides are speaking the (more or less) same language.


--
 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


Re: valueDiff for arrays?

2018-08-04 Thread Mark Waddingham via use-livecode

On 2018-08-04 20:15, Brian Milby via use-livecode wrote:
So maybe what is really needed is a split of the revcommonlibrary into 
3
separate ones:  revdesktoplibrary, revmobilelibrary, and 
revcommonlibrary.
Then utility functions that are easily written in LCS could be placed 
in
the appropriate library and would be available to all apps that are 
built
for that platform.  (I actually looked into this when working on adding 
the

common library to mobile.)


Yes! In the first instance that would be more than sufficient.

However, over time I'd suggest we look at it sitting in a 
mobile-permissions script library. Given the dynamic nature of handler 
dispatch in LC, there's all kinds of things we can do to make it really 
easy to adapt for particular projects.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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: valueDiff for arrays?

2018-08-04 Thread Mark Waddingham via use-livecode

On 2018-08-04 20:06, Mark Wieder via use-livecode wrote:

LOL. Well, OK. But by exposing *just* the mobileXXX function at the
scripting level, the onus is no longer on the developer to have to
script the utility function for each application. You have the
opportunity at this point to expose a single function rather than two
or three.

https://www.knowyourphrase.com/beating-a-dead-horse


LOL - perhaps - but its an important point which I perhaps did not make 
entirely clear - my bad!


My intent was never to suggest that every developer would have to hack 
their own together in every individual case... More that is gives us the 
opportunity to write an engine-level 'script library' in LCS which 
provides the functionality.


We have quite a rich extension system these days - and even before that 
liburl was embedded as essentially an engine feature, written in LCS 
because of the way it was handled in the IDE and Standalone Builder.


Basically these lower-level platform specific operations can be used to 
create a mobile handler script library, which would be a script-library 
in the open source repository - which can contain the cross-platform 
'mobile' implementations.


It makes it visible, accessible and something which is much easier for 
people to contribute to - or copy, rename and modify as they need to for 
their specific project.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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: DataGrid image display woes

2018-08-04 Thread Brian Milby via use-livecode
Wow, and Trevor knew right away... pretty impressive!
___
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: valueDiff for arrays?

2018-08-04 Thread Brian Milby via use-livecode
On Sat, Aug 4, 2018 at 1:06 PM, Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 08/04/2018 09:36 AM, Mark Waddingham via use-livecode wrote:
>
>> On 2018-08-04 18:25, Mark Wieder via use-livecode wrote:
>>
>
> Heh - well your pseudo-code just essentially made my point for me - why
>> does any of that need to be in the engine, if the engine provides the
>> underlying wrappers around the OS functionality (as it is on the specific
>> OS) to be able to write them? :)
>>
>
> LOL. Well, OK. But by exposing *just* the mobileXXX function at the
> scripting level, the onus is no longer on the developer to have to script
> the utility function for each application. You have the opportunity at this
> point to expose a single function rather than two or three.
>

So maybe what is really needed is a split of the revcommonlibrary into 3
separate ones:  revdesktoplibrary, revmobilelibrary, and revcommonlibrary.
Then utility functions that are easily written in LCS could be placed in
the appropriate library and would be available to all apps that are built
for that platform.  (I actually looked into this when working on adding the
common library to mobile.)
___
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: valueDiff for arrays?

2018-08-04 Thread Brian Milby via use-livecode
I guess I'll have to admit I had to do the line-by-line to see it, but once
I did I realized what the problem was.  Pointers and reference counting is
one thing that I still really need to think about when looking at lower
level code.  That is one thing that really does make LCS nice.  LCB too for
the most part, you can get into pointer stuff, but it is when you venture
there on purpose (FFI and/or using engine library code).
___
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: valueDiff for arrays?

2018-08-04 Thread Mark Wieder via use-livecode

On 08/04/2018 09:36 AM, Mark Waddingham via use-livecode wrote:

On 2018-08-04 18:25, Mark Wieder via use-livecode wrote:


Heh - well your pseudo-code just essentially made my point for me - why 
does any of that need to be in the engine, if the engine provides the 
underlying wrappers around the OS functionality (as it is on the 
specific OS) to be able to write them? :)


LOL. Well, OK. But by exposing *just* the mobileXXX function at the 
scripting level, the onus is no longer on the developer to have to 
script the utility function for each application. You have the 
opportunity at this point to expose a single function rather than two or 
three.


https://www.knowyourphrase.com/beating-a-dead-horse

--
 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


Re: Getting Started with DataGrid and another datagrid form question

2018-08-04 Thread zryip theSlug via use-livecode
Dear Douglas,

Thanks for your interesting feedback about your attempt to use DGH for the
first time, with creating a datagrid form.

All the properties for customizing the datagrid apart, I've created the
form template area (the way to custom the content of a row with controls
such as image, buttons, etc) with the following objectives:
- in the standard way to customize a datagrid template, we have to open the
row template group inside the template card. In DGH all this group is
copied inside a "visual" area we can manipulate
- when dropping some controls in the template area, with the datagrid, you
are alone with the required script for managing all these controls. DGH, at
the condition to respond to the right dialog, is building a minimal script
depending of the kind of controls you added. Unfortunately this is
difficult to cover all the needs, because they are all specific depending
of the developer and what he want to do. But at least the goal of the
installed script is to give you the keys and philosophy to understand what
it is required for the controls.For a button, how to perform an action, for
a checkbox, how to check or uncheck it, for an image how to display it, to
click it, etc
- one of the recurrent difficulties for users was to understand the
datagrid rows remains empty until you have populate it. And because it is
empty you will never see the beautiful button or image you have added if
you have not at least a row data. This is why in DGH, upper the template
area, we have a datagrid preview, to see immediately the control we have
added.

Your comment make me realize that it is not enough when you are beginning
with form template. One of my unexploited idea was to add kind of presets
template with for example a text on the left and four checkboxes on the
right, etc so the developper could start with ready to use templates to add
to his datagrid. The problem of the approach is covering needs, I can't
anticipate.

What might have you expected from DGH in this task? More tutorial
explaining how the template area is working?, more lessons?, contextual
help in DGH to help you to start? Something else? Feel free to expand, I'm
always interested in approachs or ways I could try to implement in the goal
to improve DGH.


Thanks in advance.


Best Regards,

On Sat, Aug 4, 2018 at 4:38 PM, Douglas Ruisaard via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I concur with Brahmanathaswami that, in particular, datagrid forms (I
> haven't worked with tables (yet)) are very finicky with regard to
> scrolling.  I still would greatly appreciate some help with a recently
> submitted message to this group, Subject:
>
> datagrid form question
>
> Once you play around with a grid enough, it becomes clearer on what you
> can and cannot do.
>
> Regarding DGH v2... during my initial foray into datagrid forms (very
> recent, by the way), I was hoping that DGH v2 would be the panacea for the
> initial confusion regarding datagrids.  Alas, it is likely a fine tool but,
> from my perspective (as many aspects of LC), it may be most effective once
> one has mastered the fundamentals of datagrid construction and usage.  I
> downloaded the trial version and will go back to it ASAP now that I am over
> that initial learning hump ... with A LOT more to learn, I'm sure.
>
> It would probably be worthwhile to read through my two posts under "
> datagrid form question " to consider what I discovered with regard to
> scrolling... hopefully, I've made the explanation clear enough but if not,
> I'd be glad to expand on the subject.
>
> Thanks in advance.
> Doug
>
>
> > At $45.00 (cheap) and with your own endorsement (knowing that it is
> maintained)
> >
> > I'll get it!
> >
> > Brahmanathaswami
> >
> > Ps do you have a real name?
> >
> > ?On 8/2/18, 12:01 PM, "use-livecode on behalf of zryip theSlug via
> use-livecode"  > boun...@lists.runrev.com on behalf of use-livecode@lists.runrev.com>
> wrote:
> >
> > Dear Swami,
> >
> > We have some free material about datagrids form or table.
> >
> > 1. A tutorial written long time ago before I created DGH, exploring
> the
> > very basic concepts of the datagrid control (form and table):
> > http://www.aslugontheroad.com/download/category/3-tutorials
> >
> > 2. Some demo stacks created for demonstrating datagrid's
> possibilities such
> > as drag and drop, calculation, etc
> > http://www.aslugontheroad.com/download/category/4-lab
> >
> > 3. About your screenshot, a datagrid form will be your better option
> in my
> > opinion.
> >
> > 4. And about Data Grid Helper, I can not answer objectively to your
> > question, for sure. All I can say is the tool has regular updates for
> > supporting the new versions of LiveCode. A new  major (nothing to do
> with
> > our friend Klaus :) (I prefer to specify because he made me the joke
> on the
> > livecode forum, haha :) )) 2.5 version has been released in June
> supporting
> > 

Re: valueDiff for arrays?

2018-08-04 Thread Mark Waddingham via use-livecode

On 2018-08-04 19:19, J. Landman Gay via use-livecode wrote:

This caught my attention. The increased security is great, and I've
heard it said before, but would love to hear the reasons that make it
more secure than lower level code. That way I'd have a knowledgeable
reason to be smug.


It is impossible to write LCS code which *just* manipulates values which 
will crash/vulnerability because of the code you have written in LCS 
*unless* there is actually a crash/vulnerability bug in the engine in 
one of the core operations which you are using.


If you translate an operation to C++, though - it is far far easier to 
introduce crashes and thus vulnerabilities - this is because C++ does 
not insulate you from the fundamentals of memory management, pointers or 
all that stuff which comes with writing in a language which is (in 
reality) only a short step away from machine code.


Admittedly, if you are using C++ as modern C++ then it is also quite 
hard to introduce such things (assuming you have built the abstractions 
using templates and C++'s typing system to do so correctly and use them 
uniformly and correctly) - but you still *can* write code that does as 
you can always by-pass C++'s typing and such - also the engine is not 
modern C++ - it is C which was transformed in C++ and due to various 
requirements on usage (at the lower-level) of the engine - many APIs 
used internally in the engine (e.g. libfoundation) are actually C APIs.


For example. Here is the core engine code for array intersection (which 
actually covers intersection, recursive intersection and difference):


static void MCArraysDoIntersect(MCExecContext& ctxt, MCValueRef p_dst, 
MCValueRef p_src, MCArrayDoIntersectOp p_op, MCValueRef& r_result)

{
if (!MCValueIsArray(p_dst))
{
r_result = MCValueRetain(p_dst);
return;

}

if (!MCValueIsArray(p_src))
{
if (p_op != kMCArrayDoIntersectOpDifference)
{
r_result = MCValueRetain(kMCEmptyString);
}
else
{
r_result = MCValueRetain(p_dst);
}
return;
}

MCArrayRef t_dst_array;
t_dst_array = (MCArrayRef)p_dst;

MCArrayRef t_src_array;
t_src_array = (MCArrayRef)p_src;

MCAutoArrayRef t_result;
if (!MCArrayMutableCopy(t_dst_array, _result))
return;

MCNameRef t_key;
MCValueRef t_src_value;
MCValueRef t_dst_value;
uintptr_t t_iterator;
t_iterator = 0;

while(MCArrayIterate(t_dst_array, t_iterator, t_key, t_dst_value))
{
bool t_key_exists;
t_key_exists = MCArrayFetchValue(t_src_array, ctxt . 
GetCaseSensitive(), t_key, t_src_value);


if (t_key_exists == (p_op == kMCArrayDoIntersectOpDifference))
{
if (!MCArrayRemoveValue(*t_result, ctxt . 
GetCaseSensitive(), t_key))

{
ctxt . Throw();
return;
}
}
else if (p_op == kMCArrayDoIntersectOpIntersectRecursively)
{
MCAutoValueRef t_recursive_result;
MCArraysDoIntersect(ctxt, t_dst_value, t_src_value, p_op, 
_recursive_result);


if (ctxt . HasError())
return;

if (!MCArrayStoreValue(*t_result, ctxt . GetCaseSensitive(), 
t_key, *t_recursive_result))

return;
}
}

r_result = MCValueRetain(*t_result);
}

This is, as far as I'm aware 'bug free' - in that the code respects all 
the semantics required of using all the lower-level functions it is 
built out of.


Here is a version which has a vulnerability/crash in it...

static void MCArraysDoIntersect(MCExecContext& ctxt, MCValueRef p_dst, 
MCValueRef p_src, MCArrayDoIntersectOp p_op, MCValueRef& r_result)

{
if (!MCValueIsArray(p_dst))
{
r_result = MCValueRetain(p_dst);
return;

}

if (!MCValueIsArray(p_src))
{
if (p_op != kMCArrayDoIntersectOpDifference)
{
r_result = MCValueRetain(kMCEmptyString);
}
else
{
r_result = p_dst;
}
return;
}

MCArrayRef t_dst_array;
t_dst_array = (MCArrayRef)p_dst;

MCArrayRef t_src_array;
t_src_array = (MCArrayRef)p_src;

MCAutoArrayRef t_result;
if (!MCArrayMutableCopy(t_dst_array, _result))
return;

MCNameRef t_key;
MCValueRef t_src_value;
MCValueRef t_dst_value;
uintptr_t t_iterator;
t_iterator = 0;

while(MCArrayIterate(t_dst_array, t_iterator, t_key, t_dst_value))
{
bool t_key_exists;
t_key_exists = MCArrayFetchValue(t_src_array, ctxt . 
GetCaseSensitive(), t_key, t_src_value);


if (t_key_exists == (p_op == kMCArrayDoIntersectOpDifference))
{
if (!MCArrayRemoveValue(*t_result, ctxt . 
GetCaseSensitive(), t_key))

{
ctxt . Throw();
return;
}
}
else if (p_op == 

Re: Getting Started with DataGrid

2018-08-04 Thread Stephen Barncard via use-livecode
 Thank you for your service, Mr. slug.
I love your revolutionary spirit, and thank you for your contributions,
priceless on this list.

I’m blown away.

On Sat, Aug 4, 2018 at 10:09 zryip theSlug via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Dear Swami,
>
> Thanks for your purchase.
>
>
> Yes I do have a real name and I do have a good reason to not share it
> publicly. When I came with the personnal challenge 8 years ago to create a
> commercial plugin, I was an employee and as a developper, my employment
> contract was containing a clause not allowing me to develop something like
> that.
> Now, even if I'm no longer a developer (my service was closed some years
> ago, and I failed to find a new job like the old one, because I have just
> no diploma in development, despite more than 10 years experience in
> different languages) my new employer not allowed me to cumulate salaries
> even if I might earn one dollar with an another activity. I asked and he
> was clear in his reply.
>
> So I don't know what rules you have in your countries, but these rules are
> real in mine and my risk is just to be fired. As I'm considering I'm free
> to do what I want during my free time and hobbies, to be sure this will
> never happen, you will never seen my real name anywhere.
>
> So I'm quite outlaw, free to do what I want (developping a commercial
> plugin during my free time, just because this was an old dream, a challenge
> and this is actually for me a way to continue to code for real users),
> using an odd nick name, which is well worth another.
>
> That's all the story behind this. Hope I have clarified this a bit.
>
>
> Best Regards,
>
> On Fri, Aug 3, 2018 at 4:14 AM, Sannyasin Brahmanathaswami via use-livecode
>  wrote:
>
> > Aloha "Zryip"
> >
> > At $45.00 (cheap) and with your own endorsement (knowing that it is
> > maintained)
> >
> > I'll get it!
> >
> > Brahmanathaswami
> >
> > Ps do you have a real name?
> >
> > On 8/2/18, 12:01 PM, "use-livecode on behalf of zryip theSlug via
> > use-livecode"  > use-livecode@lists.runrev.com> wrote:
> >
> > Dear Swami,
> >
> > We have some free material about datagrids form or table.
> >
> > 1. A tutorial written long time ago before I created DGH, exploring
> the
> > very basic concepts of the datagrid control (form and table):
> > http://www.aslugontheroad.com/download/category/3-tutorials
> >
> > 2. Some demo stacks created for demonstrating datagrid's
> possibilities
> > such
> > as drag and drop, calculation, etc
> > http://www.aslugontheroad.com/download/category/4-lab
> >
> > 3. About your screenshot, a datagrid form will be your better option
> > in my
> > opinion.
> >
> > 4. And about Data Grid Helper, I can not answer objectively to your
> > question, for sure. All I can say is the tool has regular updates for
> > supporting the new versions of LiveCode. A new  major (nothing to do
> > with
> > our friend Klaus :) (I prefer to specify because he made me the joke
> > on the
> > livecode forum, haha :) )) 2.5 version has been released in June
> > supporting
> > dg2 properties, widgets, custom headers, etc. A blog article has been
> > published about it, with some available screenshots of the new
> > features:
> >
> https://livecode.com/data-grid-helper-2-5-adds-support-for-datagrid-2/
> >
> > Now, if someone in the List want to add a comment about DGH, positive
> > or
> > not, he / she is welcome. :)
> >
> >
> > Best Regards,
> >
> >
> >
> > ___
> > 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
> >
>
>
>
> --
> Zryip TheSlug
> http://www.aslugontheroad.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

-- 
--
Stephen Barncard - Sebastopol Ca. USA -
mixstream.org
___
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: valueDiff for arrays?

2018-08-04 Thread Brian Milby via use-livecode
On Sat, Aug 4, 2018 at 11:33 AM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> This one's not at all hard to write, just floated the idea to see if
> others saw it suitable to add to the "convenience" functions already in the
> language, such as:
>
>
@Richard,

What was your intent on the return value?  Did you want an array or the
keys.  If an array, which value for the differences (Left, Right,
Both-how?)  I'd like to compare how I solve it to how you did.

Thanks,
Brian
___
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: valueDiff for arrays?

2018-08-04 Thread J. Landman Gay via use-livecode
This caught my attention. The increased security is great, and I've heard 
it said before, but would love to hear the reasons that make it more secure 
than lower level code. That way I'd have a knowledgeable reason to be smug.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On August 4, 2018 10:59:23 AM Mark Waddingham via use-livecode 
 wrote:


Yes - but coding in LCS is much more fun, quicker (for me, anyway - and
I've been writing C/C++ for nigh-on 30 years) - more importantly it is
also MUCH MUCH more secure.





___
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: valueDiff for arrays?

2018-08-04 Thread Mark Waddingham via use-livecode

On 2018-08-04 18:33, Richard Gaskin via use-livecode wrote:

Adding more such commands to operate on values instead of just keys
would be handy, but not at all necessary.  There are more pressing
concerns that only the engine team can implement, and scripting in
LiveCode is something every LiveCode scripter can do.


Yes - so come up with LCS handlers which do that, share them, let's work 
together to make them as efficient in LCS as possible and then see what 
we can do in the engine to improve their performance (which I'm guessing 
is as much the purpose for the proposition as the syntax).


If they show up more fundamental operations which they can be built out 
of which can be made exceptionally efficient in C++ (because it has 
greater fidelity at the bit/pointer/memory level), then we add those and 
then the higher-level operations that use them remain in LCS.


The only difference between value manipulation operations in the engine 
and in LCS is (at the end of day) the syntax, and the overhead of 
maintenance. Maintenance of every single line of C++ code is at least an 
order of magnitude mode expensive (in both time, man power and money) 
than an equivalent line in LCS (otherwise we'd all be coding in C++, 
wouldn't we?).


So - first - if you have an implementation of valueDiff - share it. It 
means everyone can see directly in code, what your English description 
actually means in effect. Then it means everyone can look to see how 
efficient it can be made in LCS - and, also to see if it can be broken 
down into more vastly more re-usable fundamental operations which allows 
us all to build even more utility functions.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps


___
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: valueDiff for arrays?

2018-08-04 Thread Mark Waddingham via use-livecode

On 2018-08-04 18:37, Brian Milby via use-livecode wrote:

@Mark,
I wasn't necessarily suggesting that it belonged in the engine, but
pointing out why I would look at the code.


:)

Understanding how the engine actually operates is important, because it 
can help to design the LCS implementation to work with its 
implementation rather than against it.


I will say from some other things that I've looked at recently that 
speed
would be so much faster in the engine - if it was a feature that 
merited
being there.  I did kind of cheat in that I looked at how the engine 
did

the array union/intersect functions.  The source actually contains LCS
versions of the logic too.  What I'm thinking is that there will be an
array size where iterating the array 3 times (twice by the engine-
intersect and symmetric difference or union) will be faster than 
iterating

the array once in LCS (using modified union logic).


Yes - which is why digging into the engine code and experimenting to 
produce a good higher-level LCS implementation is the right approach.


Adding variant codepaths based on size of arrays and such is probably 
inappropriate in the engine - because it will likely always be dependent 
on the data set. (If you can prove that it is independent of dataset - 
or is almost always what you might say is the amortized best-case - like 
qsort - which is actually O(n^2) worst case, its just that you have to 
work pretty darn hard to produce its worst-case behavior - then it makes 
sense to do so).


Sometimes optimizations will be independent of all of that though. For 
example:


All array operations are currently X, Y -> Z - i.e. not in-place. In the 
cases where (for example):


  intersect X with Y

Is operating on an X which can safely be mutated directly - there is a 
much more efficient implementation which does not require creating a new 
array (i.e. you just loop through and delete the keys in X which aren't 
in Y).


The reason the current implementations are in-place is actually due to 
the syntax dispatch - that needs to be able to detect the 'correct' 
situation where in-place can be used and then use it.


All of the current engine array code is based on comparing the key.  
The

distinction here is that a value comparison is also required.


Indeed - which is why I wonder whether there are more fundamental 
operations which do a basic 'key-ish' thing which would be appropriate 
for being in the engine - as then any variation on what 'valueDiff' 
might mean could be coded in LCS with little overhead compared to a 
hard-coded C++ version.


i.e. I can certainly say that a patch which makes in-place array 
operations work (in a way which doesn't cause a ripple effect elsewhere 
in terms of locality and such) would be accepted.


I can also certainly forsee there being a variation on the 
union/intersect etc. commands which are 'general' operations taking into 
the key that would also make sense to be in the engine... However, I'm 
not sure quite what that/they would be - but would be most interested to 
see proposals / examples of (and implementations too) :)


So in no way was I intending to discourage you from your efforts - just 
trying to focus on trying to find where the line is between engine/LCS 
in terms of interface - that's the hardest part. At the end of the day, 
the actual coding in one language or another when you know what you are 
meaning to achieve is (communally) quite trivial.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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: Getting Started with DataGrid

2018-08-04 Thread zryip theSlug via use-livecode
Dear Swami,

Thanks for your purchase.


Yes I do have a real name and I do have a good reason to not share it
publicly. When I came with the personnal challenge 8 years ago to create a
commercial plugin, I was an employee and as a developper, my employment
contract was containing a clause not allowing me to develop something like
that.
Now, even if I'm no longer a developer (my service was closed some years
ago, and I failed to find a new job like the old one, because I have just
no diploma in development, despite more than 10 years experience in
different languages) my new employer not allowed me to cumulate salaries
even if I might earn one dollar with an another activity. I asked and he
was clear in his reply.

So I don't know what rules you have in your countries, but these rules are
real in mine and my risk is just to be fired. As I'm considering I'm free
to do what I want during my free time and hobbies, to be sure this will
never happen, you will never seen my real name anywhere.

So I'm quite outlaw, free to do what I want (developping a commercial
plugin during my free time, just because this was an old dream, a challenge
and this is actually for me a way to continue to code for real users),
using an odd nick name, which is well worth another.

That's all the story behind this. Hope I have clarified this a bit.


Best Regards,

On Fri, Aug 3, 2018 at 4:14 AM, Sannyasin Brahmanathaswami via use-livecode
 wrote:

> Aloha "Zryip"
>
> At $45.00 (cheap) and with your own endorsement (knowing that it is
> maintained)
>
> I'll get it!
>
> Brahmanathaswami
>
> Ps do you have a real name?
>
> On 8/2/18, 12:01 PM, "use-livecode on behalf of zryip theSlug via
> use-livecode"  use-livecode@lists.runrev.com> wrote:
>
> Dear Swami,
>
> We have some free material about datagrids form or table.
>
> 1. A tutorial written long time ago before I created DGH, exploring the
> very basic concepts of the datagrid control (form and table):
> http://www.aslugontheroad.com/download/category/3-tutorials
>
> 2. Some demo stacks created for demonstrating datagrid's possibilities
> such
> as drag and drop, calculation, etc
> http://www.aslugontheroad.com/download/category/4-lab
>
> 3. About your screenshot, a datagrid form will be your better option
> in my
> opinion.
>
> 4. And about Data Grid Helper, I can not answer objectively to your
> question, for sure. All I can say is the tool has regular updates for
> supporting the new versions of LiveCode. A new  major (nothing to do
> with
> our friend Klaus :) (I prefer to specify because he made me the joke
> on the
> livecode forum, haha :) )) 2.5 version has been released in June
> supporting
> dg2 properties, widgets, custom headers, etc. A blog article has been
> published about it, with some available screenshots of the new
> features:
> https://livecode.com/data-grid-helper-2-5-adds-support-for-datagrid-2/
>
> Now, if someone in the List want to add a comment about DGH, positive
> or
> not, he / she is welcome. :)
>
>
> Best Regards,
>
>
>
> ___
> 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
>



-- 
Zryip TheSlug
http://www.aslugontheroad.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: valueDiff for arrays?

2018-08-04 Thread Brian Milby via use-livecode
On Sat, Aug 4, 2018 at 10:57 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2018-08-04 04:00, Brian Milby via use-livecode wrote:
>
>> Other than the fact that coding is fun :)
>>
>
> Yes - but coding in LCS is much more fun, quicker (for me, anyway - and
> I've been writing C/C++ for nigh-on 30 years) - more importantly it is also
> MUCH MUCH more secure.
>

@Mark,
I wasn't necessarily suggesting that it belonged in the engine, but
pointing out why I would look at the code.

I will say from some other things that I've looked at recently that speed
would be so much faster in the engine - if it was a feature that merited
being there.  I did kind of cheat in that I looked at how the engine did
the array union/intersect functions.  The source actually contains LCS
versions of the logic too.  What I'm thinking is that there will be an
array size where iterating the array 3 times (twice by the engine-
intersect and symmetric difference or union) will be faster than iterating
the array once in LCS (using modified union logic).

All of the current engine array code is based on comparing the key.  The
distinction here is that a value comparison is also required.

Thanks,
Brian
___
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: valueDiff for arrays?

2018-08-04 Thread Mark Waddingham via use-livecode

On 2018-08-04 18:25, Mark Wieder via use-livecode wrote:

On 08/04/2018 08:57 AM, Mark Waddingham via use-livecode wrote:

On a related note, I get the feeling I might have irked Mr Wieder the 
other day with regards the android permission thing - that wasn't my


No, not irked, and sorry if I gave that impression.
My point was simply that the way I would approach this is (pseudocode 
follows)


function mobilePermissions
  switch platform
case "iOS"
  return iosPermissions
  break
case "Android"
  return androidPermissions
  break
  end switch
end mobilePermissions

private function iosPermissions
  return_the_array_of_ios_permissions
end iosPermissions

private function androidPermissions
  throw "not yet implemented"
end androidPermissions

...document the fact that mobilePermissions is available *only* on iOS
for now, and then flesh out the Android function later on. My thinking
being that developers could use the mobileXXX functions when
developing for iOS and then not have to change their code for Android
down the line.


Heh - well your pseudo-code just essentially made my point for me - why 
does any of that need to be in the engine, if the engine provides the 
underlying wrappers around the OS functionality (as it is on the 
specific OS) to be able to write them? :)


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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: valueDiff for arrays?

2018-08-04 Thread Richard Gaskin via use-livecode

Mark Waddingham wrote:

> In general coding things in C++ in the engine should be strictly
> reserved for things where it is *absolutely* required - and in this
> case, I don't see an absolute requirement in this case (yet!).
>
> This would be fundamental operations, and the interconnection with
> things where doing it in LCS or LCB is not feasible or cannot produce
> the fidelity required to do it.

Agreed.  This one's not at all hard to write, just floated the idea to 
see if others saw it suitable to add to the "convenience" functions 
already in the language, such as:


> All array operations in LiveCode (union, intersect etc.) can all be
> written precisely (as in replicating exact functionality of the
> engine) in LCS.

LC has a few things like that. It was nice to see "difference" added to 
that suite fairly recently.


Adding more such commands to operate on values instead of just keys 
would be handy, but not at all necessary.  There are more pressing 
concerns that only the engine team can implement, and scripting in 
LiveCode is something every LiveCode scripter can do.


--
 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: valueDiff for arrays?

2018-08-04 Thread Mark Wieder via use-livecode

On 08/04/2018 08:57 AM, Mark Waddingham via use-livecode wrote:

On a related note, I get the feeling I might have irked Mr Wieder the 
other day with regards the android permission thing - that wasn't my 


No, not irked, and sorry if I gave that impression.
My point was simply that the way I would approach this is (pseudocode 
follows)


function mobilePermissions
  switch platform
case "iOS"
  return iosPermissions
  break
case "Android"
  return androidPermissions
  break
  end switch
end mobilePermissions

private function iosPermissions
  return_the_array_of_ios_permissions
end iosPermissions

private function androidPermissions
  throw "not yet implemented"
end androidPermissions

...document the fact that mobilePermissions is available *only* on iOS 
for now, and then flesh out the Android function later on. My thinking 
being that developers could use the mobileXXX functions when developing 
for iOS and then not have to change their code for Android down the line.


--
 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


LCB - Text entry/edit in a widget

2018-08-04 Thread pink via use-livecode
What I would like to make is a widget that essentially functions as a multi
field form. 

I know how to add text to a widget, but how can I make editable by the user?

Essentially, how can I create one or more "fields" in a widget?



-
---
Greg (pink) Miller
mad, pink and dangerous to code
--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
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: valueDiff for arrays?

2018-08-04 Thread Mark Waddingham via use-livecode

On 2018-08-04 04:00, Brian Milby via use-livecode wrote:

Other than the fact that coding is fun :)


Yes - but coding in LCS is much more fun, quicker (for me, anyway - and 
I've been writing C/C++ for nigh-on 30 years) - more importantly it is 
also MUCH MUCH more secure.


Additionally, it is also the *one* language that everyone on this list 
understands and comprehends. and more secure than in C++


In general coding things in C++ in the engine should be strictly 
reserved for things where it is *absolutely* required - and in this 
case, I don't see an absolute requirement in this case (yet!).


This would be fundamental operations, and the interconnection with 
things where doing it in LCS or LCB is not feasible or cannot produce 
the fidelity required to do it.


All array operations in LiveCode (union, intersect etc.) can all be 
written precisely (as in replicating exact functionality of the engine) 
in LCS. Indeed, I'm pretty sure there are comments lurking around either 
in tests, or in the engine source which show the LCS equivalent. In this 
case, the C++ implementation is merely a 'hand-coded' to-C++ compilation 
of the an LCS handler for all intents and purposes (and I'm not even 
sure there is much performance advantage to it being so - perhaps an 
interesting project to determine, for those that are interested in such 
things!).


My suggestion here would be *first* write an LCS handler which does what 
you want. Then rewrite it, trying to distill it down so it does a single 
orthogonal operation (it might be what you actually want is a 
composition of two or more). Get a 'perfect' LCS implementation written 
which uses the engine's various 'internal' features (names, 
copy-on-write) etc. to make sure it is as efficient as it can be 
(centered around the use of lists / arrays - i.e. actual individual 
values - rather than string-lists).


This will give rise to a name of the operation, or fundamental 
operations it is composed of; the name(s) of which will lead to 
potential syntax for it/them... For example, there is zero semantic 
(i.e. runtime effect) difference between:


  arrayUnion @xArray, pOtherArray

and

  union xArray with pOtherArray

The difference is purely in our brains language-processing centers - the 
abstract operation is the same.


As I've always said in the past, english-like syntax is like sugar (when 
used as a condiment) - it makes many things easier to ingest (there are 
many things which many people would not even think about wanting to 
eat/drink without it), but is something you add after something exists, 
not before it does.


On a related note, I get the feeling I might have irked Mr Wieder the 
other day with regards the android permission thing - that wasn't my 
intent - but it is a similar situation. Android and iOS permissions are 
actually really quite different - yes they have the same user-level 
effect - but internally iOS's are essentially limited and hard-coded, 
Android's are not. If we had 'raced' to implement a uniform 'mobile' 
abstraction form for them - then it would have most likely have been 
wrong or at the very least very limited. Instead, we now have a simple 
set of Android handlers (3 IIRC) which mean that an LC application can 
utilise the full power (and it is quite extensive!) of the Android 
permissions usage APIs - as if you were writing in Java (but a little 
bit easier to grok!).


The 'mobileRequestPermission' handler which would be nice - can be done 
in an LCS library - where it is easy to change / evolve and get right. 
Indeed, people can write their own variants should they have the need 
and then feed back if they want to.


If we had raced straight to C++ this wouldn't have been the case. You 
all would have been stuck with what the people who poke around in the 
engine had come up with and their understanding of that particular part 
of the Android elephant and any future changes to them would have been 
glacial.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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: DataGrid image display woes

2018-08-04 Thread FlexibleLearning.com via use-livecode
 I recently wrote... 

> Okay, I have a datagrid Form with a template to display an image and 4
fields.
> 
> The fields display the correct data for each line/record, but the unique
image
> for each line/record is not being correctly displayed.
> 
> If the dataGrid height can show all records, the image for the last record
is
> displayed in the first line and all the other images are empty. If the
dataGrid
> requires scrolling to display all the records, only every 7th line
displays an
> image and the image changes as the group is scrolled. I have tried all the
> versions I have from from 5.54 up to 8.1 with the same problem.
> 
> Is this a known issue?
> 
> Hugh Senior


Cancel all that... my object referencing error by omitting "of me". Must be
tyred.

Except now the dataGrid no longer scrolls... Restart the engine... Now it
scrolls.

I should write a book entitled "DataGrids or Voodoo, you decide"

Hugh Senior




___
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: A poor man's app updater

2018-08-04 Thread Kee Nethery via use-livecode
For sure don’t try to write updates to Applications on macOS, that requires 
permissions. Far better to treat them as app data and store in same place 
preferences get stored.

Kee Nethery

> On Aug 3, 2018, at 5:29 PM, Peter Bogdanoff via use-livecode 
>  wrote:
> 
> So, to store and access LC stacks and other files used by myApp that must be 
> periodically updated, does it make sense to put them into
> 
> macOS—Library/Application Support/myApp
> Win—user/AppData/myApp
> 
> rather than in Applications or Program Files?
> 
> Are there any restrictions or downside to this?
> 
> Peter
> 
>> On Aug 3, 2018, at 5:14 AM, Paul Dupuis via use-livecode 
>>  wrote:
>> 
>> On 8/3/2018 2:32 AM, Peter Bogdanoff via use-livecode wrote:
>>> Hi,
>>> 
>>> To raise the issue again of updating Mac and Windows apps, I’m referencing 
>>> this thread between Graham and Jacqueline...
>>> 
>>> Can existing files in the user’s application directory be 
>>> saved/modified/replaced by my application?
>>> 
>> 
>> The accurate answer is that it all depends upon the permissions of the
>> account running the software. Typically for most personal or home
>> computers, the user has administrative privs, but that is increasingly
>> not the case on university or company owned computers. On these, they
>> may not have permission to alter files in the Program Files (Win) or
>> Applications (OSX) folders.
>> 
>> In some cases, again depending on OS and permissions, you can alter the
>> folders contents directly. In others you application must launch a
>> process (another app) with elevated privs, where the OS asks the user
>> for permissions for the elevated privs, and then that app (if allowed)
>> can make changes.
>> 
>> 
>> ___
>> 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: Getting Started with DataGrid and another datagrid form question

2018-08-04 Thread Douglas Ruisaard via use-livecode
I concur with Brahmanathaswami that, in particular, datagrid forms (I haven't 
worked with tables (yet)) are very finicky with regard to scrolling.  I still 
would greatly appreciate some help with a recently submitted message to this 
group, Subject:

datagrid form question

Once you play around with a grid enough, it becomes clearer on what you can and 
cannot do.

Regarding DGH v2... during my initial foray into datagrid forms (very recent, 
by the way), I was hoping that DGH v2 would be the panacea for the initial 
confusion regarding datagrids.  Alas, it is likely a fine tool but, from my 
perspective (as many aspects of LC), it may be most effective once one has 
mastered the fundamentals of datagrid construction and usage.  I downloaded the 
trial version and will go back to it ASAP now that I am over that initial 
learning hump ... with A LOT more to learn, I'm sure.

It would probably be worthwhile to read through my two posts under " datagrid 
form question " to consider what I discovered with regard to scrolling... 
hopefully, I've made the explanation clear enough but if not, I'd be glad to 
expand on the subject.

Thanks in advance.
Doug


> At $45.00 (cheap) and with your own endorsement (knowing that it is 
> maintained)
> 
> I'll get it!
> 
> Brahmanathaswami
> 
> Ps do you have a real name?
> 
> ?On 8/2/18, 12:01 PM, "use-livecode on behalf of zryip theSlug via 
> use-livecode"  boun...@lists.runrev.com on behalf of use-livecode@lists.runrev.com> wrote:
> 
> Dear Swami,
> 
> We have some free material about datagrids form or table.
> 
> 1. A tutorial written long time ago before I created DGH, exploring the
> very basic concepts of the datagrid control (form and table):
> http://www.aslugontheroad.com/download/category/3-tutorials
> 
> 2. Some demo stacks created for demonstrating datagrid's possibilities 
>such
> as drag and drop, calculation, etc
> http://www.aslugontheroad.com/download/category/4-lab
> 
> 3. About your screenshot, a datagrid form will be your better option in my
> opinion.
> 
> 4. And about Data Grid Helper, I can not answer objectively to your
> question, for sure. All I can say is the tool has regular updates for
> supporting the new versions of LiveCode. A new  major (nothing to do with
> our friend Klaus :) (I prefer to specify because he made me the joke on 
>the
> livecode forum, haha :) )) 2.5 version has been released in June 
>supporting
> dg2 properties, widgets, custom headers, etc. A blog article has been
> published about it, with some available screenshots of the new features:
> https://livecode.com/data-grid-helper-2-5-adds-support-for-datagrid-2/
> 
> Now, if someone in the List want to add a comment about DGH, positive or
> not, he / she is welcome. :)
> 
> 
> Best Regards,
>

Douglas Ruisaard
Trilogy Software
(250) 573-3935



___
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: Move command on iOS

2018-08-04 Thread Randy Hengst via use-livecode
Sorry I’m a bit late to this strand, but yes, I’ve seen what you’re describing 
Jacque. I’ve seen it in the simulator and when loaded on the iPad.

Have you tried turning off acceleratedRendering and setting to static? As I 
shared earlier with the list, the problem I’m seeing includes slowdowns of the 
movements.

I’ve read on in the strand… and I’m using move to …. without waiting. The move 
for me always includes two buttons… sometimes five depending on the context of 
the call.

I was also seeing some issues with the acceleratedRendering/dynamic in the IDE.


be well,
randy
www.classroomFocusedSoftware.com


> On Aug 3, 2018, at 4:53 PM, J. Landman Gay via use-livecode 
>  wrote:
> 
> Anyone else having trouble with the move command on iOS? I'm sliding a group 
> into view, which works the first time, and after that it starts to move and 
> then immediately jumps to its destination without any animation. It works 
> fine in the IDE.
> 
> AccleratedRendering is true and the group layermode is "dynamic". I don't 
> have an actual phone to try it on, so maybe this is a simulator problem?
> 
> -- 
> 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

___
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: DataGrid image display woes

2018-08-04 Thread Trevor DeVore via use-livecode
Are you missing an “of me” in the code that sets the image data?

-- 
Trevor DeVore

On Sat, Aug 4, 2018 at 5:38 AM FlexibleLearning.com via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Okay, I have a datagrid Form with a template to display an image and 4
> fields.
>
> The fields display the correct data for each line/record, but the unique
> image for each line/record is not being correctly displayed.
>
> If the dataGrid height can show all records, the image for the last record
> is displayed in the first line and all the other images are empty. If the
> dataGrid requires scrolling to display all the records, only every 7th line
> displays an image and the image changes as the group is scrolled. I have
> tried all the versions I have from from 5.54 up to 8.1 with the same
> problem.
>
> Is this a known issue?
>
> Hugh Senior
>
>
> ___
> 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

DataGrid image display woes

2018-08-04 Thread FlexibleLearning.com via use-livecode
Okay, I have a datagrid Form with a template to display an image and 4
fields. 

The fields display the correct data for each line/record, but the unique
image for each line/record is not being correctly displayed.

If the dataGrid height can show all records, the image for the last record
is displayed in the first line and all the other images are empty. If the
dataGrid requires scrolling to display all the records, only every 7th line
displays an image and the image changes as the group is scrolled. I have
tried all the versions I have from from 5.54 up to 8.1 with the same
problem.

Is this a known issue?

Hugh Senior


___
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: Move command on iOS

2018-08-04 Thread panagiotis merakos via use-livecode
Hello all,

I have added a comment to the bug report.

Best,
Panos
--

On Sat, Aug 4, 2018 at 7:53 AM, Monte Goulding via use-livecode <
use-livecode@lists.runrev.com> wrote:

> This seems to work fine here testing on a device
>
> > On 4 Aug 2018, at 2:20 pm, J. Landman Gay via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > I jumped the gun and sent a download link to both of you. But you're
> hours ahead of him so you have time to intercept. :)
> >
> > On 8/3/18 10:25 PM, Monte Goulding via use-livecode wrote:
> >> Hmm… feel free to send through to me as I’m intrigued. I will send the
> stack to Panos if I can’t figure out what is going on so he can put it
> wherever private test stacks go.
> >>> On 4 Aug 2018, at 1:05 pm, J. Landman Gay via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >>>
> >>> Skip the test, it works fine in isolation. Bug report is here:
> >>> https://quality.livecode.com/show_bug.cgi?id=21461
> >>>
> >>> But there must be something else going on so I should send the real
> stack to either you or Panos I guess.
> >>>
> >>> On 8/3/18 9:27 PM, J. Landman Gay via use-livecode wrote:
>  Here's the relevant part of the script. There's only one "move"
> command:
>  put the long id of grp "iOSPicker" into tGrp
>  get the height of tGrp div 2
>  put the height of this cd - it into tDestV
>  show tGrp -- before updating text
>  wait 1 millisecond with messages
>  move tGrp to (item 1 of the loc of me),tDestV in 500 milliseconds
>  I put the wait command in there to see if it made any difference but
> it doesn't.
>  If the above isn't enough, it would be quicker if I could just send
> you my client's stack privately. Is that okay? I'll put in a bug report
> regardless.
>  On 8/3/18 8:27 PM, Monte Goulding via use-livecode wrote:
> > @Jacque I’ve had a look around the engine… would be interested to
> know if you are moving without waiting or not (if that makes a difference).
> >
> > It looks like the most likely cause of what you are seeing is
> multiple calls to `move` the object to a location. The second of which will
> look like the first just ended because a second move ends the first and
> then the object is already at the location. Perhaps log when you are doing
> it?
> >
> >>>
> >>>
> >>> --
> >>> 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
> >> ___
> >> 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
> >
> >
> > --
> > 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
>
>
> ___
> 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: Move command on iOS

2018-08-04 Thread Monte Goulding via use-livecode
This seems to work fine here testing on a device

> On 4 Aug 2018, at 2:20 pm, J. Landman Gay via use-livecode 
>  wrote:
> 
> I jumped the gun and sent a download link to both of you. But you're hours 
> ahead of him so you have time to intercept. :)
> 
> On 8/3/18 10:25 PM, Monte Goulding via use-livecode wrote:
>> Hmm… feel free to send through to me as I’m intrigued. I will send the stack 
>> to Panos if I can’t figure out what is going on so he can put it wherever 
>> private test stacks go.
>>> On 4 Aug 2018, at 1:05 pm, J. Landman Gay via use-livecode 
>>>  wrote:
>>> 
>>> Skip the test, it works fine in isolation. Bug report is here:
>>> https://quality.livecode.com/show_bug.cgi?id=21461
>>> 
>>> But there must be something else going on so I should send the real stack 
>>> to either you or Panos I guess.
>>> 
>>> On 8/3/18 9:27 PM, J. Landman Gay via use-livecode wrote:
 Here's the relevant part of the script. There's only one "move" command:
 put the long id of grp "iOSPicker" into tGrp
 get the height of tGrp div 2
 put the height of this cd - it into tDestV
 show tGrp -- before updating text
 wait 1 millisecond with messages
 move tGrp to (item 1 of the loc of me),tDestV in 500 milliseconds
 I put the wait command in there to see if it made any difference but it 
 doesn't.
 If the above isn't enough, it would be quicker if I could just send you my 
 client's stack privately. Is that okay? I'll put in a bug report 
 regardless.
 On 8/3/18 8:27 PM, Monte Goulding via use-livecode wrote:
> @Jacque I’ve had a look around the engine… would be interested to know if 
> you are moving without waiting or not (if that makes a difference).
> 
> It looks like the most likely cause of what you are seeing is multiple 
> calls to `move` the object to a location. The second of which will look 
> like the first just ended because a second move ends the first and then 
> the object is already at the location. Perhaps log when you are doing it?
> 
>>> 
>>> 
>>> -- 
>>> 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
>> ___
>> 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
> 
> 
> -- 
> 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


___
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