Re: Don't ampute numberformat

[Mike Kerner via use-livecode]

Well, that would be a nice thing to have in a field widget, but I run into
formatting issues with databases, as well, especially when sorting.

On Sun, Apr 23, 2017 at 12:42 PM, Roland Huettmann via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I get around with numberformt, format() and own custom functions. But the
> discussion is interesting nevertheless, even when repeating.
>
> But it would be better to have consistent support throughout the IDE with
> one preferred method covering also international formatting edge cases.
>
> What I really would love to see are fields and lists (columns at least)
> where a field/column/cell has a formatting property similar to Excels cell
> formatting.
>
> It would make life much easier to simply set such property from predefined
> options. Or formats will be user-define manually or through script.
>
> 90% of overhead in formatting would be gone when entering or displaying
> data this way. And dependent on the field formatting, the engine would
> internally convert data types when addressing such field:
>
> "put 1000 into field 1" would render "$1,000.00" if the format property
> would have been set as such. And entering 1000 would format the field in
> the same way. Using such values in mathematical operations would be
> possible without the need to strip "$" and comma symbols or thousand
> seperators, the  engine would convert text to number automatically even for
> such formats.
>
> Only for the output or numbers/dates rendered as part of a text string,
> individual formatting of numbers/dates will still be needed sometimes.
>
> Roland
> ___
> 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: Don't amputate numberFormat (was: affecting array keys???)

[Curry Kenworthy via use-livecode]

Richard:

> With format(), you put something in and get something
> else out in one statement.

> With numberFormat, you first change an abstraction in
> the engine, then do something to a value elsewhere,
> and if you remembered to do it in the right order,
> and within a single handler, you'll get what you were
> looking for.

Ha ha, and that's precisely what I love about it, in addition to the 
intuitive representation and the great syntax!


In other words, the property acts a lot like a setting. Plenty of those 
in LiveCode. That's also intuitive, efficient the way I use them, and 
something that relates well to human experience, very easy to teach and 
learn. That's a strength in my book.


I forgot to add before that numberFormat seems to have the advantage on 
data type awareness. When you don't know about it, it works anyway, 
using the default when you concatenate. When you desire a different 
result and gain awareness, you can set it, and your concatenation code 
stays the same.


With format, you must have awareness from the start. Otherwise you're 
just concatenating stuff, and then the default has to cover for you. We 
could call that a tie, but I look at two other points. The default 
superficially looks like the way numberFormat works (the syntax is just 
concatenating with no functions) and LiveCode must have that built in 
anyway, unless it throws an error. Then you must change your 
concatenation code to include the function.


Bottom line is the "0.0" representation is just too intuitive to beat. 
Cognitive load theory or not, mark my words, that representation is 
going to blow away the competition in learning. That's obvious by being 
so much closer in form to the desired result. The closer things are, 
generally the less work required to bridge them. You can give it fancy 
names, but the underlying math will hold true regardless.


