Re: The use-livecode list.

[J. Landman Gay via use-livecode]

We did it just for you because we've all been there.

:)

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On August 19, 2022 6:54:47 PM Alex Tweedly via use-livecode 
 wrote:



I've had a pretty shitty day. A variety of things have happened, or not
happened, that made it not one of the good days.

So I was not happy, and rather grumpy. (My apologies to Panos for being
ungracious in an earlier post - it was meant to be a plea for
completeness of the product in preference to more work-arounds - but it
came across wrongly. Sorry, Panos).

And then, the use-list comes up with a nice, tight, well-defined problem
to tackle - and now I can end my day on a puzzle-solving high note,
rather than dragging myself off to bed on a downbeat.

Thanks again, use-list !!

Alex.



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

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





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

Re: The use-livecode list.

[Paul Dupuis via use-livecode]

No, THANK YOU!


On 8/19/2022 7:53 PM, Alex Tweedly via use-livecode wrote:
I've had a pretty shitty day. A variety of things have happened, or 
not happened, that made it not one of the good days.


So I was not happy, and rather grumpy. (My apologies to Panos for 
being ungracious in an earlier post - it was meant to be a plea for 
completeness of the product in preference to more work-arounds - but 
it came across wrongly. Sorry, Panos).


And then, the use-list comes up with a nice, tight, well-defined 
problem to tackle - and now I can end my day on a puzzle-solving high 
note, rather than dragging myself off to bed on a downbeat.


Thanks again, use-list !!

Alex.



___
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

The use-livecode list.

[Alex Tweedly via use-livecode]

I've had a pretty shitty day. A variety of things have happened, or not 
happened, that made it not one of the good days.


So I was not happy, and rather grumpy. (My apologies to Panos for being 
ungracious in an earlier post - it was meant to be a plea for 
completeness of the product in preference to more work-arounds - but it 
came across wrongly. Sorry, Panos).


And then, the use-list comes up with a nice, tight, well-defined problem 
to tackle - and now I can end my day on a puzzle-solving high note, 
rather than dragging myself off to bed on a downbeat.


Thanks again, use-list !!

Alex.



___
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: Livecode performance problem

[Paul Dupuis via use-livecode]

On 8/19/2022 7:40 PM, Mark Wieder via use-livecode wrote:

On 8/19/22 16:31, Alex Tweedly via use-livecode wrote:

to trim about another 15% off the time (for my sample data, 24ms down 
to 20ms.)


Nice.
Note, of course, that we're all going on the assumption that all four 
fields contain the same number of lines.





Thank you all for the example of improving performance over my clunky code.

Yes, all the fields contain the same number of lines.

For strange legacy application reasons, when lines get added to the set 
of fields (a frequency action by users - sometimes adding hundreds of 
lines a day), the data has to be repackaged into this tab delimited 
structure in a single variable to run some procedures on.


So a user driven action of:

1) Add a line (or a few) to the fields
2) repackage data and run a few procedures
3) User repeats starting at step 1

Can become very slow as the number of lines in the fields gets large - 
as you all have noted!


Thank you all again!



___
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: Livecode performance problem

[Alex Tweedly via use-livecode]

On 20/08/2022 00:03, Bob Sneidar via use-livecode wrote:

It's probably a lot of text. The engine has to start from the beginning of 
every string then scan through for every cr or lf or cr/lf or whatever counts 
as a line break, until if finds the nth one. The more lines, the longer the 
scan takes each time, and the more text per line the exponentially more time it 
takes. Multiply that by 4 times plus the combinination of all of them as the 
code progresses *4 for the output string and you have the makings of a mountain 
that keeps getting steeper the higher you go.


Yes, for all the input strings. For the output string, it's just a "put 
... after ...", so there is no need to count or scan the output string; 
LC already keeps (effectively) a pointer to the end of a string, and 
optimizes the straightforward extension at the end of a string.


Alex.



___
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: Livecode performance problem

