Hmm. I thought you could still get URL blah blah on mobile and it would
work. In fact, though the functionality differs slightly, you can use the
load command on mobile too. Perhaps this would be useful? If you're using
http urls, the only real difference in load between desktop and mobile, is
-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of J. Landman Gay
Sent: Saturday, March 21, 2015 6:04 PM
To: How to use LiveCode
Subject: Re: Speed on Android
On 3/21/2015 1:51 PM, Ralph DiMola wrote:
I see what libURL is all about but I don't see what it has to do with
opening
PM
To: How to use LiveCode
Subject: Re: Speed on Android
On 3/21/2015 1:51 PM, Ralph DiMola wrote:
I see what libURL is all about but I don't see what it has to do with
opening a MySQL db from an app.
The database is on a remote server, so it uses an http URL rather than a
file path
On 3/21/2015 5:24 PM, Ralph DiMola wrote:
I just open the remote database like this== put revOpenDatabase(mysql,
YourDomain.on-rev.com, DatabaseName ,Username ,Password true)
into DBID
Note there is nohttp://;
Yes, I misspoke. There's no http in the database path, it's like yours:
put
On 3/21/2015 1:44 PM, Richard Gaskin wrote:
J. Landman Gay wrote:
Richard Gaskin wrote:
Que a post from Mark Wieder about the benefits of web APIs
for DB connectivity in three...two...one...
...
...the conclusion is: remote database connections are not supported.
But GET and PUT are.
[mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of J. Landman Gay
Sent: Saturday, March 21, 2015 6:41 PM
To: How to use LiveCode
Subject: Re: Speed on Android
On 3/21/2015 5:24 PM, Ralph DiMola wrote:
I just open the remote database like this== put
revOpenDatabase(mysql, YourDomain.on
...@evergreeninfo.net
-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of J. Landman Gay
Sent: Saturday, March 21, 2015 6:41 PM
To: How to use LiveCode
Subject: Re: Speed on Android
On 3/21/2015 5:24 PM, Ralph DiMola wrote:
I just open the remote
On 3/21/2015 7:39 PM, Ralph DiMola wrote:
Another thing. Could it be your router/firewall? Did you try over the
cellular network?
If it were my router I think it would fail on my Mac and it works fine
there. I can try on a different network though.
How about the true I put in the
On 3/21/2015 7:34 PM, Ralph DiMola wrote:
Brain storm.
How about the true I put in the revOpenDatabase after the password,
Could this be it?
Oh man. That was it. I think I love you.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software |
On 3/20/2015 4:52 PM, Colin Holgate wrote:
Is there a very simple test stack you can make that shows the delay?
Does it make a difference if you use touch events instead of mouse
events?
Okay, I've narrowed it down to the database drivers or libraries. If I
create an apk without any database
message /divdivFrom: J. Landman Gay
jac...@hyperactivesw.com /divdivDate:03/21/2015 01:40 (GMT-05:00)
/divdivTo: How to use LiveCode use-livecode@lists.runrev.com
/divdivSubject: Re: Speed on Android /divdiv
/divOn 3/20/2015 11:07 PM, Ralph DiMola wrote:
I use both SQLite and MySQL
On 3/20/2015 11:07 PM, Ralph DiMola wrote:
I use both SQLite and MySQL in Android apps.
There are background images, resizing going on and local SQLite DB access to
build scrolling lists of hundreds of lines in sub-second card changes after
touching a button. Even orientation changes with
Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net
-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of J. Landman Gay
Sent: Friday, March 20, 2015 8:40 PM
To: How to use LiveCode
Subject: Re: Speed on Android
On 3
I'm trying to build an Android app. It is taking about 5 seconds to
respond to touches, card changes, etc. I started with 7.0.3, then tried
in 6.6.7 thinking it might be faster but it's the same. Buttons and list
fields are not autohiliting because it takes too long for the app to
realize
Is there a very simple test stack you can make that shows the delay? Does it
make a difference if you use touch events instead of mouse events?
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe
DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net
-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of J. Landman Gay
Sent: Friday, March 20, 2015 5:20 PM
To: LiveCode Mailing List
Subject: Speed on Android
I'm trying
On 3/20/2015 4:20 PM, J. Landman Gay wrote:
Any speedup tricks?
An addition: the main problem seems to be that it is taking 5-8 seconds
to respond to a touch event. After that, scripts run at only slightly
slower speeds than desktop.
I'm using mouseUp rather than touchEnd. Would that
On Mon, Jan 26, 2015 at 10:54 AM, Geoff Canyon gcan...@gmail.com wrote:
set relayergroupedcontrols to true
set the layer of whatever control to whatever layer
wow.
That did it.
I keep trying to read large blocks of the dictionary, but there is still so
much to find . . .
We're a long way
set relayergroupedcontrols to true
set the layer of whatever control to whatever layer
On Sun, Jan 25, 2015 at 7:30 PM, Scott Rossi sc...@tactilemedia.com wrote:
Try locking the screen before doing any object relayering.
Regards,
Scott Rossi
Creative Director
Tactile Media, UX/UI Design
Try locking the screen before doing any object relayering.
Regards,
Scott Rossi
Creative Director
Tactile Media, UX/UI Design
On Jan 25, 2015, at 5:19 PM, Dr. Hawkins doch...@gmail.com wrote:
I have a group with four overlapping graphics.
Depending upon what happens, different ones want
I have a group with four overlapping graphics.
Depending upon what happens, different ones want to be brought to the top
and change the overlap.
I'm currently using start editing/set the layer of zzz to top/stop
editing. I think it also changes the size.
I can actually see the order in which
Try using the relayer command;
relayer grc 1 of grp x after grc 2 of grp x
You don't need to start editing with relayer, but you need to be careful not to
relayer an object to outside the group.
HTH
Eric
On Jan 25, 2015, at 17:19, Dr. Hawkins doch...@gmail.com wrote:
I have a group
Geoff
Thanks for your input.
I think you are correct that the memory access comparison isn’t fair. I don’t
have time right now but I’ll try to come up with a better comparison.
I’m not convinced that the file comparison is fair. If LiveCode is appending
the data to the file rather than
as a professional server tool we need to identify
and eliminate any significant performance difference between it and PHP.”
I thought that it would be worth spending a little time to compare the
speed of LiveCode against the speed of PHP. I came up with a test based
loosely on Carl Sassenrath’s
spending a little time to compare the
speed of LiveCode against the speed of PHP. I came up with a test based
loosely on Carl Sassenrath’s Rebol Speed Script (
http://www.rebol.com/cgi-bin/blog.r?view=0506 ). I have found it a
useful
base for writing comparative scripts (either comparing
that it would be worth spending a little time to compare the
speed of LiveCode against the speed of PHP. I came up with a test
based
loosely on Carl Sassenrath’s Rebol Speed Script (
http://www.rebol.com/cgi-bin/blog.r?view=0506 ). I have found it a
useful
base for writing comparative scripts
On Tue, Nov 25, 2014 at 5:16 AM, Andre Garzia an...@andregarzia.com wrote:
co-routines
mmm, co-routines...
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
difference between it and PHP.”
I thought that it would be worth spending a little time to compare the
speed of LiveCode against the speed of PHP. I came up with a test based
loosely on Carl Sassenrath’s Rebol Speed Script (
http://www.rebol.com/cgi-bin/blog.r?view=0506 ). I have found it a useful
that it would be worth spending a little time to compare the
speed of LiveCode against the speed of PHP. I came up with a test based
loosely on Carl Sassenrath’s Rebol Speed Script (
http://www.rebol.com/cgi-bin/blog.r?view=0506 ). I have found it a useful
base for writing comparative scripts
.”
I thought that it would be worth spending a little time to compare the speed of
LiveCode against the speed of PHP. I came up with a test based loosely on Carl
Sassenrath’s Rebol Speed Script ( http://www.rebol.com/cgi-bin/blog.r?view=0506
). I have found it a useful base for writing comparative
It is my understanding that reference to id is faster than name.
However, if i get the long id of something, I can get
field id 1 of group id 2 of group id 3 of card id 4 of stack theSubStack
of stack /some/really/long/filename
If I take
word 1 to 3 of theLongId word -6 to -4 of theLongId,
I apologize if someone has brought this up before. I don’t recall.
I’m working on an update to an app and have switched over to using LC 6.7.
Apart from having to change a line of code to get in-app purchases working
correctly (new syntax), I’m noticing a speed difference. After building
Wed, 3 Sep 2014 08:56:11 -0500
Geoff Canyon wrote :
Gah, I forgot one stinkin' line:
put isNewElement into wasNewElement
That does the JOB :-)
I was playing around with deleting duplicate perms inside the handler, which
worked, but Geoff's solution (correct script) is much faster.
On Tue, Sep 2, 2014 at 1:45 PM, Beat Cornaz b.cor...@gmx.net wrote:
Mon, 1 Sep 2014 19:47:58 -0500
From: Geoff Canyon gcan...@gmail.com
I think this is faster for many arguments. It might be slower for others.
Your right. The only thing with this script is, that it sometimes
generates too
Mon, 1 Sep 2014 19:35:31 -0500
From: Geoff Canyon gcan...@gmail.com
I have a set of code that seems to do the trick. It takes as an argument the
number of each element to permute.
Great, Geoff, this works fine. Quite clever thinking :-)
Mon, 1 Sep 2014 19:47:58 -0500
From: Geoff Canyon
On Mon, Sep 1, 2014 at 5:58 PM, Geoff Canyon gcan...@gmail.com wrote:
All justifications aside, I'd use method 3 all the time unless something
broke. ;-)
A recent post on a similar topic (filtering lines by filetype from the
output of the files) made me think of this thread again.
I tried
hasMemory may indeed be of some use, but I have had problems with it in the
past. Besides, as has been pointed out, anything that is likely to drain all
memory should probably be served from a database anyway.
heapSpace is for HC/SC compatibility and does not map on all (if any)
platforms.
Hi Alex
Agreed. And your #4 is a nice solution.
Hugh Senior
FLCo
From: Alex Tweedly
Hugh,
The condition you've chosen for deciding whether to delete the line is
whether or not the line is empty.
So in method 2, replacing those lines by has no effect on the data.
That is, I think, an
Thanks to j...@souslelogo.com for the suggestion that hasMemory(bytes)
might be useful. I haven't tried this yet.
Thanks to ad...@flexiblelearning.com for replies to my other
questions.
On the memory cost of writing fld data to tVar
Q2. Of course it does, but the same condition is in
Sat, 30 Aug 2014 09:01:16 -0400
From: Geoff Canyon
This was my initial thought as well, but I didn't like having to work
line-by-line on (potentially) large sets of lines from the initial
not-duplicate set of permutations. Doing the dupes first is weirder
conceptually, but it means that
I have a set of code that seems to do the trick. It takes as an argument
the number of each element to permute. So for your examples:
On Mon, Sep 1, 2014 at 10:32 AM, Beat Cornaz b.cor...@gmx.net wrote:
On my computer :
Input : 1112223334568320 mSec
Input : 1233
On Mon, Sep 1, 2014 at 10:32 AM, Beat Cornaz b.cor...@gmx.net wrote:
This is my fastest script so far :
I think this is faster for many arguments. It might be slower for others. I
removed the dependency on an external routine for removing duplicates. It
also removes duplicates only when
On Sun, Aug 31, 2014 at 4:04 PM, Alex Tweedly a...@tweedly.net wrote:
I also added method4, which tries to get the best of both worlds. It
restricts the additional memory usage (by building up a second variable,
but removing sections of the input variable at the same time), and also
does
Some benchtesting...
Setup:
LC7DP10, Windows 7
Source data:
10,000 lines of random data
100 chars per line
3,346 empty lines
Task:
Strip lines where a given condition is met.
Results:
Method 1
Operating on a single variable, 'repeat with' + delete line
25.586
ad...@flexiblelearning.com compared 3 methods of stripping lines from a
variable, and concluded:
If memory is an issue, then Method 2 is best
If memory is not an issue, then Method 3 is best
3 questions:
1. Is there a good way to determine ahead of time whether memory is an issue?
When I
Method 2 doesn't have the filter, I am guessing the lack is a typo? Also,
I'd be interested in your results with the repeat for each method that
modifies tvar with the direct line deletion, though thinking about it,
(since i'm awake now) it wouldn't work unless it was modified. Something
like..
Thanks Hugh. I guess I'll be careful about where I use method 1 in
future!
I would expect method 1 to take longer but that's a huge difference. I
wonder if this would speed it up:
Put the number of lines in tVar into tCount
Repeat with x=tCount down to 1
Pete
lcSQL Software
On Aug 31, 2014 2
speed penalty (also, if they're weighted towards the end
of the data) Seems though, that hitting tDat using line numbers, whether
deleting, or changing, would have similar speed penalties. Also, if the
criteria is not too complicated (say, all items that are less than 40 as in
my example) perhaps
in tDeletions are static.
Won't it mess up the whole thing?
Regards,
Sri
--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/Speed-testing-Fastest-search-method-tp4682719p4682730.html
Sent from the Revolution - User mailing list archive at Nabble.com
rearranged dynamically after each
deletion,
whereas the line numbers contained in tDeletions are static.
Won't it mess up the whole thing?
Regards,
Sri
--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/Speed-testing-Fastest-search-method-tp4682719p4682730
Hi
Some benchtesting...
Task:
Strip lines where a given condition is met.
Have you tried the following method (condition is line empty) :
on mouseUp
set the cursor to watch
put the long seconds into tStart
put fld Data into tVar
repeat while tVar contains (return return)
- tStart into fld timer2
end mouseUp
Have I misunderstood that rule?
Many thanks.
David Epstein
From: Mike Bonner
Correct. My typo by omission.
Method 2 doesn't have the filter, I am guessing the lack is a typo?
From: Peter Haworth
1. Speed difference: 'for each' does
1. Is there a good way to determine ahead of time whether memory is an
issue? When I start the handler I can find out how big tVar is, but how do
I find out how much memory is available?
Could the function hasMemory(bytes) be of some help ?
Or perhaps heapSpace() on Mac OS systems ?
jbv
Hugh,
The condition you've chosen for deciding whether to delete the line is
whether or not the line is empty.
So in method 2, replacing those lines by has no effect on the data.
That is, I think, an inadequate benchmark. The primary cost you would
encounter in the real case with method 2
Sat, 30 Aug 2014 Geoff wrote :
Used Alex's code to generate a list of the permutations of all the characters
that were duplicates.
Substituted in unique characters for each instance of the duplicates.
Ran my permutation code on the rest of the characters, with the addition of
the
On Sat, Aug 30, 2014 at 7:24 AM, Beat Cornaz b.cor...@gmx.net wrote:
Sat, 30 Aug 2014 Geoff wrote :
Used Alex's code to generate a list of the permutations of all the
characters that were duplicates.
Substituted in unique characters for each instance of the duplicates.
Ran my
Gah -- now I'm not convinced that my way will work at all. I'll test and
reply later.
On Sat, Aug 30, 2014 at 8:19 AM, Geoff Canyon gcan...@gmail.com wrote:
On Sat, Aug 30, 2014 at 7:24 AM, Beat Cornaz b.cor...@gmx.net wrote:
Sat, 30 Aug 2014 Geoff wrote :
Used Alex's code to generate
On Wed, Aug 27, 2014 at 9:33 AM, Beat Cornaz b.cor...@gmx.net wrote:
So, getting rid of the duplicates inside the script is quite important. I
still don't see yet how I can do that in Geoff's script (I will look into
that again, as soon as I can find a little time). If we can get that to
Thanks Alex,
I will mail you off-list about the order of elements in the input and provide
some examples.
And thanks for the correction of your script. Seems to work fine now. I should
have seen that one myself, but it was a bit late last night, sorry :-)
Alex, you've explained the recursive
Thanks Peter,
your script works, but is in the same speed region as my original script, with
the added disadvantage that it can't go beyond 9 chars.
As for the duplicate elements : I did the same before - make all the possible
permutations and then delete the duplicate ones.
But as Geoff
On 27/08/2014 14:33, Beat Cornaz wrote:
So, getting rid of the duplicates inside the script is quite important. I still
don't see yet how I can do that in Geoff's script (I will look into that again,
as soon as I can find a little time). If we can get that to work, I think we'll
have a
Alex wrote :
To make it faster, it *should* be serialized, so that it isn't actually
recursive; that should be quite easy (but will make the code much less
easy to read or understand, so I haven't done it yet). If you think it's
worth pursuing, let me know and I'll have a go at unrolling
I'm going to reply 2 or 3 separate answers ... otherwise it will get
confusing :-)
Sorry if this overloads anyone trying to delete or ignore the thread
message by message.
On 27/08/2014 21:15, Beat Cornaz wrote:
As for the Duplicates :
Alex wrote :
permut() is the optimized version -
(second reply ..)
On 27/08/2014 21:15, Beat Cornaz wrote:
Alex wrote :
Recursive scripts is something I know in principle about, but never have used
them before. They are quite compact, but I find it hard to follow, especially
as your variables are emptied in each new entry into the script
On 27/08/2014 23:02, Alex Tweedly wrote:
I'll have a go at serializing this code - hopefully tonight (i.e.
starting now and not getting myself tied up in knots with it :-)
Here's a serialized version. Not as fast as I had hoped - it's about
twice as fst as the recursive vesion, but that
Works like a charm, Geoff. Great way of tackling the thing, very original.
function P2 N,B
-- N is the depth to permute
-- B is the ASCII value to start from
-- so P2(1,49) returns 21 cr 12
-- P2(2,53) returns 675 cr 765 cr 756 cr 576 cr 657 cr 567
if N = 0 then return numToChar(B) cr
On Aug 26, 2014, at 9:42 AM, Beat Cornaz wrote:
Works like a charm, Geoff. Great way of tackling the thing, very original.
function P2 N,B
-- N is the depth to permute
-- B is the ASCII value to start from
-- so P2(1,49) returns 21 cr 12
-- P2(2,53) returns 675 cr 765 cr 756 cr 576 cr
A followup on how to handle duplicate characters in the permuting algorithm.
The following seems to work, not sure how it will scale. tString can contain
any characters -- duplicates, digits, spaces, whatever.
function permute tString
-- returns all the permutations in the string tString
A tune-up on the earlier solution to listing permutations of a string.
Obviously, no need to load an array with the values of the characters, just use
char c of tString. Also, if tString contains duplicate letters then there
will be duplicate entries in the output, so those should be stripped
On Tue, Aug 26, 2014 at 1:57 PM, Peter M. Brigham pmb...@gmail.com wrote:
A followup on how to handle duplicate characters in the permuting
algorithm. The following seems to work, not sure how it will scale. tString
can contain any characters -- duplicates, digits, spaces, whatever.
I don't
James wrote :
There are significant differences in speed between 5.5 and 6.6. Not so much in
deriving the permutations as in displaying the results in a field.
I guess that's true. The values in millisecs that I have posted are taken
without putting the result into a field. Just the plain
). I will look into that later.
The fastest algorithm doesn't take into account the difference between
LiveCode's native C speed based on a single command vs. the much slower
execution of a substantial amount of transcript/livecode/whatever we call
the code in livecode these days. For example
On Mon, Aug 25, 2014 at 6:21 AM, Beat Cornaz b.cor...@gmx.net wrote:
But I think it quite a pity (to put it mildly) that LC 6.xx is so much
slower thank 5.5.
Could it be the unicode implementation? Agreed, that would be unfortunate.
It would be nice to have a text setting for fields.
setting for fields.
Not likely, as the just works Unicode implementation is only in v7.
Has anyone filed a bug report against this?
The speed difference is enough that it if fixed may help offset
performance degradation as a part of the Unicode implementation.
And since it predates the Unicode
But I think it quite a pity (to put it mildly) that LC 6.xx is so much
slower thank 5.5.
Geoff wrote :
Could it be the unicode implementation? Agreed, that would be unfortunate.
It would be nice to have a text setting for fields.
I talked about this just a couple of hours ago with my
a text setting for fields.
Richard wrote :
Not likely, as the just works Unicode implementation is only in v7.
Has anyone filed a bug report against this?
The speed difference is enough that it if fixed may help offset
performance degradation as a part of the Unicode implementation.
And since
Now for the permutations.
Geoff, great. Your script is by far the fastest. Almost 10 times faster than my
own script which comes second.
I could improve a little bit even on your script with the suggestion of Kay.
--
Kay wrote :
I obtained a 10% speed increase by changing this:
repeat with n
This routine will permute to any depth that memory/time allows. It has the
added benefit of using characters starting from any ASCII value you like,
allowing you to work around what you want to eventually permute using the
PLines routine.
It also has the speed benefit you get from using items
All right, the permutations. Thanks for the responses.
My findings so far :
Mark wrote :
--
In addition, you're losing much of the speed of the repeat for each
loops by embedding a repeat with loop at the deepest level (and in
addition you're making an unneccsary extra copy of tLine each time
There are significant differences in speed between 5.5 and 6.6. Not so much in
deriving the permutations as in displaying the results in a field.
To see this run this in the message box:
go url https://dl.dropboxusercontent.com/u/47044230/PermutationSpeed3.rev”
(Does this only work in LC 6
Sorry about that last post. Forgot to delete all message above Geoff’s.
Jim
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
On Aug 22, 2014, at 1:17 PM, Beat Cornaz b.cor...@gmx.net wrote:
So a good example would be how to make all possible permutations of say 10
different elements (0-9). This gives 3628800 different permutations.
The resulting permutations will be in lines I guess, but what would be the
best
On Aug 23, 2014, at 1:31 AM, Dick Kriesel dick.krie...@mail.com wrote:
putLine n things produce ( number of elements in
tCountForPermutation ) of \
oops. please replace putLine with put
___
use-livecode mailing list
I obtained a 10% speed increase by changing this:
repeat with n = 3 to 10
to this:
put 3,4,5,6,7,8,9,10 into nList
repeat for each item n in nList
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url
Beat Cornaz wrote:
I have some hundred fitness functions, which need to be recalculated
many times. But I think the problem of making Permutations might be
illuminating for me, as this one takes quite long to run (with 10 or
more elements to Permutate).
So a good example would be how to
This has several restrictions, but it generates all permutations of 10
items in about 6 seconds on my recent macbook. It uses two functions, one
to generate a permuted list of single digits, and the other to replace in
the actual items to be permuted.
The restrictions are:
1. The general
Thanks Richard,
So it depends on a number of factors, which makes it a bit harder. I had hoped
for some general rules, like always use repeat for if possible or words are
generally slower that items. But I understand, it depends on more things.
I have some hundred fitness functions, which need
On 22/08/2014 21:17, Beat Cornaz wrote:
At the moment I use :
--
function BC2_RemoveDuplicate_Lines pData
repeat for each line rLine in pData
add 1 to TestArray[rLine]
end repeat
return the keys of TestArray
end BC2_RemoveDuplicate_Lines
--
I hope someone
losing much of the speed of the repeat for each
loops by embedding a repeat with loop at the deepest level (and in
addition you're making an unneccsary extra copy of tLine each time
through the slowest loop):
repeat for each line tLine in TempPerms1
repeat with y = Index down to 1
put tLine
A while ago I did a test for speed with 'repeat for'. It turned out that with
items it worked the fasted. Chars were slower and words even more so.
Now I redid the test with 'LineOffset'. To my surprise: with chars was
considerably faster.
A long list with lines like 'aabcbcax' (chars
Systems
Software Design and Development for the Desktop, Mobile, and the Web
ambassa...@fourthworld.comhttp://www.FourthWorld.com
Beat Cornaz wrote:
A while ago I did a test for speed with 'repeat
Must have messed up somewhere.
repeatRate Seems OK now.
The speed is still sluggish though irrespective of the setting.
All the best
Terry
On 27 Feb 2014, at 21:27, Kay C Lan lan.kc.macm...@gmail.com wrote:
New stack, new btn:
on mouseUp
set the repeatRate to 20
end mouseUp
On Wed, Feb 26, 2014 at 5:05 PM, Terence Heaford
t.heaf...@btinternet.comwrote:
repeatRate is clearly working because if i raise it significantly
everything slows to a crawl but honestly
I can't notice much difference between 50 and 10 or 0 with my 1700
records.
Perhaps it's time to give
Out of interest when I close down LiveCode and reopen it
and in the message box type
put the repeatRate, it always comes back at 1 not 50.
Either the Language Guide is wrong and it is reset to 1 and not 50 or the
default setting has been
changed to 1 and not 50 and the Language Guide is
On Thu, Feb 27, 2014 at 11:01 PM, Terence Heaford
t.heaf...@btinternet.comwrote:
This assumes of course it is reset each time you close LC.
That's what happens on my machine: OS X 10.9.2, LC 6.5.2
New stack, new btn:
on mouseUp
set the repeatRate to 20
end mouseUp
Press the btn and in
:
Hi Terence,
This sounds more of a speed issue related to how often the scrolling is
fired while using page up/down rather than a general performance issue with
the data grid.
If you click on the data grid scrollbar and just drag from the top to
bottom does the data grid respond quickly
...@mangomultimedia.com wrote:
Hi Terence,
This sounds more of a speed issue related to how often the scrolling is
fired while using page up/down rather than a general performance issue
with
the data grid.
If you click on the data grid scrollbar and just drag from the top to
bottom does
Hi,
I have looked at modTableField but noted in the docs you can’t have right
alignment
unless I misread that would mean no decimal point alignment.
All the best
Terry
On 26 Feb 2014, at 17:23, Peter Haworth p...@lcsql.com wrote:
If you're looking for a ready-to-use table control, I will,
Hi Terence,
You're right, modTableField doesn't have a built-in way to right justify a
column. I hope one day LC implements right (and center) tabs.
I did come up with a workaround to right justify a column which seems to
work speedily. If you're interested email me off list and I'll send it to
script the data is scrolled through in ~12 seconds. What
(I think) this demonstrates is that the speed of scrolling isn't as much
the data grid as it is the frequency with which the LiveCode engine sends
the scrollbarDragged message.
In order to further confirm that it isn't the data grid holding
201 - 300 of 347 matches
Mail list logo