Using the property like a setting is an added plus, appealing and 
intuitive for many (I'd venture to guess most) people. Some others may 
prefer format. For them, it's there to use and no one is advocating that 
it be removed or deprecated. And even if a new property were added to 
control field display, it would probably act a lot like numberFormat.


But even that wouldn't replace the need for numberFormat itself. I think 
there are so many better priorities for LiveCode's "surgeons" than 
attacking the healthy tissue. There are still LC 8/9 bugs and so on that 
need attention, and having to intervene on behalf of this feature takes 
away a lot time from submitting those bug reports and maybe doing some 
promotions and such. This is one of the good parts of LiveCode! I hope 
people don't get dazzled by trends or self-destructive. I've seen that 
happen before. Good feature, realize the value of what you have and hang 
on to it.


Best wishes,

"Uber-Mega-Doctor" Curry Kenworthy
(Richmond, my check is in the mail! Don't be stingy with the gold lettering)

Custom Software Development
LiveCode Training and Consulting
http://curryk.com/consulting/

___
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: Stupid Q No 999: mergeBLE

[Richmond Mathewson via use-livecode]

" All of the addons have full documentation making it a joy to use them 
in your app."


Well I am unfortunately missing 2 things: "full" documentation 
(extremely minimal in the LC Documentation stack),

and the "joy": te second as a consequence of the first.

Richmond.

On 4/23/17 10:59 pm, Roger Eller via use-livecode wrote:

Have you looked at the mergBLE commands in the LC dictionary?

mergBLEConnectPeripheral pUUID

Monte will likely have the answers you seek.

~Roger


On Sun, Apr 23, 2017 at 6:38 AM, Richmond Mathewson via use-livecode <
use-livecode@lists.runrev.com> wrote:


So, here I am with Livecode 8.1.3 Indy (owing to the generosity of a
donor) which contains mergeBLE

I also own a floor-robot (Blue-Bot), know its UUID and have
complete documentation of commands accepted by the robot.

HOWEVER, I cannot for the life of me work out HOW one would do this sort
of thing (pseudoCode):

send "AA 03 81 11 04 67" to Bluebot

so the robot would move FORWARD 1 unit.

Richmond.
___
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

Legofied thistle

[hh via use-livecode]

In order to follow the current Lego-Hype of LC's advertising you may
create an own 'legofied' version of the thistle that thistles at
Thistle street NW, Edinburgh.
To have a playground for the little version-boys from LC's homepage...

http://forums.livecode.com/viewtopic.php?p=153583#p153583

___
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: Stupid Q No 999: mergeBLE

[Roger Eller via use-livecode]

Have you looked at the mergBLE commands in the LC dictionary?

mergBLEConnectPeripheral pUUID

Monte will likely have the answers you seek.

~Roger


On Sun, Apr 23, 2017 at 6:38 AM, Richmond Mathewson via use-livecode <
use-livecode@lists.runrev.com> wrote:

> So, here I am with Livecode 8.1.3 Indy (owing to the generosity of a
> donor) which contains mergeBLE
>
> I also own a floor-robot (Blue-Bot), know its UUID and have
> complete documentation of commands accepted by the robot.
>
> HOWEVER, I cannot for the life of me work out HOW one would do this sort
> of thing (pseudoCode):
>
> send "AA 03 81 11 04 67" to Bluebot
>
> so the robot would move FORWARD 1 unit.
>
> Richmond.
> ___
> 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: AW: Which code signing authority?

[Camm via use-livecode]

Second that !

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of tbodine via use-livecode
Sent: 21 April 2017 14:17
To: use-revolut...@lists.runrev.com
Cc: tbodine
Subject: Re: AW: Which code signing authority?

I've been using K Software's Comodo certs to sign Windows standalones and
installers for at least five years. The support provided by the owner of K
Software is quite good. (Example: http://certhelp.ksoftware.net/support/home
)

Tom B.



--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/Which-code-signing-authority-
tp4714079p4714101.html
Sent from the Revolution - User mailing list archive at Nabble.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

---
This email has been checked for viruses by AVG.
http://www.avg.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

Don't ampute numberformat

[Roland Huettmann via use-livecode]

I get around with numberformt, format() and own custom functions. But the
discussion is interesting nevertheless, even when repeating.

But it would be better to have consistent support throughout the IDE with
one preferred method covering also international formatting edge cases.

What I really would love to see are fields and lists (columns at least)
where a field/column/cell has a formatting property similar to Excels cell
formatting.

It would make life much easier to simply set such property from predefined
options. Or formats will be user-define manually or through script.

90% of overhead in formatting would be gone when entering or displaying
data this way. And dependent on the field formatting, the engine would
internally convert data types when addressing such field:

"put 1000 into field 1" would render "$1,000.00" if the format property
would have been set as such. And entering 1000 would format the field in
the same way. Using such values in mathematical operations would be
possible without the need to strip "$" and comma symbols or thousand
seperators, the  engine would convert text to number automatically even for
such formats.

Only for the output or numbers/dates rendered as part of a text string,
individual formatting of numbers/dates will still be needed sometimes.

Roland
___
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: Cognitive load

[jbv via use-livecode]

sorry I didn't have the time to go into details in my previous post,
but as for "a well-known fact" I was referring to decades of studies
in psychology and ergonomics.
This approach has nothing to with "reducing the human brain/mind to the
level of a binary computer", but rather with very specific and carefully
designed & reproductible tasks in which the amount of information processed
can be precisely measured.
Of course, individuals differ in their processing capacity, but (from the
top of my head) according to the above mentioned studies, the upper limit
seemed to be 7 bits/sec (again this doesn't mean that human brain = fancy
computer).
I also have several years of experience teaching programing to newbies of
very different ages & backgrounds (starting in 1980/81 with a Logo machine
and a class of kids aged 12/13), and the 3 "steps" I mentioned previously
(perhaps a better word could be used) were constantly present during my
teachings. These are not really successive "steps", as newbies have to
apprehend all of them simultaneously.
Last but not least, the concept of "workload" has been widely studied for
decades in psychology & ergonomics, as well as (long story short) the best
ways to organize & display information so that processing is reduced as
much as possible.
Several studies also showed that newbies tend to memorize algorithms in
a very specific language (the one they used), while experienced coders
tend to memorize algorithms "outside" of any specific language.
That's why a programing language close to the natural language is a huge
improvement, especially for newbies, for whom the necessary "workload" to
apprehend the language (the first "step") is reduced, saving some processing
capacity for the rest of the task.

On Sun, April 23, 2017 4:14 pm, Richmond Mathewson via use-livecode wrote:
> "a well-known fact"
>
>
> Actually this is a fairly subjective finding, and it is not
> a bad idea to work out the difference between a 'fact' (as in "this
> concrete is hard, as you will see if you hit it with your first") and
> widely held beliefs which may later prove to be erroneous.
>
> "Cognitive Load" is a theory, and NOT a collection of facts.
>
>
> https://en.wikipedia.org/wiki/Cognitive_load
>
>
> " Evidence has been found that individuals systematically differ in
> their processing capacity."
>
> So, while one might have a modal workload the categorical boundaries are
> had to define and largely unquantifiable.
>
> Smaller MAY, generally be better, but NOT always; this very much depends
> on the person who is working with something.
>
> There is a tendency to treat the human brain as a super-computer, but
> this is, in all probability, a confusion of kinds which may lead to a
> complete misreading of both how minds work and how computers work.
>
> "7 bits/sec"
>
>
> So, you would reduce the human brain/mind to the level of a binary
> computer: I wonder how those
> "bits" were measured.
>
>
> "so the less cognitive load is needed by step 1 above, the more remains
> available for the other steps..."
>
> Well that rests on an unproven presupposition that the human brain/mid
> works in steps (again because of the odd equation brain= fancy computer);
> while it may not; it may work holistically, assessing a whole situation
> all at once.
>
> I find that teaching children (7-14) LiveCode produces rapid results, as
> does teaching them BBC BASIC (they love my BBC Micro computer). Supposedly
> LiveCode should present less of a cognitive load
> than BASIC: well it would if the two methods of GETTING COMPUTERS TO DO
> SOMETHING allowed one to GET THE COMPUTERS TO DO
> THE SAME THING, but they don't,
> they are two totally different ways of interacting with computers that were
> developed at different historical periods for rather different jobs, so
> comparing them is probably a waste of time.
>
> Oddly enough, children generally find this exercise:
>
>
> Get the computer to produce a table of the first 10 digits, their
> squares and their cubes on-screen.
>
> considerably easier in BBC BASIC than in LiveCode. It generally takes them
> 5 to 10 minutes with BASIC,
> with LiveCode they find that the GUI "gets in the way".
>
> While (not oddly at all) they wouldn't know how to begin (and nor would
> I) how to do this with BASIC:
>
>
> Produce a blue square, 200 x 200 pixels, with a button titled "Press Me"
> in the middle.
>
> Mason, Cooper, et al. attempt 'Assessing Cognitive Load in Mobile App
> Development Environments' which is,
> after all, very much a subset of computer-programming.
>
> They compare 5 programming "environments" (I'm using those quotation
> marks to point out that they are NOT comparing GUI-based IDEs with more
> 'traditional' programming
> methods, such as BASIC) that all, to a lesser or greater extent provide the
> programmer with a toolbox of premade objects, thereby cutting out a very
> large part of any cognitive apprenticeship that has, historically been
> required to attain compe

Re: Cognitive load

[Richmond Mathewson via use-livecode]

On 4/23/17 6:01 pm, Keith Martin via use-livecode wrote:

On 23 Apr 2017, at 15:14, Richmond Mathewson via use-livecode wrote:


Until about 1600 is was a "well-known fact" that the world was flat


Heh. Nice analogy.
Except that even this fact itself isn't true!


Very few facts ultimately turn out to be true; face it, we live in a 
shaky universe.


Richmond.

Most educated people much further back than that believed that the 
Earth was round. Copernicus (1473-1543) didn't cause consternation 
through refuting the flatness of the world, he proposed that the world 
revolved around the sun rather than the other way around. And this 
wasn't the first time for that concept: Aristarchus of Samos (approx 
310-230 BC) originally presented the heliocentric concept, which 
relies inherently on the Earth being a sphere. In fact (uh-oh! ;) the 
flat-Earth idea has been only patchily believed for far longer than 
people generally realise.
Which makes it even more mind-numbingly strange that people think this 
today. But then, who in their right mind would look to a basketball 
player for scientific information?


:D

k


---

Keith Martin
Senior Lecturer, LCC (University of the Arts London)
President, http://IVRPA.org
http://PanoramaPhotographer.com
http://thatkeith.com
+44 (0)7909541365

---
___
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: Cognitive load

[Keith Martin via use-livecode]

On 23 Apr 2017, at 15:14, Richmond Mathewson via use-livecode wrote:


Until about 1600 is was a "well-known fact" that the world was flat


Heh. Nice analogy.
Except that even this fact itself isn't true! Most educated people much 
further back than that believed that the Earth was round. Copernicus 
(1473-1543) didn't cause consternation through refuting the flatness of 
the world, he proposed that the world revolved around the sun rather 
than the other way around. And this wasn't the first time for that 
concept: Aristarchus of Samos (approx 310-230 BC) originally presented 
the heliocentric concept, which relies inherently on the Earth being a 
sphere. In fact (uh-oh! ;) the flat-Earth idea has been only patchily 
believed for far longer than people generally realise.
Which makes it even more mind-numbingly strange that people think this 
today. But then, who in their right mind would look to a basketball 
player for scientific information?


:D

k


---

Keith Martin
Senior Lecturer, LCC (University of the Arts London)
President, http://IVRPA.org
http://PanoramaPhotographer.com
http://thatkeith.com
+44 (0)7909541365

---
___
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: Cognitive load

[Richmond Mathewson via use-livecode]

"a well-known fact"

Actually this is a fairly subjective finding, and it is not
a bad idea to work out the difference between a 'fact'
(as in "this concrete is hard, as you will see if you hit it with your 
first")

and widely held beliefs which may later prove to be erroneous.

"Cognitive Load" is a theory, and NOT a collection of facts.

https://en.wikipedia.org/wiki/Cognitive_load

" Evidence has been found that individuals systematically differ in 
their processing capacity."


So, while one might have a modal workload the categorical boundaries are 
had to define

and largely unquantifiable.

Smaller MAY, generally be better, but NOT always; this very much depends 
on the person who is working

with something.

There is a tendency to treat the human brain as a super-computer, but 
this is, in all probability, a confusion
of kinds which may lead to a complete misreading of both how minds work 
and how computers work.


"7 bits/sec"

So, you would reduce the human brain/mind to the level of a binary 
computer: I wonder how those

"bits" were measured.

"so the less cognitive load is needed by step 1 above, the more remains 
available for the other steps..."


Well that rests on an unproven presupposition that the human brain/mid 
works in steps (again because of the
odd equation brain= fancy computer); while it may not; it may work 
holistically, assessing a whole situation all at once.


I find that teaching children (7-14) LiveCode produces rapid results, as 
does teaching them BBC BASIC (they love my BBC Micro
computer). Supposedly LiveCode should present less of a cognitive load 
than BASIC: well it would if the two methods of
GETTING COMPUTERS TO DO SOMETHING allowed one to GET THE COMPUTERS TO DO 
THE SAME THING, but they don't,
they are two totally different ways of interacting with computers that 
were developed at different historical periods for

rather different jobs, so comparing them is probably a waste of time.

Oddly enough, children generally find this exercise:

Get the computer to produce a table of the first 10 digits, their 
squares and their cubes on-screen.


considerably easier in BBC BASIC than in LiveCode. It generally takes 
them 5 to 10 minutes with BASIC,

with LiveCode they find that the GUI "gets in the way".

While (not oddly at all) they wouldn't know how to begin (and nor would 
I) how to do this with BASIC:


Produce a blue square, 200 x 200 pixels, with a button titled "Press Me" 
in the middle.


Mason, Cooper, et al. attempt 'Assessing Cognitive Load in Mobile App 
Development Environments' which is,

after all, very much a subset of computer-programming.

They compare 5 programming "environments" (I'm using those quotation 
marks to point out that they are
NOT comparing GUI-based IDEs with more 'traditional' programming 
methods, such as BASIC) that all, to a lesser or greater
extent provide the programmer with a toolbox of premade objects, thereby 
cutting out a very large part of any cognitive
apprenticeship that has, historically been required to attain competence 
in programming.


I would argue that LiveCode, at least, does require quite a bit of 
cognitive effort, at least at the start,
for programmers to understand how each of the premade controls/objects 
functions, and how each of them
can be addressed to do what the end-user wants them to do. While 
LiveCode allows programmers to bypass
a lot of 'stuff' that PASCAL. C++ and so on require a programmer to 
know, it presents them with another
lot of 'stuff' which they have to know instead. The only thing that may 
make LiveCode easier to acquire some
initial level of competence in is that the object-oriented visual 
metaphor adopted by LiveCode is, in some ways, nearer
to the real world that what other, more traditional programming 
languages present.


However, you will notice that I "argue", I don't present my subjective 
experience working with school children as

'facts'.

Until about 1600 is was a "well-known fact" that the world was flat: but 
I have a funny feeling that it wasn't and
that the world did not suddenly change shape when people started 
believing it was vaguely spherical. Now that
people have gone up into space with rockets and taken photos of the 
earth the argument seems to be over whether
the world "is" a sphere or an "oblate spheroid", and only nutty 
fruitcakes believe otherwise:


https://www.tfes.org/

"So, Listen, I drive from coast to coast, and this shit is flat to me." 
Dr. Shaquille O'Neal.


Anyone else wanting a doctorate can mail me $100 to the usual address 
and with a week they will recieve a doctoral diploma

lovingly printed out from my laser printer :)