[Mark Wieder via use-livecode]

On 8/19/22 16:03, Bob Sneidar via use-livecode wrote:

It's probably a lot of text. The engine has to start from the beginning of 
every string then scan through for every cr or lf or cr/lf or whatever counts 
as a line break, until if finds the nth one. The more lines, the longer the 
scan takes each time, and the more text per line the exponentially more time it 
takes. Multiply that by 4 times plus the combinination of all of them as the 
code progresses *4 for the output string and you have the makings of a mountain 
that keeps getting steeper the higher you go.


My tests were based on 2174 lines of text in each field.
Got nowhere near 20 seconds. Or even one.

--
 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: Livecode performance problem

[Mark Wieder via use-livecode]

On 8/19/22 16:31, Alex Tweedly via use-livecode wrote:

to trim about another 15% off the time (for my sample data, 24ms down to 
20ms.)


Nice.
Note, of course, that we're all going on the assumption that all four 
fields contain the same number of lines.



--
 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: Livecode performance problem

[Alex Tweedly via use-livecode]

On 19/08/2022 23:32, Mark Wieder via use-livecode wrote:


It is indeed faster. Here's what I came up with. I'm not sure why 2000 
lines of text in four fields should take that long, I came up with


original code: 320 ms
array version: 21 ms

   put empty into vCombined
   put fld "A" into v1
   put fld "B" into v2
   put fld "C" into v3
   put fld "D" into v4
   split v1 by cr
   split v2 by cr
   split v3 by cr
   split v4 by cr
   put 1 into i
   repeat for each element tLine in v1
  put i[i][i][i][i] after 
vCombined

  add 1 to i
   end repeat


which is already quick enough that any further improvement is mainly 
academic.


But for the record:

"repeat for each line " is very efficient for a single variable, o you 
can avoid one of the four 'split's, and use the line variable to count 
your loop.



   --   split v1 by cr
   split v2 by cr
   split v3 by cr
   split v4 by cr
   put 1 into i
   repeat for each line tLine in v1
  put i& tLine & v2[i] & v3[i] & v4[i] & cr after 
vCombined

  add 1 to i
   end repeat

to trim about another 15% off the time (for my sample data, 24ms down to 
20ms.)


(and if you know that one of the four fields typically contains much 
more text (i.e. longer lines) than the others, you would choose it to 
not be split).


Alex.



___
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: Livecode performance problem

[Bob Sneidar via use-livecode]

It's probably a lot of text. The engine has to start from the beginning of 
every string then scan through for every cr or lf or cr/lf or whatever counts 
as a line break, until if finds the nth one. The more lines, the longer the 
scan takes each time, and the more text per line the exponentially more time it 
takes. Multiply that by 4 times plus the combinination of all of them as the 
code progresses *4 for the output string and you have the makings of a mountain 
that keeps getting steeper the higher you go.

That is my understanding at least.

Bob S


On Aug 19, 2022, at 15:32 , Mark Wieder via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

It is indeed faster. Here's what I came up with. I'm not sure why 2000 lines of 
text in four fields should take that long, I came up with

___
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: Livecode performance problem

[Mark Wieder via use-livecode]

On 8/19/22 15:07, Bob Sneidar via use-livecode wrote:

Off the top of my head:

split v1 by tab
split v2 by tab
split v3 by tab
split v4 by tab

put the keys of v1 into tKeyList
sort tKeyList ascending numeric

repeat for each line tKey in tKeyList
put tKey & tab & v1 [tKey] & tab & v2 [tKey] & tab & v3 [tKey] & tab & v4 
[tKey] & cr after tCombined
end repeat

Not sure if this will be faster, but every time you refer to a line of a string 
the engine has to parse out where that line is from the beginning.


It is indeed faster. Here's what I came up with. I'm not sure why 2000 
lines of text in four fields should take that long, I came up with


