On 2/17/2015 6:25 PM, Bob Sneidar wrote:
on openStack
go card 2
go back
end openCard
I end up on card 2. Ideas??
I wonder if openStack doesn't push the first card onto the recentcards
list, since the card isn't technically open yet at that point. What
happens if you execute the sequence on
Ya know, simply turning off explicit variables for now allows you to move
forward with your project. Who knows, you might like it. ;-)
Bob S
On Feb 17, 2015, at 13:32 , J. Landman Gay
jac...@hyperactivesw.commailto:jac...@hyperactivesw.com wrote:
I wonder if globals are treated differently
I don't think I fully get that.
If the problem is that LC is just too slow, and the required
calculations continuously or consistently take more time than is elapsed
(i.e. we just keep getting further and further behind), then the problem
is performance, not how/when we can trigger redraws.
Okay I have positively isolated it to setting the height of the stack in an
openCard handler. That was the change I made today that borked the whole stack.
For whatever reason, going to a card, changing the height, and then going back
does something to the stack that prevents the card from
For this test, I realized I was causing a recursion problem.
Bob S
On Feb 17, 2015, at 18:40 , J. Landman Gay jac...@hyperactivesw.com wrote:
On 2/17/2015 6:25 PM, Bob Sneidar wrote:
on openStack
go card 2
go back
end openCard
I end up on card 2. Ideas??
I wonder if openStack
Yeah, looks like something broke with send in time. It’s clearly ignoring the
in argument, because attempting to delete the card at all when the send in time
is in a running script fails to delete the card, but deleting the card from the
message box works fine. If I were you, I’d file a bug
IOC nvm. Looks like that is how revExecuteSQL works. I can see now why I was
befuddled trying to get SQL to work in LC using their built in functions.
Bob S
On Feb 17, 2015, at 12:11 , Mike Kerner
mikeker...@roadrunner.commailto:mikeker...@roadrunner.com wrote:
Peter (Brett),
Help me with
On 2/17/2015 4:29 PM, Alex Tweedly wrote:
I am *absolutely* not recommending that anyone should modify the
variable in question within the loop - even if that seems to work in
some cases, it is known to be dangerous, and so should just NOT BE DONE
in real code. But doing it in limited cases
Something very odd has happened to my Livecode Install. The command Go Back no
longer works. Was working up until about a half hour ago. To test it I created
a new stack with two cards, each marked card 1 and card 2 respectively. In the
first card I have a handler in the card script
on
On 2/17/2015 7:43 PM, Richard Gaskin wrote:
Bob Sneidar wrote:
That should not be the case. Send in time means execute next idle
message plus time. If it doesn’t work with 0 seconds, that means
there is something triggering an Idle message before the script
is finished. The only other
On Tue, Feb 17, 2015 at 2:57 PM, Bob Sneidar bobsnei...@iotecdigital.com
wrote:
Ya know, simply turning off explicit variables for now allows you to move
forward with your project. Who knows, you might like it. ;-)
With my typing, that would be a bad idea (tm), Dr. Venkman . . .
I was able
On Tue, Feb 17, 2015 at 2:20 PM, Mike Kerner mikeker...@roadrunner.com
wrote:
I didn't include everything, including the transaction code, or opening the
database in memory instead of on a disk. When we were messing with this,
the piece that became the (58 minute) bottleneck was inside the
Try:
on openStack
go card 2
go back 1
end openCard
Eric
On Feb 17, 2015, at 4:25 PM, Bob Sneidar bobsnei...@iotecdigital.com wrote:
Something very odd has happened to my Livecode Install. The command Go Back
no longer works. Was working up until about a half hour ago. To test it I
created
Bob Sneidar wrote:
That should not be the case. Send in time means execute next idle
message plus time. If it doesn’t work with 0 seconds, that means
there is something triggering an Idle message before the script
is finished. The only other explanation is that the way we all
thought send
Well this is just crazy crap. If I step through the code it *sometimes* works.
Other times it fails. This is the “silent stop” issue some people were
complaining about, where script execution stops without any warning or alert.
It just stops. Even with debugging on, I get no indication that
Tiemo Hollmann:
Nowadays, with the new app paradigm on mobile phones and tablets the user
has forgotten that these nice tiny little icons on their smartphones are
also software with well-definied requirements and and investment to be
produced. And the OEMs like Apple with their automated
Hey Bob, it's not 4/1 yet, ya did reconcile yer on and end statements, right?
Sent from my iPhone
Bob S said
on openStack
go card 2
go back
end openCard
I end up on card 2. Ideas??
___
use-livecode mailing list
use-livecode@lists.runrev.com
On 18/02/15 00:52, Bob Sneidar wrote:
Yeah, looks like something broke with send in time. It’s clearly ignoring the
in argument, because attempting to delete the card at all when the send in time
is in a running script fails to delete the card, but deleting the card from the
message box works
NVM My whole LC installation crashes whenever I try to access a script of an
object. Probably preferences or a plugin.
Bob S
On Feb 17, 2015, at 08:48 , Bob Sneidar bobsnei...@iotecdigital.com wrote:
Hi all.
I think I’ve stumbled on a reliable way to crash LC 6.7.1. I search for
On Mon, Feb 16, 2015 at 10:14 PM, J. Landman Gay jac...@hyperactivesw.com
wrote:
It threw no error loading prAry, and it turned into the correct array.
Single step into the calling handler, and prAry and the global prAry was
gone.
This is correct behavior, at least when explicit variables
On Mon, Feb 16, 2015 at 10:16 PM, J. Landman Gay jac...@hyperactivesw.com
wrote:
On 2/16/2015 7:54 PM, Dr. Hawkins wrote:
Livecode just plain didn't catch that a variable was undeclared . . . had
it been declared as local, it would have been an error.
Hm. Are you saying you *did* declare
Hi all.
I think I’ve stumbled on a reliable way to crash LC 6.7.1. I search for (“form
in the find dialog with Script checked and This Stack File and it’s Stack Files
checked. I then double click on the first object that comes up. I get the watch
cursor but the script editor never shows. I
Hi Tiemo
I'm with you on this one when it comes to developing apps for clients.
I've recently started to specify that the app I will develop for them is
guaranteed to run on specific versions of particular platforms (I used to
just say it would be guaranteed to run on, for example, 'iOS').
Something very wrong happened to the Build 63 uploads yesterday. All the
fixes failed to stick... twice!
Build 64 has just been uploaded which should now work as expected. If you
have any problems, do please let me know.
This is truly embarrassing.
Hugh Senior
FLCo
Yesterday I wrote...
There
Tiemo,
I feel your pain. Apparently, Android development is very difficult because
many of the versions on different phone models have OS bugs and custom
configurations that can cause problems. If I were developing for Android, I
might specify that the software is only guaranteed on platforms
On Tue, Feb 17, 2015 at 11:55 AM, Dr. Hawkins doch...@gmail.com wrote:
Won't this be orders of magnitude slower?
Yes.
Given that you have access to lines, items, and words, if possible it would
be better to set the outer loop to work on lines, and then do whatever you
like with items within
On Mon, Feb 16, 2015 at 6:23 PM, Peter M. Brigham pmb...@gmail.com wrote:
No need to change the itemdel in a loop, you can use this instead:
put getItem(pList, pIndex, pDelim) into tItem
Won't this be orders of magnitude slower?
I can see the use in the general case, but Im ususally in
On Tue, Feb 17, 2015 at 9:01 AM, Geoff Canyon gcan...@gmail.com wrote:
Given that you have access to lines, items, and words, if possible it would
be better to set the outer loop to work on lines, and then do whatever you
like with items within the loop.
Most of the time, it is enough to set
If I am going to compile, then I will use a splash stack as the mainstack.
Bob S
On Feb 16, 2015, at 17:41 , Peter M. Brigham
pmb...@gmail.commailto:pmb...@gmail.com wrote:
You mention saving something in a property of the mainStack. So I assume you
are running this in the IDE not as a
I agree that additional features like SVG import or access to a phyiscs engine
would make things possible that are now not possible. In a similar vein,
multimedia problems like the slowness of using gifs for animated images, as
well as the general lack of movie format support could be addressed
Alex,
Thanks for that.
Disbelieving soul that I am (sorry), I puzzled for a while over the results of
these two versions.
on mouseup
put empty into msg
put abc CR def CR ghi CR into t
repeat for each line L in t
put the number of chars in L L CR after msg
Then past posts are incorrect on this matter. It was explicitly stated that the
actual memory holding the variable data was “indexed” and that altering the
variable data could relocate the variable in memory resulting in invalid data.
I have seen this myself. The data returned is garbled
The second is slow, because the current position is not tracked. So, for
line 1, its easy. You grab line 1. For line 2, you count the lines, until
you get to line 2. Same for line 3. Or think of it this way.. If you have
100 lines, and you are grabbing all of them using the second method, The
On 17/02/15 21:05, Bob Sneidar wrote:
That should not be the case. Send in time means execute next idle message plus
time. If it doesn’t work with 0 seconds, that means there is something
triggering an Idle message before the script is finished. The only other
explanation is that the way we
On 17/02/15 20:50, Richmond wrote:
On 16/02/15 23:00, BNig wrote:
Hi Peter,
the point is that in a button on a card
---
on mouseUp
put the long id of this card into tLID
send delete tLID to this stack in 0 milliseconds
end mouseUp
But, this was, indeed joyous:
A BIG, BIG 'Thank You' to all and everyone for their very great help
snowing me under with wonderful suggestions for this problem.
Confirming my opinion, yet again, that this Use-List and the LiveCode
community as a whole consists of a great bunch of people.
Love you lot, Richmond.
That should not be the case. Send in time means execute next idle message plus
time. If it doesn’t work with 0 seconds, that means there is something
triggering an Idle message before the script is finished. The only other
explanation is that the way we all thought send in time worked is not
I have always thought that the advice to reboot the computer to resolve a
problem with software was some kind of wild shotgun approach by first tier
technical support for no better reason than it was one of the steps on the
script they read from. I stand corrected. Rebooting my computer fixed
Yes, speed will be an issue if the data is thousands of lines. I'm usually
dealing with less than a thousand iterations, and taking a half-second or so to
do the job is nearly unnoticeable for the user.
-- Peter
Peter M. Brigham
pmb...@gmail.com
http://home.comcast.net/~pmbrig
On Feb 17,
On 16/02/15 23:00, BNig wrote:
Hi Peter,
the point is that in a button on a card
---
on mouseUp
put the long id of this card into tLID
send delete tLID to this stack in 0 milliseconds
end mouseUp
No joy with this one:
on mouseUp
answer Do you want to delete
Peter (Brett),
Help me with the chunking piece, then.
The following is very fast:
put INSERT INTO sortTest VALUES :1 into tSQL
repeat for each line tLine in tDataSet
revExecuteSQL dbid, tsql, tline
end repeat
The following is very slow:
put INSERT INTO sortTest VALUES :1 into tSQL
put the
It just seems odd to me that the chunking is so slow when done the second
way. Just for the heck of it, I did a SPLIT so as to work on an array, and
sure enough, it is just a little slower than the first technique (even
though there is the overhead involved with splitting the container into an
On 2/17/2015 2:11 PM, Mike Kerner wrote:
Help me with the chunking piece, then.
Put 100 apples in a box.
repeat with x = 1 to 100:
pick up one apple
drop it back in the box
pick up one apple
pick up a second apple
drop them both back into the box
pick up one apple
pick up a
On 2/17/2015 11:13 AM, Dr. Hawkins wrote:
The issue here seems to be that you had explicit variables turned on but
you didn't get a warning about the undeclared global variable.
Yes, that.
I wonder if globals are treated differently in the compiler. I don't use
explicit variables so I'm
On Tue, Feb 17, 2015 at 12:11 PM, Mike Kerner mikeker...@roadrunner.com
wrote:
The following is very fast:
put INSERT INTO sortTest VALUES :1 into tSQL
repeat for each line tLine in tDataSet
revExecuteSQL dbid, tsql, tline
end repeat
Faster still would probably be to build a command in
I didn't include everything, including the transaction code, or opening the
database in memory instead of on a disk. When we were messing with this,
the piece that became the (58 minute) bottleneck was inside the loop, or,
according to Peter, the way the chunks are accessed in the loop.
On Tue,
On 17/02/2015 15:43, Bob Sneidar wrote:
Then past posts are incorrect on this matter. It was explicitly stated that the
actual memory holding the variable data was “indexed” and that altering the
variable data could relocate the variable in memory resulting in invalid data.
I have seen this
On 17/02/2015 13:25, Dave Cragg wrote:
Alex,
Thanks for that.
Disbelieving soul that I am (sorry), I puzzled for a while over the results of
these two versions.
...
I had to use a pencil and paper to track what was in t and what the engine was referring to after
the x and y inserts. Then it
Or he could be just trying to initialise each time the program is loaded, in
which case things are fine.
Didn’t work for me of course, since I want to keep the data from the very first
activation (registration data, for example) in between activations - which is
what the Application Data
There was an error in the update issued yesterday afternoon. A replacement
was issued yesterday evening (UK time).
If you were quick off the mark yesterday, do please check you actually have
the most recent version! Open the Utility and click the Check for Updates
button, top right corner.
My
Priority bug fixes for Pro license holders means exactly that. If you report a
bug and you have a Pro license, that bug gets flagged as a priority. We still
apply rules of practicality to fixing such bugs, but if we can fix them in a
rapid timescale we will. This is one of the value adds of a
I am surprised that this is so OT, that anybody either cares about it or has
nothing to tell about.
Perhaps I am wracking my brain about something which doesn't even exist, or
only in German law?
Thanks anyway
Tiemo
-Ursprüngliche Nachricht-
Von: use-livecode
Just to say, that there is absolutely nothing wrong in using a modal stack to
stop the action until the user had done their input - I now see that for the
case I outlined, it’s the preferred way to go. What it does (apart from the
obvious grabbing of control and keeping a grip on it) is to
53 matches
Mail list logo