Well, I enjoyed myself this weeked; hope you all did :)

Richmond.

On 4/23/17 3:36 pm, jbv via use-livecode wrote:

On Sun, April 23, 2017 9:55 am, Richmond Mathewson via use-livecode wrote:

I'm not sure why smaller should necessarily be better.


It is actually, and the cognitive load approach, especially for
program

Re: Cognitive load

[jbv via use-livecode]

On Sun, April 23, 2017 9:55 am, Richmond Mathewson via use-livecode wrote:
> I'm not sure why smaller should necessarily be better.
>

It is actually, and the cognitive load approach, especially for
programmers newbies, is quite relevant.
Newbies have to deal with 2 or 3 things simultaneously :
1- the language itself
2- the programming "rules" (variables, loops...)
3- the program itself they're attempting to write.

It is a well-known fact that the workload that human minds can
process per unit of time is limited (AFAIR 7 bits/sec), so the
less cognitive load is needed by step 1 above, the more remains
available for the other steps...


___
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: Browser widget

[Klaus major-k via use-livecode]

Hi John,

> Am 23.04.2017 um 14:02 schrieb John Dixon via use-livecode 
> :
> 
> Are there any messages than can be used with the browser 'widget', so that 
> you could know when the URL has finished loading, for example ?

sure, e.g. -> browserNavigateComplete tUrl