original code: 320 ms
array version: 21 ms

   put empty into vCombined
   put fld "A" into v1
   put fld "B" into v2
   put fld "C" into v3
   put fld "D" into v4
   split v1 by cr
   split v2 by cr
   split v3 by cr
   split v4 by cr
   put 1 into i
   repeat for each element tLine in v1
  put i[i][i][i][i] after vCombined
  add 1 to i
   end repeat



--
 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: Livecode performance problem

[Brian Milby via use-livecode]

Based on what Bob said, here is my version of that handler:

on mouseUp
   local tA, tB, tC, tD, tAll, tStart, tEnd
   put fld "A" into tA
   put fld "B" into tB
   put fld "C" into tC
   put fld "D" into tD
   --
   put the milliseconds into tStart
   split tA by cr
   split tB by cr
   split tC by cr
   split tD by cr
   repeat with i=1 to the number of lines of the keys of tA
  put i & tab & tA[i] & tab & tB[i] & tab & tC[i] & tab & tD[i] & cr
after tAll
   end repeat
   delete the last char of tAll
   put the milliseconds into tEnd
   put (tEnd - tStart) & cr & tAll into fld "result"
end mouseUp

I used very short lines, but this way was 3/4ms; my initial method was
6/7ms; your original method was 15/16ms.

On Fri, Aug 19, 2022 at 6:09 PM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Off the top of my head:
>
> split v1 by tab
> split v2 by tab
> split v3 by tab
> split v4 by tab
>
> put the keys of v1 into tKeyList
> sort tKeyList ascending numeric
>
> repeat for each line tKey in tKeyList
>put tKey & tab & v1 [tKey] & tab & v2 [tKey] & tab & v3 [tKey] & tab &
> v4 [tKey] & cr after tCombined
> end repeat
>
> Not sure if this will be faster, but every time you refer to a line of a
> string the engine has to parse out where that line is from the beginning.
> Parsing times will increase exponentially (is that the right term?) the
> more lines you are parsing in both the source strings AND the destination
> string.
>
> But arrays are indexed memory locations so the engine knows exactly where
> every bit of text is. And putting something after a string does not have to
> parse to find the end, the engine knows where that is in memory. It might
> be even faster though if you build an array as output and then use the
> combine command to convert it all at once to a string.
>
> I am assuming of course that splitting does not put lines of text in
> random order in the array. Arrays can be dicey that way.
>
> Bob S
>
>
>
> > On Aug 19, 2022, at 14:09 , Paul Dupuis via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > I have a set of fields, call them A, B, C, and D. Each has the same
> number of lines. Each field has different text (per line)
> >
> > I need to combine the data - frequently - into a form that look like:
> >
> >  C>
> >
> > For the number of lines in the set of fields. Currently I do this as
> follows:
> >
> > put empty into vCombined
> > put fld A into v1
> > put fld B into v2
> > put fld C into v3
> > put fld D into v4
> > repeat with i=1 to the number of lines in v1
> >   put i & line i of v1 & line i of v2 & line i of v3 &
> line i of v4 into line i of vCombined
> > end repeat
> >
> > I put the field contents into variable before the loop to combine them
> as my understanding is variable access is faster than field access in a loop
> >
> > My question to the Hivemind is: Is there a noticeably faster way to
> covert these field to the tab delimited structure as show above than the
> code above?
> >
> > This current takes about 20 seconds for 2000 lines or about a second per
> 100 lines (very roughly, I was not using a timer in my code, just my
> wristwatch seconds in the IDE debugger between breakpoints)
> >
> > Thank you for any pointers in advance,
> >
> > Paul Dupuis
> > Researchware
> >
> >
> > ___
> > 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: Livecode performance problem

[Brian Milby via use-livecode]

First optimization would be to put … & cr after vCombined and then delete the 
trailing from when done.

Sent from my iPhone

