>From the web site:
"Pro for Business
Get premium support when you need it, guidance with everything from coding,
debugging and deployment to app design and marketing, priority bug fixes and
quarterly members webinars with RunRev's CEO and LiveCode Product Manger. Be
smart in business, get Live
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 the global somewhere? If it wasn't
at the top of the script, then wherever you declare
On 2/16/2015 7:48 PM, Dr. Hawkins wrote:
It used to be
on prePreOpenStack
local prefsDir, prefsFilNam, newPrefsDb, prTabNams
local dcmd, theData, vtb
...
put "SELECT pref, pval FROM prefs" into dcmd
put revDataFromQuery(tab,vtb,prefsDb,dcmd) into prAry
split prAry by vtb and
You can have a card button that deletes the card if you make the button a group
background button. While you see the button on the card, it is not actually on
the card but behind the card and can be used to delete the card.
on mouseUp -- script on background group button
delete this card
end mo
Hey, silly question, but is there a way to do this..
sort lines of tWorking numeric by (--sCount) so that there is no actual
function call? (an in position, decrement sort of thing)
Just curious.
On Mon, Feb 16, 2015 at 8:25 PM, Jerry Jensen wrote:
> Good point. Besides being a good gener
Good point. Besides being a good general habit, it would be especially
important to make recursive functions private.
.Jerry
> On Feb 16, 2015, at 7:18 PM, Geoff Canyon wrote:
>
> It's important to note that the efficiency is all/mostly in the function
> call, not in the execution of the functi
It's important to note that the efficiency is all/mostly in the function
call, not in the execution of the function itself. So for really short
functions that will be called many times, this is significant. For longer
functions, the difference all but vanishes:
on mouseUp
put 1000 into n
--
RichardG wrote:
>
> I would imagine that a handler in the same
> script as the caller would be faster than having it just about any other
> place, but to limit its scope trims the execution time by a surprising
> amount.
>
Whoda thunk!
> I think my new habit is to declare everything as priva
On Mon, Feb 16, 2015 at 2:42 PM, Richmond
wrote:
> Now, for every new term a templet card is cloned and 2 fields on the
> cloned card are filled.
>
Bernd's solution is correct if you really want to create/delete cards. It
would be better/more scalable to just maintain a list of the information
a
On Feb 16, 2015, at 9:05 PM, Dr. Hawkins wrote:
> On Mon, Feb 16, 2015 at 3:08 PM, Alex Tweedly wrote:
>
>> That's not quite correct. It doesn't do a single initial complete scan of
>> the whole variable and keep all the pointers. What it does is (more like)
>> keep track of how far it has curre
Right. Back to the original version, a command, with referenced list.
-- Peter
Peter M. Brigham
pmb...@gmail.com
http://home.comcast.net/~pmbrig
On Feb 16, 2015, at 7:19 PM, Alex Tweedly wrote:
> You were right first time
>
> if you use a reference, then there is no copy created when you
On Mon, Feb 16, 2015 at 3:08 PM, Alex Tweedly wrote:
> That's not quite correct. It doesn't do a single initial complete scan of
> the whole variable and keep all the pointers. What it does is (more like)
> keep track of how far it has currently processed, and then when it needs
> the next line,
On Mon, Feb 16, 2015 at 3:55 PM, Bob Sneidar
wrote:
> The simple way to avoid that in the future is what many have suggested for
> the eons we have been posting on this list: Name your variables in such a
> way that they *cannot* conflict.
>
But that's not the problem here :)
Livecode just plai
On Mon, Feb 16, 2015 at 4:06 PM, Peter Haworth wrote:
> Certainly good to have naming conventions. Unfortunately, it doesn't
> prevent the infamous "name shadows another variable" compile error.
> Although I seem to be getting far fewer of those now I've moved to more
> recent LC versions.
>
>
I
On Mon, Feb 16, 2015 at 2:03 PM, J. Landman Gay
wrote:
> I'm still not sure what you saw. Maybe if you can post the handler and
> describe what happened again we will spot something.
It used to be
on prePreOpenStack
local prefsDir, prefsFilNam, newPrefsDb, prTabNams
local dcmd, theData,
You mention saving something in a property of the mainStack. So I assume you
are running this in the IDE not as a standalone, since the mainStack in a
standalone can't be changed and then saved? Or maybe I'm missing something?
-- Peter
Peter M. Brigham
pmb...@gmail.com
http://home.comcast.net/~
Hi Bernd,
> Am 17.02.2015 um 00:15 schrieb BNig :
> Hi Klaus,
> ...
>>> ---
>>> on mouseUp
>>> put the long id of this card into tLID
>>> send "delete tLID" to this stack in 0 milliseconds
>>> end mouseUp
>>>
>>> you don't need any handler anywhere. Just tested on LC 5.5, it
On February 16, 2015 5:04:40 PM CST, BNig wrote:
>funny, nobody likes "private"
>
>It save up to 20 % all else equal.
>
>On about 44000 lines 5 items on each line
>
>with private 86 ms, without 106 ms LC 6.7.2
>
>with private roughly 180 ms, without 200 ms on LC 7.0.2 rc2 (times vary
>much
>more
You were right first time
if you use a reference, then there is no copy created when you do the
call; and then you build up the output list.
without the reference, there is an initial copy and then you
additionally build the output list.
So using a reference parameter saves the memory
Certainly good to have naming conventions. Unfortunately, it doesn't
prevent the infamous "name shadows another variable" compile error.
Although I seem to be getting far fewer of those now I've moved to more
recent LC versions.
On Mon Feb 16 2015 at 3:55:51 PM Bob Sneidar
wrote:
> The simple w
Right, just saw that in the dictionary. But I'm still confused on why it
results in less messages. Is it because the engine checks to see if there
is a private handler before sending a message along the message path?
As Richard and Mark mentioned, seems like any handlers in an object's
script th
Richard-
Monday, February 16, 2015, 3:55:54 PM, you wrote:
> I think my new habit is to declare everything as private unless I know I
> need it available to other scripts.
Yeah, that's my normal MO anyway.
And for just that reason.
--
-Mark Wieder
ahsoftw...@gmail.com
This communication may
The simple way to avoid that in the future is what many have suggested for the
eons we have been posting on this list: Name your variables in such a way that
they *cannot* conflict. For instance, globals should start with a g as in
gFormApp. Local variables might start with an l (some say p but
Bernd wrote:
funny, nobody likes "private"
It save up to 20 % all else equal.
On about 44000 lines 5 items on each line
with private 86 ms, without 106 ms LC 6.7.2
with private roughly 180 ms, without 200 ms on LC 7.0.2 rc2 (times vary much
more on LC 7.0.2 rc2 than on LC 6.7.2
Ooooh, good
I forgot to mention that you can go to a stack as modal, so you can put all
these setup cards in a setup stack, then go to that stack modal (once it’s
debugged of course). That way script execution in the calling stack will be
suspended until you close the modal stack. My Database Merger stack w
What I do is I have setup cards. One for preferences, another for setting up
the database etc. In the card script of each setup card, I have a script local
variable, which when the stack is first opened will be empty. So in the
openstack handler in the mainstack, I lock the screen, then go to ea
Hi Pete,
Peter Haworth wrote
> That's very interesting. I've never used private since I had the
> impression that the only thing it did was stop the handler from being
> called outside of the script it appears in.
>
> But it seems there is a performance benefit too. Why would that be, I
> wond
If you are talking about a Bootcamp partition, they are NTFS and to the Mac OS
are read only. I am not sure what you are trying to accomplish.
Bob S
> On Feb 15, 2015, at 07:43 , Charles Szasz wrote:
>
> Bob,
>
> I saw your posting on Rev listserv. I got my windows code signing
> certifi
Terence Heaford
> A quick glance on the bug report system would indicate there are
> many many bugs not yet corrected.
>
> Is there a specific order in which the bugs get sorted or is it
> pot luck?
Jacque answered most of this really well. The only detail that may be
useful to add here is tha
That's very interesting. I've never used private since I had the
impression that the only thing it did was stop the handler from being
called outside of the script it appears in.
But it seems there is a performance benefit too. Why would that be, I
wonder. I understand that the engine only need
Hi Klaus,
Klaus major-k wrote
> Am 16.02.2015 um 22:00 schrieb BNig <
> bernd.niggemann@
> >:
>>
>> 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 m
Hi Jacque,
J. Landman Gay wrote
> This is getting to be just too much fun. I think Geoff was right, we
> don't need to initialize sNum because we don't care if we go into
> negative territory. And since the handler isn't actually using the value
> of the line, we can omit passing it by removin
On 16/02/2015 16:06, Bob Sneidar wrote:
The For Each form is also quite handy as it eliminates the need for stuffing
some variables in the process. As mentioned in past threads, the one downside
is that you *MUST* not change the contents of the source data (and I think the
each variable as wel
I wrote:
> I referenced the list and turned the function into a command, saves memory
> (possibly speed?) on very large lists.
I just realized that no memory is saved this way because we are building a new
duplicate (reversed) list within the command. So referencing the list has no
advantage.
So, Alex's way of doing it is the fastest pure-LC way (I didn't get into using
the database methods). I referenced the list and turned the function into a
command, saves memory (possibly speed?) on very large lists.
on reverseSort @pList, pDelim
-- reverse-sorts an arbitrary list
--ie,
On 2015-02-16 22:02, Mike Kerner wrote:
I don't think I follow on the first part. Edinburgh says that the
complexity of the two traversals are dramatically different. repeat
for
each is somewhere between nlogn and n, and repeat with is n^2. At
least
for the case of your squares of integers,
On 16/02/2015 21:15, Peter M. Brigham wrote:
As I now understand it, the really big difference is between the repeat for
n = 1 to… form on the one hand, and the repeat for each… and repeat n times
forms. The latter 2 are not that different, but when the engine has to
count lines/items every time,
This is getting to be just too much fun. I think Geoff was right, we
don't need to initialize sNum because we don't care if we go into
negative territory. And since the handler isn't actually using the value
of the line, we can omit passing it by removing "each". So it could be
even shorter/fas
I'm still not sure what you saw. Maybe if you can post the handler and
describe what happened again we will spot something.
On 2/16/2015 3:19 PM, Dr. Hawkins wrote:
On Mon, Feb 16, 2015 at 11:07 AM, J. Landman Gay
wrote:
Is the global declared at the top of the script? Are you trying to use
On 2/16/2015 3:02 PM, Mike Kerner wrote:
At least
for the case of your squares of integers, I would expect that there is a
crossover where it's going to be faster to build the list, first. I don't
know if that is at 100, 1000, or some bigger number, but n vs. n^2 is a
very big difference.
If y
Am 16.02.2015 um 22:00 schrieb BNig :
>
> 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
>
>
> you don't need any handler anywhere. Just
On Mon, Feb 16, 2015 at 11:07 AM, J. Landman Gay
wrote:
> Is the global declared at the top of the script? Are you trying to use a
> local variable in a handler with the same name as the global?
>
>
no & nope.
There is a single local variable declared outside of any scripts (to flag
initializati
Right. Simpler.
-- Peter
Peter M. Brigham
pmb...@gmail.com
http://home.comcast.net/~pmbrig
On Feb 16, 2015, at 4:00 PM, 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
As I now understand it, the really big difference is between the repeat for n =
1 to… form on the one hand, and the repeat for each… and repeat n times forms.
The latter 2 are not that different, but when the engine has to count
lines/items every time, it slows things down a very significant amo
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
you don't need any handler anywhere. Just tested on LC 5.5, it works :)
@ Dixie,
I don't claim I foun
I don't think I follow on the first part. Edinburgh says that the
complexity of the two traversals are dramatically different. repeat for
each is somewhere between nlogn and n, and repeat with is n^2. At least
for the case of your squares of integers, I would expect that there is a
crossover whe
You have to put the delete card handler in a higher level script in the message
path. For instance.
put this into the stack script:
on deleteMyCard cdID
delete card id cdID
end deleteMyCard
then put this into the button:
on mouseup
send ("deleteMyCard" && the short id of this card) to
Bernd...
You show us all up every time...:-)
Again, 'nice one!'...
Dixie
> Date: Mon, 16 Feb 2015 12:43:28 -0800
> From: bernd.niggem...@uni-wh.de
> To: use-revolut...@lists.runrev.com
> Subject: Re: Deleting cards from within themselves.
>
> Or even a bit easier
>
> ---
> on mouse
Or even a bit easier
---
on mouseUp
put the long id of this card into tLID
send "delete tLID" to this stack in 5 milliseconds
end mouseUp
---
see also on the forum
http://forums.livecode.com/viewtopic.php?f=7&t=22154&hilit=+delete+button#p114046
Kind regards
Be
in the stack script:
on delcd pCd
delete cd id pCd
end delcd
in the script of the btn of your card:
on mouseUp
send ("delcd" && the id of this cd) to this stack in 0
end mouseup
Best
Günter
Am 16.02.2015 um 20:42 schrieb Richmond:
This CANNOT be done, as such.
I am currently working
On 16/02/15 22:41, John Dixon wrote:
Richmond...
It is not 'nope!'.. Eric's suggestion is on the right track
put this into a stack script :-)
global cardNo
on getridofcard
delete card ID cardNo
end getridofcard
and this in the button, you were on about in each card :-
global cardNo
on m
Richmond...
It is not 'nope!'.. Eric's suggestion is on the right track
put this into a stack script :-)
global cardNo
on getridofcard
delete card ID cardNo
end getridofcard
and this in the button, you were on about in each card :-
global cardNo
on mouseUp
put the short id of this card
On 16/02/15 22:30, Eric Corbett wrote:
use
send "mouseUp" to btn "DELL" of card “INPUTTER” in 1 milliseconds
Nope!
On Feb 16, 2015, at 12:02 PM, Richmond wrote:
On 16/02/15 21:54, Roger Eller wrote:
try this:
click at the loc of btn "DELL" of card "INPUTTER"
~Roger
Thanks, but no j
On Feb 16, 2015, at 1:58 PM, BNig wrote:
> Hi Peter,
>
> you also might want to check your reverse algorithm on 7.x.x
Well, I'm still running 5.5.1, since I have a more than full-time job already
taking care of patients and I don't have time to debug 38,000 lines of script
for my practice mana
use
send "mouseUp" to btn "DELL" of card “INPUTTER” in 1 milliseconds
in the first mouseU
On Feb 16, 2015, at 12:02 PM, Richmond wrote:
> On 16/02/15 21:54, Roger Eller wrote:
>> try this:
>>
>> click at the loc of btn "DELL" of card "INPUTTER"
>>
>> ~Roger
>
> Thanks, but no joy: because
Thanks, Jim, for trying it.
A colleague also was successful with it playing correctly in the program.
I still don’t know why it wouldn’t play on my machine, even after a reboot of
LC and the computer.
But it is showing me that it is possible for a problem can be local to a user
for some reason
On 16/02/15 21:54, Roger Eller wrote:
try this:
click at the loc of btn "DELL" of card "INPUTTER"
~Roger
Thanks, but no joy: because that line still has to be inside a script in
an object on the card
to be deleted.
On Mon, Feb 16, 2015 at 2:42 PM, Richmond
wrote:
This CANNOT be done,
try this:
click at the loc of btn "DELL" of card "INPUTTER"
~Roger
On Mon, Feb 16, 2015 at 2:42 PM, Richmond
wrote:
> This CANNOT be done, as such.
>
> I am currently working up a moronically simple flashcard program for
> people to learn words in a new language.
>
> It features a card where
On 15/02/2015 02:28, Mike Kerner wrote:
I just read the dictionary entry (again), and I would say that it is not at
all clear that there would appear to be an ENORMOUS difference. For
starters, you have to read wy down to find the mention, it isn't
really called out with a NOTE or anythi
On 2/16/2015 1:45 PM, J. Landman Gay wrote:
The main importance is how severe the bug is, how difficult it will be
to fix, and, to some degree, how widespread the effect is.
I should also add, if there's a usable workaround, the bug isn't so
critical.
--
Jacqueline Landman Gay |
> PeterB wrote:
> I?m playing audio off a server in a player. I noticed just today that this
> file will only play the first 10 seconds or so and always stop in LC 6.1.3
> (uses QT) but play properly in Safari:
>
> http://artsinteractive.info//MITA/MITA_audio03/497-StraussR-Rosenkavalier-
On 2/16/2015 1:24 PM, Terence Heaford wrote:
Is there a specific order in which the bugs get sorted or is it pot luck?
The last I heard it was like this:
Crashers get first attention. Easy fixes that only need a tiny tweak are
often quickly implemented. After that it depends on what they're w
This CANNOT be done, as such.
I am currently working up a moronically simple flashcard program for
people to learn words in a new language.
It features a card where end-users can add terms.
Now, for every new term a templet card is cloned and 2 fields on the
cloned card are filled.
No rocket
A quick glance on the bug report system would indicate there are many many bugs
not yet corrected.
Is there a specific order in which the bugs get sorted or is it pot luck?
For example:
Do coding bugs come before user interface bugs or vice versa?
What is important to me may not be important t
On 2/16/2015 11:57 AM, Dr. Hawkins wrote:
Variable values were not getting set, even though they showed as set in
handlers.
In both cases, it turned out that I was modifying a globle variable that
hadn't been set in that handler.
Is the global declared at the top of the script? Are you trying
Hi Peter,
you also might want to check your reverse algorithm on 7.x.x
in my testing Jacque's initial post with little tweaks is as fast as your
code and faster on 7.x.x (tested on 7.0.2 rc2) In my testing it took only
60% of the time compared to yours on 7.x.x
Of course Alex Tweedly's ingenious
I've never seen *this* before, but I've been bitten by it twice this
morning in different stubstacks & handlers.
Variable values were not getting set, even though they showed as set in
handlers.
In both cases, it turned out that I was modifying a globle variable that
hadn't been set in that handl
Thanks to all RunRev staff for this build
However (and there is a however) bug 14295 still not fixed
Kind regards
Dave
-
"Some are born coders, some achieve coding, and some have coding thrust upon
them." - William Shakespeare & Hugh Senior
--
View this message in context:
http://runt
Anything new coming for Android? With Lollipop and material design getting
all the attention in the press, I am hoping we will see some new things in
LiveCode to target the updated OS features.
Roger EllerGraphics Systems Analyst
803 North Maple StreetP: 864.967.1625Simpsonville, SC 29681C: 86
According to LC, we're dealing with somewhere bewtween nlog(n) and n on the
one side and n^2 on the other, which is about as far apart as we can get.
On Mon, Feb 16, 2015 at 11:09 AM, Bob Sneidar
wrote:
> Ah. Because the keys of an array are effectively a system of pointers in
> themselves. It m
Ah. Because the keys of an array are effectively a system of pointers in
themselves. It might actually be slightly quicker, since the array has already
been created, while the For Each will have to create the pointers on the fly at
the start of the loop. I’d be curious to find out how much time
The For Each form is also quite handy as it eliminates the need for stuffing
some variables in the process. As mentioned in past threads, the one downside
is that you *MUST* not change the contents of the source data (and I think the
each variable as well) as doing so will corrupt what ends up i
Yes, but that part of the script already works. I have no problem deleting all
of the text in the combo box, as I have a special case to account for that.
Bob S
> On Feb 13, 2015, at 17:17 , Randy Hengst wrote:
>
> I'm not at my computer so this idea might just be worthless. Can the first
>
Hi all,
Our VDN special ends the end of today. Its 50% off VDN, our Oem'd server
that can be bundled with your solutions (there's a native VCLIENT for
pulling data from LiveCode). The server serves both data and reports.
http://valentina-db.com/en/valentina-developer-network-overview
Best regar
Well… technically, if all children have this opportunity, it’s not really a
head start. In fact, any child who doesn’t embrace the technology will be at a
disadvantage. I know. My sister Edith called me a couple days ago after I
installed a Typing Instruction program on the iMac she is using at
Dear List Members,
We're pleased to announce the release of LiveCode 6.7.2. This is a stable
release focusing on 64bit iOS apps as well as product robustness and
quality.
*Release Contents*
This release contains bug fixes and support for 64bit iOS binaries. For
full details of the changes in this
I am pleased to announce a free update for ChartMaker that is LC6.7 and LC7
compatible.
Full release notes and the new release download are available here,
including a free 30-day trial (or use your existing key to update):
http://www.flexiblelearning.com/chartmaker/versioning/whatsnew.htm
The d
77 matches
Mail list logo