Check the dictionary for more info about available browser widget 
commands/functions.
Open the dictionary and select "Browser" in the popup "Choose API..." on the 
top left there.

> dixie

Best

Klaus

--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
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: Cognitive load

[Richmond Mathewson via use-livecode]

On 4/23/17 2:59 pm, Keith Martin via use-livecode wrote:

On 23 Apr 2017, at 8:55, Richmond Mathewson via use-livecode wrote:


I'm not sure why smaller should necessarily be better.

Surely a better equation might be how much one gets out for what one 
puts in.


Well, that would be *another* measurement – related but not the same. 
Even harder to measure, I'm sure. The cognitive load of a menu-driven 
scripting system such as early versions of Flash was very low indeed 
(despite being rooted in an animation timeline concept) – but it was 
itself very limited. I think it's good that this Southern Cross U 
comparison didn't go beyond a set of actual application development 
tools.


I find the idea of cognitive load measurement extremely interesting. 
If something's Just Damn Tough to learn it's simply less accessible. 
It's the broad accessibility of xTalk that I have always found so 
exciting, from my HyperCard 1.x and SuperCard 1.x days onwards... and 
it's the relative Just Damn Tough-ness of Objective C that made me 
bail on my attempts to learn it a few years back. The cognitive load 
was too much for me. :-/