> On Aug 19, 2022, at 5:11 PM, Paul Dupuis via use-livecode 
>  wrote:
> 
> I have a set of fields, call them A, B, C, and D. Each has the same number 
> of lines. Each field has different text (per line)
> 
> I need to combine the data - frequently - into a form that look like:
> 
>  C>
> 
> For the number of lines in the set of fields. Currently I do this as follows:
> 
> put empty into vCombined
> put fld A into v1
> put fld B into v2
> put fld C into v3
> put fld D into v4
> repeat with i=1 to the number of lines in v1
>   put i & line i of v1 & line i of v2 & line i of v3 & line i 
> of v4 into line i of vCombined
> end repeat
> 
> I put the field contents into variable before the loop to combine them as my 
> understanding is variable access is faster than field access in a loop
> 
> My question to the Hivemind is: Is there a noticeably faster way to covert 
> these field to the tab delimited structure as show above than the code above?
> 
> This current takes about 20 seconds for 2000 lines or about a second per 100 
> lines (very roughly, I was not using a timer in my code, just my wristwatch 
> seconds in the IDE debugger between breakpoints)
> 
> Thank you for any pointers in advance,
> 
> Paul Dupuis
> Researchware
> 
> 
> ___
> 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: Livecode performance problem

[Bob Sneidar via use-livecode]

Off the top of my head:

split v1 by tab
split v2 by tab
split v3 by tab
split v4 by tab

put the keys of v1 into tKeyList
sort tKeyList ascending numeric

repeat for each line tKey in tKeyList
   put tKey & tab & v1 [tKey] & tab & v2 [tKey] & tab & v3 [tKey] & tab & v4 
[tKey] & cr after tCombined
end repeat

Not sure if this will be faster, but every time you refer to a line of a string 
the engine has to parse out where that line is from the beginning. Parsing 
times will increase exponentially (is that the right term?) the more lines you 
are parsing in both the source strings AND the destination string. 

But arrays are indexed memory locations so the engine knows exactly where every 
bit of text is. And putting something after a string does not have to parse to 
find the end, the engine knows where that is in memory. It might be even faster 
though if you build an array as output and then use the combine command to 
convert it all at once to a string. 

I am assuming of course that splitting does not put lines of text in random 
order in the array. Arrays can be dicey that way. 

Bob S



> On Aug 19, 2022, at 14:09 , Paul Dupuis via use-livecode 
>  wrote:
> 
> I have a set of fields, call them A, B, C, and D. Each has the same number of 
> lines. Each field has different text (per line)
> 
> I need to combine the data - frequently - into a form that look like:
> 
>  C>
> 
> For the number of lines in the set of fields. Currently I do this as follows:
> 
> put empty into vCombined
> put fld A into v1
> put fld B into v2
> put fld C into v3
> put fld D into v4
> repeat with i=1 to the number of lines in v1
>   put i & line i of v1 & line i of v2 & line i of v3 & line i 
> of v4 into line i of vCombined
> end repeat
> 
> I put the field contents into variable before the loop to combine them as my 
> understanding is variable access is faster than field access in a loop
> 
> My question to the Hivemind is: Is there a noticeably faster way to covert 
> these field to the tab delimited structure as show above than the code above?
> 
> This current takes about 20 seconds for 2000 lines or about a second per 100 
> lines (very roughly, I was not using a timer in my code, just my wristwatch 
> seconds in the IDE debugger between breakpoints)
> 
> Thank you for any pointers in advance,
> 
> Paul Dupuis
> Researchware
> 
> 
> ___
> 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

Livecode performance problem

[Paul Dupuis via use-livecode]

I have a set of fields, call them A, B, C, and D. Each has the same 
number of lines. Each field has different text (per line)


I need to combine the data - frequently - into a form that look like:

C>


For the number of lines in the set of fields. Currently I do this as 
follows:


put empty into vCombined
put fld A into v1
put fld B into v2
put fld C into v3
put fld D into v4
repeat with i=1 to the number of lines in v1
  put i & line i of v1 & line i of v2 & line i of v3 & 
line i of v4 into line i of vCombined

end repeat