Personally the Damn Tough-ness of just about everything apart from 
LiveCode is making me worry about my cognitive capacity.


Richmond.


k


---

Keith Martin
Senior Lecturer, LCC (University of the Arts London)
President, http://IVRPA.org
http://PanoramaPhotographer.com
http://thatkeith.com
+44 (0)7909541365

---
___
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: Browser widget

[hh via use-livecode]

Yes, see

Dict:API:Browser
or
tinyDict:Dicts:Browser

___
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

Browser widget

[John Dixon via use-livecode]

Are there any messages than can be used with the browser 'widget', so that you 
could know when the URL has finished loading, for example ?


dixie
___
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: Cognitive load

[Keith Martin via use-livecode]

On 23 Apr 2017, at 8:55, Richmond Mathewson via use-livecode wrote:


I'm not sure why smaller should necessarily be better.

Surely a better equation might be how much one gets out for what one 
puts in.


Well, that would be *another* measurement – related but not the same. 
Even harder to measure, I'm sure. The cognitive load of a menu-driven 
scripting system such as early versions of Flash was very low indeed 
(despite being rooted in an animation timeline concept) – but it was 
itself very limited. I think it's good that this Southern Cross U 
comparison didn't go beyond a set of actual application development 
tools.


I find the idea of cognitive load measurement extremely interesting. If 
something's Just Damn Tough to learn it's simply less accessible. It's 
the broad accessibility of xTalk that I have always found so exciting, 
from my HyperCard 1.x and SuperCard 1.x days onwards... and it's the 
relative Just Damn Tough-ness of Objective C that made me bail on my 
attempts to learn it a few years back. The cognitive load was too much 
for me. :-/