I put the field contents into variable before the loop to combine them 
as my understanding is variable access is faster than field access in a loop


My question to the Hivemind is: Is there a noticeably faster way to 
covert these field to the tab delimited structure as show above than the 
code above?


This current takes about 20 seconds for 2000 lines or about a second per 
100 lines (very roughly, I was not using a timer in my code, just my 
wristwatch seconds in the IDE debugger between breakpoints)


Thank you for any pointers in advance,

Paul Dupuis
Researchware


___
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 few issues with web apps

[Tweedly via use-livecode]

> On 19 Aug 2022, at 16:01, panagiotis m via use-livecode 
>  wrote:
> 
> Hello all,
> 
> BTW, I just wrote a lesson on how to scroll a LC text field on Web using
> :
>> 
Thank you. 
But at the risk of sounding ungrateful - please don’t.
Please just make basic functionality like resizing, scrolling, etc. Work 
properly and nicely out of the box.
Alex.

___
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 few issues with web apps

[J. Landman Gay via use-livecode]

I just tried the kangaroo example on your web site using my Android tablet. 
It behaves just like my slider widget. I can tap in the scrollbar to get 
the field scroll to jump but the indicator can't be moved. When I try, the 
whole canvas moves instead.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On August 19, 2022 8:23:25 AM Andreas Bergendal via use-livecode 
 wrote:


Thanks for the hint, Panos - that is useful to mention for those who want 
to try it.

However, that is not my problem - I’ve already done that!

Kangaroo’s stack works as advertised, as is (with dp-4 mod):
https://wheninspace.com/test/WebScrollField.html 



But when I try to use the code, either like in the original, where it is 
inserted by an LC script in preOpenStack, or by extracting the actual js 
and putting it into the html file beforehand, it just doesn’t trigger. I 
get no error message, js or LC, it just does nothing.


Actually, it was the same with the ”Meeting space” demo, which has a 
slightly different scroll wheel script. At first, I took both the resize js 
and the scroll js from there, but only the resize part works for me. It’s 
strange since my portal solution apparently catches resize events and 
passes them on to topStack, but fails to catch/pass scroll events…


/Andreas
___
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: A few issues with web apps

[panagiotis m via use-livecode]

Hello all,

BTW, I just wrote a lesson on how to scroll a LC text field on Web using
:

https://lessons.livecode.com/m/2592/l/1595736-scrolling-a-livecode-text-field-on-web-using-javascript

Cheers,
Panos
--

On Fri, 19 Aug 2022 at 16:22, Andreas Bergendal via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Thanks for the hint, Panos - that is useful to mention for those who want
> to try it.
> However, that is not my problem - I’ve already done that!
>
> Kangaroo’s stack works as advertised, as is (with dp-4 mod):
> https://wheninspace.com/test/WebScrollField.html <
> https://wheninspace.com/test/WebScrollField.html>
>
> But when I try to use the code, either like in the original, where it is
> inserted by an LC script in preOpenStack, or by extracting the actual js
> and putting it into the html file beforehand, it just doesn’t trigger. I
> get no error message, js or LC, it just does nothing.
>
> Actually, it was the same with the ”Meeting space” demo, which has a
> slightly different scroll wheel script. At first, I took both the resize js
> and the scroll js from there, but only the resize part works for me. It’s
> strange since my portal solution apparently catches resize events and
> passes them on to topStack, but fails to catch/pass scroll events…
>
> /Andreas
> ___
> 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: polylist toys

[Mike Kerner via use-livecode]

while we're on the topic, i was just having a conversation off-list and it
reminded me: we really should do another lcb class.
i looked at lcb a couple of times, messed with it, and then said "meh", and
moved on.

On Fri, Aug 19, 2022 at 8:56 AM panagiotis m via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hello,
>
> Thank you all for the useful comments.
>
> I *think* the LCB feature in LC 10 Steven mentioned is the "is
> valid" operator, that returns a boolean value indicating whether or not the
> image data is valid.
> Also, note that in the upcoming releases of LC 10 we will add syntax for
> checking if a file/directory exists, so we could check not only image
> validity but also image existence in the first place.
>
> BTW, we have found a workaround for allowing this stack (lazy image
> example) to work in LC 9 as well. The updated bundle will probably appear
> in your account area in the next couple of days.
>
> Kind regards,
> Panos
> --
>
> On Fri, 19 Aug 2022 at 01:13, Alex Tweedly via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> >
> > On 18/08/2022 17:34, Steven Crighton via use-livecode wrote:
> > > Hi Mike,
> > >
> > > I just tested the lazy load example and hit populate and clicked around
> > etc and could not trigger an error.
> >
> > As already confirmed, that problem is fixed in 10.
> >
> > However, the lazy load example still contains bugs due to race
> > conditions, some of which I described in some forum post somewhere (Boy
> > do I hate the forums! Surely there's some way to check what posts I have
> > done myself).
> >
> > Thinking about it more, there are other race conditions which are
> > perhaps more obscure, but more serious. I know it's only an example, and
> > maybe can't be expected to be bulletproof, but as an example of how to
> > do Lazy Loading it is (IMHO) really too naive and simplistic. People
> > expect to take those examples and just use them.
> >
> > The obvious race conditions are:
> >
> > 1. if multiple entries reference the same image, then there is a chance
> > the earlier ones never get properly updated (sURLToIndex[pURL] will have
> > been overwritten by the next call to onlineImage before the image value
> > gets set).
> >
> > 2. if the user (or anything else) resets the dataContent of the widget
> > while there are outstanding "load URL"s, then when the downloadComplete
> > is triggered, it will set the image value for some random new item to
> > the image of the earlier one.
> >
> > 3. And if the one which was wrongly set in case 2 above also happens to
> > be a URL that occurs multiple time (i.e. case 1 above), then that
> > wrongly set image will remain "forever".
> >
> > Alex.
> > ___
> > 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
>


-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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 few issues with web apps

[Andreas Bergendal via use-livecode]

Thanks for the hint, Panos - that is useful to mention for those who want to 
try it.
However, that is not my problem - I’ve already done that! 

Kangaroo’s stack works as advertised, as is (with dp-4 mod):
https://wheninspace.com/test/WebScrollField.html 


But when I try to use the code, either like in the original, where it is 
inserted by an LC script in preOpenStack, or by extracting the actual js and 
putting it into the html file beforehand, it just doesn’t trigger. I get no 
error message, js or LC, it just does nothing.

Actually, it was the same with the ”Meeting space” demo, which has a slightly 
different scroll wheel script. At first, I took both the resize js and the 
scroll js from there, but only the resize part works for me. It’s strange since 
my portal solution apparently catches resize events and passes them on to 
topStack, but fails to catch/pass scroll events…

/Andreas
___
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 few issues with web apps

[panagiotis m via use-livecode]

Hello Andreas,

To use Kangaroo's sample stack as is (
https://forums.livecode.com/viewtopic.php?f=120=36957) you have to tweak
the custom standalone.html that is included in the Copy Files section and
replace "" at line 213
with the correct version of LC 10 you're using, I guess in this case
""

Cheers,
Panos
--

On Fri, 19 Aug 2022 at 15:53, Andreas Bergendal via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Bah, I can only get Kangaroo’s scroller trigger to work if deployed in a
> separate standalone. No matter how I try to integrate the code in my
> portal, it just doesn’t trigger.
>
> In any case, the code that works in desktop web browsers doesn't work in
> mobile browsers, so there is still a problem to solve there. Hoping for the
> mothership to fix (in-field wheel/touch) scrolling natively in coming dp’s…
>
> I mean, clicking/touching the actual scrollbar of a field always works,
> but in a desktop browser you want the mouse wheel scroll to work in fields
> (Kangaroo’s script does that, sometimes...), and on mobile
> touching/dragging over a field should scroll it (still unsolved).
> ___
> 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: polylist toys