k


---

Keith Martin
Senior Lecturer, LCC (University of the Arts London)
President, http://IVRPA.org
http://PanoramaPhotographer.com
http://thatkeith.com
+44 (0)7909541365

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

Stupid Q No 999: mergeBLE

[Richmond Mathewson via use-livecode]

So, here I am with Livecode 8.1.3 Indy (owing to the generosity of a 
donor) which contains mergeBLE


I also own a floor-robot (Blue-Bot), know its UUID and have
complete documentation of commands accepted by the robot.

HOWEVER, I cannot for the life of me work out HOW one would do this sort 
of thing (pseudoCode):


send "AA 03 81 11 04 67" to Bluebot

so the robot would move FORWARD 1 unit.

Richmond.
___
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: How many words from start of text to my selection

[Mark Schonewille via use-livecode]

HYi Kaveh,

LiveCode sets the focus to the clicked object after running the scripts. 
If I would select text the normal way, the selection would be deselected 
again, because the focus would go away from the field to the button 
containing the script. Using the send in time command, I make sure that 
this command is executed after LiveCode completes its routines, also 
after LiveCode sets the focus.


If you use a different way to execute the script rather then from a 
button or other object that is activated by a click, you won't need this 
last line.


Moreover, sometimes I have this problem and sometimes not. I haven't 
figured out why. At least, when it occurs, there is a way to solve it.


Kind regards,

Mark Schonewille
http://economy-x-talk.com
https://www.facebook.com/marksch

Buy the most extensive book on the
LiveCode language:
http://livecodebeginner.economy-x-talk.com

Op 22-Apr-17 om 16:05 schreef Kaveh Bazargan:

Wonderful :-)

Can you give me a hint of this line please:

send "select word" && myChunk && "of fld 1" to me in 0 millisecs

Why not just

select word" && myChunk && "of fld 1"

On 22 April 2017 at 12:33, Mark Schonewille via use-livecode <
use-livecode@lists.runrev.com> wrote:


This tells you the number of the selected word:

on mouseUp
   put the selectedChunk into myChunk
   put word 4 of myChunk into myChunk
   put the number of words of char 1 to myChunk of fld 1
   send "select word" && myChunk && "of fld 1" to me in 0 millisecs
end mouseUp

Kind regards,

Mark Schonewille
http://economy-x-talk.com
https://www.facebook.com/marksch

Buy the most extensive book on the
LiveCode language:
http://livecodebeginner.economy-x-talk.com

Op 22-Apr-17 om 13:18 schreef Kaveh Bazargan via use-livecode:


I have selected some text in a field. I want to convert that to "word xxx
of fld yyy". Any hints on how I do that?



___
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: Cognitive load

[Richmond Mathewson via use-livecode]

I'm not sure why smaller should necessarily be better.

Surely a better equation might be how much one gets out for what one 
puts in.


Another consideration is how many transferrable skills one learns during 
any one cognitive apprenticeship.


Richmond.

On 4/23/17 2:29 am, Mike Kerner via use-livecode wrote:

So I assume that smaller is better

On Sat, Apr 22, 2017 at 1:36 PM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:


Since cognitive load came up in the other thread about numberFormat, some
of you may find this paper very interesting:


Using Cognitive Load Theory to select an Environment for Teaching
Mobile Apps Development

Raina Mason, Southern Cross University
Graham Cooper, Southern Cross University
Simon, University of Newcastle
Barry Wilks, Southern Cross University

Abstract

After considering a number of environments for the development of apps for
mobile devices, we have evaluated five in terms of their suitability for
students early in their programing study. For some of the evaluation we
devised an evaluation scheme based on the  principles of cognitive load
theory to assess the relative ease or difficulty of learning and using each
environment. After briefly presenting the scheme, we discuss our results,
including our findings about which mobile apps development environments
appear to show most promise for early-level programming students.


Excerpt
---
The computed averages are as follows:

TouchDevelop: 16%
LiveCode: 17%
App Inventor: 33%
Xamarin: 59%
Visual Studio: 65%
...
The mobile development environments that we evaluated fell clearly into
three groups. TouchDevelop and LiveCode, with threshold scores of less than
20%,  permitted the development of code with the least relative cognitive
load. Despite the fact that it was designed for, and is typically used for,
novice programmers, App Inventor had double the threshold score of these
two environments, indicating a substantially higher relative cognitive
load. Both Visual Studio and Xamarin Studio had threshold scores of around
60%, nearly double again, indicating another substantial leap in the
relative cognitive load required to develop mobile apps in these
environments.





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

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






___
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