[panagiotis m via use-livecode]

Hello,

Thank you all for the useful comments.

I *think* the LCB feature in LC 10 Steven mentioned is the "is
valid" operator, that returns a boolean value indicating whether or not the
image data is valid.
Also, note that in the upcoming releases of LC 10 we will add syntax for
checking if a file/directory exists, so we could check not only image
validity but also image existence in the first place.

BTW, we have found a workaround for allowing this stack (lazy image
example) to work in LC 9 as well. The updated bundle will probably appear
in your account area in the next couple of days.

Kind regards,
Panos
--

On Fri, 19 Aug 2022 at 01:13, Alex Tweedly via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> On 18/08/2022 17:34, Steven Crighton via use-livecode wrote:
> > Hi Mike,
> >
> > I just tested the lazy load example and hit populate and clicked around
> etc and could not trigger an error.
>
> As already confirmed, that problem is fixed in 10.
>
> However, the lazy load example still contains bugs due to race
> conditions, some of which I described in some forum post somewhere (Boy
> do I hate the forums! Surely there's some way to check what posts I have
> done myself).
>
> Thinking about it more, there are other race conditions which are
> perhaps more obscure, but more serious. I know it's only an example, and
> maybe can't be expected to be bulletproof, but as an example of how to
> do Lazy Loading it is (IMHO) really too naive and simplistic. People
> expect to take those examples and just use them.
>
> The obvious race conditions are:
>
> 1. if multiple entries reference the same image, then there is a chance
> the earlier ones never get properly updated (sURLToIndex[pURL] will have
> been overwritten by the next call to onlineImage before the image value
> gets set).
>
> 2. if the user (or anything else) resets the dataContent of the widget
> while there are outstanding "load URL"s, then when the downloadComplete
> is triggered, it will set the image value for some random new item to
> the image of the earlier one.
>
> 3. And if the one which was wrongly set in case 2 above also happens to
> be a URL that occurs multiple time (i.e. case 1 above), then that
> wrongly set image will remain "forever".
>
> Alex.
> ___
> 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: A few issues with web apps

[Andreas Bergendal via use-livecode]

Bah, I can only get Kangaroo’s scroller trigger to work if deployed in a 
separate standalone. No matter how I try to integrate the code in my portal, it 
just doesn’t trigger.

In any case, the code that works in desktop web browsers doesn't work in mobile 
browsers, so there is still a problem to solve there. Hoping for the mothership 
to fix (in-field wheel/touch) scrolling natively in coming dp’s… 

I mean, clicking/touching the actual scrollbar of a field always works, but in 
a desktop browser you want the mouse wheel scroll to work in fields (Kangaroo’s 
script does that, sometimes...), and on mobile touching/dragging over a field 
should scroll it (still unsolved).
___
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

A few issues with web apps

[Andreas Bergendal via use-livecode]

Hi Jacque,

1. I can’t test on Android, but I doubt an Android native field would solve the 
problem here, as the platform is Web, thus not really natively Android. The LC 
web engine doesn’t seem to know where it is running, apart from "in a browser”… 
But do try putting an Android native field in your test stack and see what 
happens. I’ll test an iOS field and see what I get.

2. I confirm the slider widget/object looks and functions horribly on iOS and 
macOS too. See next point.

3. Motif makes most standard LC objects look horrible, but the mothership has 
promised to get rid of that in future releases (please hurry! :).

As to getting scrollers to work, some js seems necessary - see the excellent 
work by Kangaroo in the forum: 
https://forums.livecode.com/viewtopic.php?f=120=36957 

Hopefully that solution can be applied to sliders too. Again, I doubt the 
native mobile scroller would work, because platform = web.

Actually, my next step is anyway to test scroller stuff in my portal - I’ll 
make sure to try not just fields but also the slider. I’ll be back! :)

/Andreas
___
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