date:20170626

No judgment from me on this. On the contrary, most development mixes 
languages from time to time, and I think it can be instructive to 
observe where the dividing lines of natural usage are found.


So I was kidding, of course, in referring to LC as a "JavaScript 
packaging tool", but maybe only somewhat:


Where we find ourselves using JavaScript to cover for something that's 
hard to do in LC -- and vice versa, where we prefer doing something in 
LiveCode because it's hard to do in JavaScript -- we may learn something 
about the sweet spot of each.


--
 Richard Gaskin
 Fourth World Systems


jonathandlynch wrote:


I am not trying to start a fuss - just find solutions for my particular problem.

This is what worked for me for this situation.

For situations where LC provides a full solution, it is MUCH faster to code in.

Sent from my iPhone


On Jun 26, 2017, at 9:56 PM, Roger Eller wrote:

On Jun 26, 2017 9:36 PM, "Richard Gaskin wrote:

With all the interest lately in bypassing the LC language to use an

embedded browser process, maybe we've found the winning slogan for LC:


"LiveCode: a great JavaScript packaging tool"

:)

--
Richard Gaskin
Fourth World Systems


-1

NOT my 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

GLX apps and 8.15

2017-06-26 Thread james--- via use-livecode

Hi, just decided to return to a project after a few months and launched it in 
8.15rc2.
It bombed out into the debugger after launching the main stackfile.
The error is thrown from the glxapp_framework stack.
"on preopencard" to be exact.
After playing around it seems this handler throws an error whenever I change 
cards so it is not to do with a specific card but the window management in the 
GLX framework.
I tried this in both Indy and business version.
Before pulling my hair out as I tried to work out what I had done wrong I 
thought I would try previous builds of my app. Ones that I know worked before.
These too gave the same error.
So I tried previous LC releases.
The error only occurs in LC8.15rc1 or rc2.
LC8.14 works fine and the error is not thrown.

So something seems to have changed between 8.14 and 8.15 which is not liked by 
the GLX framework.

Has anyone else had this?
If so, have you fixed it?

James

___
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 do we access the clipboard on mobile devices?

I am not trying to start a fuss - just find solutions for my particular problem.

This is what worked for me for this situation.

For situations where LC provides a full solution, it is MUCH faster to code in.

Sent from my iPhone

> On Jun 26, 2017, at 9:56 PM, Roger Eller via use-livecode 
>  wrote:
> 
> On Jun 26, 2017 9:36 PM, "Richard Gaskin via use-livecode" <
> use-livecode@lists.runrev.com> wrote:
>> 
>> With all the interest lately in bypassing the LC language to use an
> embedded browser process, maybe we've found the winning slogan for LC:
>> 
>> "LiveCode: a great JavaScript packaging tool"
>> 
>> :)
>> 
>> --
>> Richard Gaskin
>> Fourth World Systems
>> Software Design and Development for the Desktop, Mobile, and the Web
>> 
>> ambassa...@fourthworld.comhttp://www.FourthWorld.com
>> 
> 
> -1
> 
> NOT my LiveCode!
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

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

Re: How do we access the clipboard on mobile devices?

2017-06-26 Thread Roger Eller via use-livecode

On Jun 26, 2017 9:36 PM, "Richard Gaskin via use-livecode" <
use-livecode@lists.runrev.com> wrote:
>
> With all the interest lately in bypassing the LC language to use an
embedded browser process, maybe we've found the winning slogan for LC:
>
> "LiveCode: a great JavaScript packaging tool"
>
> :)
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com
>

-1

NOT my 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: How do we access the clipboard on mobile devices?


jonathandlynch wrote:
> I just modified the texting part of Augmented Earth to use a browser
> widget for texting - it was a huge pain. But - now it has inertial
> scrolling, copy and paste, and works fine with all of the emojis.
>
> I might wind up going that route on other text entry stuff. It is
> clean and smooth that way.

With all the interest lately in bypassing the LC language to use an 
embedded browser process, maybe we've found the winning slogan for LC:


"LiveCode: a great JavaScript packaging tool"

:)

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

Re: How do we access the clipboard on mobile devices?

And the iPhone speech to text works this way too!

Sent from my iPhone

> On Jun 26, 2017, at 9:21 PM, jonathandly...@gmail.com wrote:
> 
> I just modified the texting part of Augmented Earth to use a browser widget 
> for texting - it was a huge pain. But - now it has inertial scrolling, copy 
> and paste, and works fine with all of the emojis.
> 
> I might wind up going that route on other text entry stuff. It is clean and 
> smooth that way.
> 
> 
> 
> 
> Sent from my iPhone
> 
>> On Jun 26, 2017, at 3:30 PM, jonathandly...@gmail.com wrote:
>> 
>> For this case, though, it will have to be called up specially, not made to 
>> look like it was already there.
>> 
>> The field in question also allows users to put in images - something I don't 
>> think native fields can do. So the app would have an enter text button that 
>> calls up the native field, where the user can type or paste text that is 
>> then inserted into the LC field.
>> 
>> Sent from my iPhone
>> 
>>> On Jun 26, 2017, at 3:21 PM, Dave Kilroy via use-livecode 
>>>  wrote:
>>> 
>>> OK good, the visible bits of a native field (border, background colour etc) 
>>> could all be provided by background graphics so when you switch fields no 
>>> visible change can be seen - you might even be able to use the 
>>> inputTextChanged message instead of a button which the user has to press
>>> 
>>> BTW you’ll have to delete the native field instead of just hiding it as 
>>> it’ll be in the top layer and could interfere with user interactions…
>>> 
>>> Dave
>>> 
>>> 
 Hi Dave - I think that might help 
 
 I could give the user a button for opening up a pastable field. They could 
 paste into that and LC could process it and put it into the regular field. 
 It's not a bad idea. 
>>> ___
>>> 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: How do we access the clipboard on mobile devices?

I just modified the texting part of Augmented Earth to use a browser widget for 
texting - it was a huge pain. But - now it has inertial scrolling, copy and 
paste, and works fine with all of the emojis.

I might wind up going that route on other text entry stuff. It is clean and 
smooth that way.




Sent from my iPhone

> On Jun 26, 2017, at 3:30 PM, jonathandly...@gmail.com wrote:
> 
> For this case, though, it will have to be called up specially, not made to 
> look like it was already there.
> 
> The field in question also allows users to put in images - something I don't 
> think native fields can do. So the app would have an enter text button that 
> calls up the native field, where the user can type or paste text that is then 
> inserted into the LC field.
> 
> Sent from my iPhone
> 
>> On Jun 26, 2017, at 3:21 PM, Dave Kilroy via use-livecode 
>>  wrote:
>> 
>> OK good, the visible bits of a native field (border, background colour etc) 
>> could all be provided by background graphics so when you switch fields no 
>> visible change can be seen - you might even be able to use the 
>> inputTextChanged message instead of a button which the user has to press
>> 
>> BTW you’ll have to delete the native field instead of just hiding it as 
>> it’ll be in the top layer and could interfere with user interactions…
>> 
>> Dave
>> 
>> 
>>> Hi Dave - I think that might help 
>>> 
>>> I could give the user a button for opening up a pastable field. They could 
>>> paste into that and LC could process it and put it into the regular field. 
>>> It's not a bad idea. 
>> ___
>> 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: synonyms

2017-06-26 Thread Mike Kerner via use-livecode

Synonyms are one of the things that make this language special.  I
appreciate the fact that my creativity is not interrupted by imposed style
and syntactic requirements as much as it is with other languages.  I
appreciate that I don't have to type containers in most cases, and I don't
have to worry about case sensitivity.  I can go on and on, but Mark, there
are lots of languages built with the compiler author in mind.  I hope LC
will remain off that list.
___
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: synonyms

2017-06-26 Thread Jim Lambert via use-livecode

OOOPS! I left out an important word

Then simply set the icon of each to the ID of the appropriate image.

should read

Then simply set the icon of each BUTTON to the ID of the appropriate image.

JimL

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

2017-06-26 Thread Jim Lambert via use-livecode

> BobS wrote:
> 
> For the record, I have given up on my Object Library. The problem is buttons. 
> Button can have icons. That means that I would need to copy all the linked 
> icons along with the button, then manage the relinking of the copied icons 
> that now have their own ID's, then manage dropping the icons BACK onto 
> another card, but only if another icon of the same name does not exist, blah 
> blah blah. YUK! 
> 
> What is needed is for the engine to allow a BUTTON to dynamically be linked 
> to a grapic ON DISK without having to import a graphic object 

Bob,

I may completely misunderstand the issue.  But can’t you have an unseen card 
with all the icons as image objects referencing image files ON DISK.
Then simply set the icon of each to the ID of the appropriate image.

For example,

create a new image
set its filename to “some>path/hand_icon.jpg”
   set the icon of button “hand” to the ID 1003
where 1003 is the id of the referenced image.

In this way there is no ‘copying’, ‘importing’ or ‘relinking’ needed.

And if you don’t want to deal with remembering IDs just name the new image, say 
“hand_icon’ then

  set the icon of button “hand” to the ID of image “hand_icon” 
(optionally - "of card ‘myIcons’")

Jim Lambert
___
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: Levure wiki / documentation

2017-06-26 Thread Trevor DeVore via use-livecode

And what Monte said too :-)

-- 
Trevor DeVore
ScreenSteps
www.screensteps.com

On Mon, Jun 26, 2017 at 6:41 PM, Monte Goulding via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Contributing to a GitHub wiki is probably not your best introduction to
> git if the wiki is restricted to collaborators only and you aren’t one so I
> would just open issues at this stage if I were you.
>
> Cheers
>
> Monte
>
> > On 27 Jun 2017, at 9:13 am, Alex Tweedly via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > I've got as far as building my app with within the framework, and
> reading much of the docs.
> >
> > I've found some things that I believe should change in the wiki - both
> >
> > - just obvious bugs / typos / cleanup
> >
> > and
> >
> > - things I think I know how to correct, but not 100% sure, and would
> like confirmation to be sure I am understanding properly.
> >
> > As a git/github newbie - how do I go about suggesting changes to the
> docs ?
> >
> > Thanks
> >
> > Alex.
> >
> >
> >
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
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: Levure wiki / documentation

2017-06-26 Thread Trevor DeVore via use-livecode

What Andre said. Here is the link to the issue page:

https://github.com/trevordevore/levure/issues

-- 
Trevor DeVore
ScreenSteps
www.screensteps.com

On Mon, Jun 26, 2017 at 6:20 PM, Andre Garzia via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Alex,
>
> I am not Trevor so he may suggest something different but usually when
> dealing with github hosted projects, we use the issue system available on
> each repository. Ideally, you submit a new issue per "thing" instead of
> doing a single new issue with many things inside.
>
> Cheers
> andre
>
> On Mon, Jun 26, 2017 at 8:13 PM, Alex Tweedly via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > I've got as far as building my app with within the framework, and reading
> > much of the docs.
> >
> > I've found some things that I believe should change in the wiki - both
> >
> >  - just obvious bugs / typos / cleanup
> >
> > and
> >
> >  - things I think I know how to correct, but not 100% sure, and would
> like
> > confirmation to be sure I am understanding properly.
> >
> > As a git/github newbie - how do I go about suggesting changes to the
> docs ?
> >
> > Thanks
> >
> > Alex.
> >
> >
> >
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
>
>
>
> --
> http://www.andregarzia.com -- All We Do Is Code.
> http://fon.nu -- minimalist url shortening service.
> ___
> 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: Levure wiki / documentation

2017-06-26 Thread Monte Goulding via use-livecode

Contributing to a GitHub wiki is probably not your best introduction to git if 
the wiki is restricted to collaborators only and you aren’t one so I would just 
open issues at this stage if I were you.

Cheers

Monte

> On 27 Jun 2017, at 9:13 am, Alex Tweedly via use-livecode 
>  wrote:
> 
> I've got as far as building my app with within the framework, and reading 
> much of the docs.
> 
> I've found some things that I believe should change in the wiki - both
> 
> - just obvious bugs / typos / cleanup
> 
> and
> 
> - things I think I know how to correct, but not 100% sure, and would like 
> confirmation to be sure I am understanding properly.
> 
> As a git/github newbie - how do I go about suggesting changes to the docs ?
> 
> Thanks
> 
> Alex.
> 
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: Levure wiki / documentation

2017-06-26 Thread Andre Garzia via use-livecode

Alex,

I am not Trevor so he may suggest something different but usually when
dealing with github hosted projects, we use the issue system available on
each repository. Ideally, you submit a new issue per "thing" instead of
doing a single new issue with many things inside.

Cheers
andre

On Mon, Jun 26, 2017 at 8:13 PM, Alex Tweedly via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I've got as far as building my app with within the framework, and reading
> much of the docs.
>
> I've found some things that I believe should change in the wiki - both
>
>  - just obvious bugs / typos / cleanup
>
> and
>
>  - things I think I know how to correct, but not 100% sure, and would like
> confirmation to be sure I am understanding properly.
>
> As a git/github newbie - how do I go about suggesting changes to the docs ?
>
> Thanks
>
> Alex.
>
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
http://www.andregarzia.com -- All We Do Is Code.
http://fon.nu -- minimalist url shortening service.
___
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

Levure wiki / documentation

2017-06-26 Thread Alex Tweedly via use-livecode

I've got as far as building my app with within the framework, and 
reading much of the docs.


I've found some things that I believe should change in the wiki - both

 - just obvious bugs / typos / cleanup

and

 - things I think I know how to correct, but not 100% sure, and would 
like confirmation to be sure I am understanding properly.


As a git/github newbie - how do I go about suggesting changes to the docs ?

Thanks

Alex.



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

Re: Creating installers when packaging a Levure application

2017-06-26 Thread William Prothero via use-livecode

Trevor:
I should be able to continue, from your last email posting. Thanks! I got 
distracted with problems with Andre’s dbLib, and now that it’s fixed, I can get 
back to Levure. I’ll post my “success” in a bit.
Best,
Bill

> On Jun 25, 2017, at 12:09 PM, Trevor DeVore via use-livecode 
>  wrote:
> 
> On Sat, Jun 24, 2017 at 12:41 PM William Prothero via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> Trevore:
>> I looked at the helper video and noted the yml file for each helper.
>> However, I didn’t know where to add those lines to the main app yml file.
>> But, I will take another look at the documentation and see if I have
>> overlooked something.
> 
> 
> Hi Bill,
> 
> Were you able to get the YAML figured out?
> 
> -- Trevor DeVore
> 
>> 
> ___
> 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: synonyms


On 06/26/2017 01:59 PM, Richard Gaskin via use-livecode wrote:


At least with Python you need a book to explain how to make mistakes. :)


LOL

--
 Mark Wieder
 ahsoftw...@gmail.com

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

Re: synonyms

For the record, I have given up on my Object Library. The problem is buttons. 
Button can have icons. That means that I would need to copy all the linked 
icons along with the button, then manage the relinking of the copied icons that 
now have their own ID's, then manage dropping the icons BACK onto another card, 
but only if another icon of the same name does not exist, blah blah blah. YUK! 

What is needed is for the engine to allow a BUTTON to dynamically be linked to 
a grapic ON DISK without having to import a graphic object and link to that 
with all the varied issues people run into. 

Bob S


> On Jun 26, 2017, at 14:18 , Bob Sneidar via use-livecode 
>  wrote:
> 
> Not saying this means anything, but the Macintosh was released at a golden 
> moment in history, where processors had just reached the place where they 
> could support a GUI, a software developer named Microsoft was willing to 
> write programs that made the Mac more than a toy, and a growing industry made 
> such a thing as a Mac potentially profitable. 
> 
> I suspect Python had a golden moment as well. Livecode's golden moment was 
> actually not RunRev's but Apples with Hypercard. Then when there where 
> millions who loved and worked with Hypercard, Apple killed it. True there 
> were other replacements, but a huge number of people threw in the towel then. 
> I was one of them. I tried SuperCard for a while, but early releases were 
> cumbersome and there were no small number of bugs. 
> 
> Now we have Livecode, and since version 2.0 I have been really amazed at how 
> capable it has become. I use an app daily that I wrote for my company, and 
> even my service manager who thinks I just play around with it every day has 
> had to admit that it is really useful. 
> 
> But when is the new golden moment? Software developers abound, and there is 
> no lack of languages scripting or otherwise. It's not like that golden moment 
> with Apple when there was literally NOTHING like Hypercard. What we lack is 
> not features or capabilities. We lack a golden moment where software produced 
> with Livecode fills a need that launches a whole new wave of interest. 
> 
> Or maybe we just need more people to find out about it. 
> 
> Bob S
> 
> 
>> On Jun 26, 2017, at 13:59 , Richard Gaskin via use-livecode 
>>  wrote:
>> 
>> But we need to find some way to reach the tipping point of at least bring on 
>> the TIOBE Index consistently at all.
> 
> 
> ___
> 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: synonyms

Not saying this means anything, but the Macintosh was released at a golden 
moment in history, where processors had just reached the place where they could 
support a GUI, a software developer named Microsoft was willing to write 
programs that made the Mac more than a toy, and a growing industry made such a 
thing as a Mac potentially profitable. 

I suspect Python had a golden moment as well. Livecode's golden moment was 
actually not RunRev's but Apples with Hypercard. Then when there where millions 
who loved and worked with Hypercard, Apple killed it. True there were other 
replacements, but a huge number of people threw in the towel then. I was one of 
them. I tried SuperCard for a while, but early releases were cumbersome and 
there were no small number of bugs. 

Now we have Livecode, and since version 2.0 I have been really amazed at how 
capable it has become. I use an app daily that I wrote for my company, and even 
my service manager who thinks I just play around with it every day has had to 
admit that it is really useful. 

But when is the new golden moment? Software developers abound, and there is no 
lack of languages scripting or otherwise. It's not like that golden moment with 
Apple when there was literally NOTHING like Hypercard. What we lack is not 
features or capabilities. We lack a golden moment where software produced with 
Livecode fills a need that launches a whole new wave of interest. 

Or maybe we just need more people to find out about it. 

Bob S

> On Jun 26, 2017, at 13:59 , Richard Gaskin via use-livecode 
>  wrote:
> 
> But we need to find some way to reach the tipping point of at least bring on 
> the TIOBE Index consistently at all.

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

Mark Wieder wrote:

> On 06/26/2017 01:29 PM, Richard Gaskin via use-livecode wrote:
>
>> Consider Python, the world's fourth-most-popular language, and
>> perhaps the leading language for introducing newcomers to
>> programming.
>>
>> Among the core principles of Python's language design is:
>>
>> "There should be one-- and preferably only one --obvious way to
>> do it."
>> - Guido van Rossum
>> 

>>
>
> I consider Guido one of the deep thinkers of language design.
> Nonetheless, python has many pitfalls for developers. There's a
> wonderful little O'Reilly pamphlet by Mike Pirnat entitled "How to
> Make Mistakes in Python".

You can't make mistakes in LiveCode? :)

I manage to do it all the time.

At least with Python you need a book to explain how to make mistakes. :)

> IMNSHO LiveCode has more to offer newcomers due in
> no small part to the approachability of the language.

I agree, yet here we are: Python has remained in the top 5 on the TIOBE 
Index as far back as I can recall, and during the time LiveCode has only 
occasionally appeared in the bottom 50 at all.

I was recently turned down on a grant-funded project to make a system 
for teaching programming fundamentals using LiveCode, in favor of a 
project they approved based on Python.

No language is perfect; all have their warts.  And LiveCode is pretty great.

But we need to find some way to reach the tipping point of at least 
bring on the TIOBE Index consistently at all.

And I don't think synonyms, or lack thereof, are going to make that 
difference.

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

Re: synonyms


On 06/26/2017 12:57 PM, Richmond Mathewson via use-livecode wrote:

Well . . . here we are all going to draw ourselves up to do battle . . .


Nope. Not interested. Mr. Waddingham and I have a running argument on 
this topic, and I can't resist the opportunity to get in a few jabs, 
especially when it's handed to me on a plate like that. But as I pointed 
out, I don't expect either of us to change our positions, and if this is 
going to turn out to be a religious war I'm going to dive into my 
atheist foxhole and sit this one out.



I suffer from a horrible tendency to see both sides of an argument.


Don't get me wrong - I do too.
Doesn't stop me from being right, though. 

--
 Mark Wieder
 ahsoftw...@gmail.com

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

Re: synonyms


On 06/26/2017 01:29 PM, Richard Gaskin via use-livecode wrote:

Consider Python, the world's fourth-most-popular language, and perhaps 
the leading language for introducing newcomers to programming.


Among the core principles of Python's language design is:

"There should be one-- and preferably only one --obvious way to do it."
- Guido van Rossum




I consider Guido one of the deep thinkers of language design. 
Nonetheless, python has many pitfalls for developers. There's a 
wonderful little O'Reilly pamphlet by Mike Pirnat entitled "How to Make 
Mistakes in Python". IMNSHO LiveCode has more to offer newcomers due in 
no small part to the approachability of the language.


http://www.oreilly.com/programming/free/how-to-make-mistakes-in-python.csp

--
 Mark Wieder
 ahsoftw...@gmail.com

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

Re: synonyms

2017-06-26 Thread J. Landman Gay via use-livecode


On 6/26/17 3:14 PM, Richmond Mathewson via use-livecode wrote:


On 6/26/17 11:07 pm, J. Landman Gay via use-livecode wrote:
Just please don't remove the ones we've got. I haven't typed out 
"background" or "card" in 30 years. My brain would short out.


I wonder if it is about time in this discussion to differentiate between 
*abbreviations* and *synonyms*?


I think from the engine's perspective they're the same.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

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

Re: synonyms

Richmond Mathewson wrote:

> I think that it is probably generally true that the more synonyms
> and ways of saying the same thing a language has, the easier it is
> to learn.
>
> This is also borne out by Linguistic research.

Linguistics for communicating with humans follows different rules than 
the linguistics used for communicating with machines.

Their purpose and scope is vastly different, so it should not be 
surprising that what is "best" for one isn't necessarily "best" in another.

Indeed, most natural languages have no "best"; only artificial languages 
like Esperanto and the older Boontling are "designed" at all.  Natural 
languages are multi-millennial accidents-in-the-making.

In stark contrast. programming languages have a very narrow scope, and 
are not only explicitly designed by necessity, but usually quite 
narrowly, as they attempt to communicate with a machine too stupid to 
count past 1.

Consider Python, the world's fourth-most-popular language, and perhaps 
the leading language for introducing newcomers to programming.

Among the core principles of Python's language design is:

"There should be one-- and preferably only one --obvious way to do it."
- Guido van Rossum

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

Re: Set the imagesource of a character to a built in graphic

In this case the only thing I am trying to hide is all the subtext between the 
main lines starting with the line clicked on. It's always going to be a 
contiguous chunk, and nothing will change the contents of the field except my 
scripts so that is good. 

Not sure about the metadata property, but I want to make sure that if the user 
clicks anywhere else except for the +/- icon, nothing happens. That is why I 
check for the clickChar. 

Bob S

> On Jun 26, 2017, at 10:52 , hh via use-livecode 
>  wrote:
> 
> Bob S. wrote:
> "if the hidden of line tStartLine to tEndLine of me is 
> then set the hidden of line tStartLine to tEndLine of me to "
> 
> Yes, but depends on the scenario: Sometimes I find it more safe to walk
> through the range (for j=tStartLine to tEndLine) and check the hidden
> of each single line, because the hidden of a range may have been changed
> by changing the range elsewhere.
> 
> Also: Did you already try to use the metadata property for a chunk instead
> of relying on spaces?

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

2017-06-26 Thread Richmond Mathewson via use-livecode




On 6/26/17 11:07 pm, J. Landman Gay via use-livecode wrote:
Just please don't remove the ones we've got. I haven't typed out 
"background" or "card" in 30 years. My brain would short out.


I wonder if it is about time in this discussion to differentiate between 
*abbreviations* and *synonyms*?


Richmond.



On 6/26/17 1:48 PM, Mark Waddingham via use-livecode wrote:
I'm against synonyms being part of the core language - they have no 
place there as they are 'tailorings'. Indeed a good part of the 
argument for them could be solved by better tooling - e.g. 
autocomplete and suggested tokens if one isn't quite right.


Every single property in the engine could have synonyms and some many 
(see the recent discussion about clipsToRect). An attempt to 
'normalise' hilite and its various compound forms would have resulted 
in 40 (iirc) additions to the token table.


Moreover every single synonym reduces the set of possibilities of 
things we could add in the future and can cause backwards 
compatibility issues in existing scripts (as they become for all 
intents and purposes reserved).


There is no easy way to administer synonym additions centrally and 
each one increases the maintenance burden in the current architecture.


So the only 'synonyms' which it makes sense to adopt right now are 
the ones which help move the current syntax to having a consistent 
and sensible canonical form which is easy to document and explain.


This allows, in the future, for a far more general and decentralised 
way to tailor syntax *in general* whilst ensuring there will always 
be one canonical form to which scripts can be translated to enable 
them to be compiled and (more importantly) be translated to people's 
preferred form.


So, I get the reasoning behind them (although I still think it better 
to train people implicitly to use canonical forms via better tooling, 
as if everyone 'sings' with the same language, uniform understanding 
is increased) so in the future everyone will be able to 'knock 
themselves out'...


However, I'd point out that the primary reason for the architecture 
to allow that is specifying custom syntax, and non-English language 
variants. The fact that the 'synonym problem' would also be 'fixed' 
by it Is but a happy by-product.


Warmest Regards,

Mark.

Sent from my iPhone

On 26 Jun 2017, at 18:59, Mark Wieder via use-livecode 
 wrote:



On 06/26/2017 03:55 AM, Mark Waddingham via use-livecode wrote:

I think it is probably generally true that the more consistent and 
simpler the language is, the easier it is to learn.


...and I would follow that with the (long-running by now) argument 
that synonyms provide for an ease-of-use facility in coding and 
therefore a simpler approach to using the language. For the trivial 
case here, if I can't remember whether the language supports "is" or 
"=" for variable assignments, I can use one or the other without 
having to interrupt my train of thought to look it up in the 
dictionary/guides.


One of LiveCode's strengths is the fact that there are many possible 
solutions to a given problem, and the xtalk language allows much 
flexibility in solving it. For a problem placed before any three 
coders, you will find at least four different solutions. Limiting 
the language limits the ways in which a problem may be thought of - 
that's the basis of the linguistic relativism, and it applies to 
programming languages as well as to natural languages.


--
Mark Wieder
ahsoftw...@gmail.com

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

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



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

2017-06-26 Thread J. Landman Gay via use-livecode

Just please don't remove the ones we've got. I haven't typed out
"background" or "card" in 30 years. My brain would short out.

On 6/26/17 1:48 PM, Mark Waddingham via use-livecode wrote:

I'm against synonyms being part of the core language - they have no place there
as they are 'tailorings'. Indeed a good part of the argument for them could be
solved by better tooling - e.g. autocomplete and suggested tokens if one isn't
quite right.

Every single property in the engine could have synonyms and some many (see the
recent discussion about clipsToRect). An attempt to 'normalise' hilite and its
various compound forms would have resulted in 40 (iirc) additions to the token
table.

Moreover every single synonym reduces the set of possibilities of things we
could add in the future and can cause backwards compatibility issues in
existing scripts (as they become for all intents and purposes reserved).

There is no easy way to administer synonym additions centrally and each one
increases the maintenance burden in the current architecture.

So the only 'synonyms' which it makes sense to adopt right now are the ones
which help move the current syntax to having a consistent and sensible
canonical form which is easy to document and explain.

This allows, in the future, for a far more general and decentralised way to
tailor syntax *in general* whilst ensuring there will always be one canonical
form to which scripts can be translated to enable them to be compiled and (more
importantly) be translated to people's preferred form.

So, I get the reasoning behind them (although I still think it better to train
people implicitly to use canonical forms via better tooling, as if everyone
'sings' with the same language, uniform understanding is increased) so in the
future everyone will be able to 'knock themselves out'...

However, I'd point out that the primary reason for the architecture to allow
that is specifying custom syntax, and non-English language variants. The fact
that the 'synonym problem' would also be 'fixed' by it Is but a happy
by-product.

Warmest Regards,

Mark.

Sent from my iPhone

On 26 Jun 2017, at 18:59, Mark Wieder via use-livecode
wrote:

On 06/26/2017 03:55 AM, Mark Waddingham via use-livecode wrote:

I think it is probably generally true that the more consistent and simpler the
language is, the easier it is to learn.

...and I would follow that with the (long-running by now) argument that synonyms provide for an
ease-of-use facility in coding and therefore a simpler approach to using the language. For the
trivial case here, if I can't remember whether the language supports "is" or
"=" for variable assignments, I can use one or the other without having to interrupt my
train of thought to look it up in the dictionary/guides.

One of LiveCode's strengths is the fact that there are many possible solutions
to a given problem, and the xtalk language allows much flexibility in solving
it. For a problem placed before any three coders, you will find at least four
different solutions. Limiting the language limits the ways in which a problem
may be thought of - that's the basis of the linguistic relativism, and it
applies to programming languages as well as to natural languages.

--
Mark Wieder
ahsoftw...@gmail.com

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

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com

Re: synonyms

2017-06-26 Thread Richmond Mathewson via use-livecode

Well . . . here we are all going to draw ourselves up to do battle . . .

On 6/26/17 9:48 pm, Mark Waddingham via use-livecode wrote:

I suffer from a horrible tendency to see both sides of an argument.

What you have stated above, Mark, makes 100% perfect sense in terms of a
"tight", efficient programming environment.

It doesn't make sense if one wants to preserve a programming language
which can largely be self-taught rather than didactically

spoon-fed to learners.

That last point was one of the main ideas behind the development of
Hypercard.

Most of us are well aware that LiveCode is NOT Hypercard any more than I
am not a small, furry mouselike mammal that danced around
the toes of dying dinosaurs: LiveCode is descended from HyperCard, and I
may be descended from small, furry mammals.

What LiveCode (the company) have to decide (and it's a tough call) is
how much they want their LiveCode to hold onto the HyperCard
legacy (and probably as a result continue to be regarded by programming
snobs as a kid's toy) and how much they want LiveCode to
"grow up" and try to displace some of the serious market leaders (C++,
C#, VBasic, Python).

My position is well-known, but I am an educator, and an educator who
does not favour didactic teaching.

There is no easy way to administer synonym additions centrally and each one
increases the maintenance burden in the current architecture.

"train people implicitly" . . . hard job.

Warmest Regards,

Mark.

Sent from my iPhone

On 26 Jun 2017, at 18:59, Mark Wieder via use-livecode
wrote:

On 06/26/2017 03:55 AM, Mark Waddingham via use-livecode wrote:

I think it is probably generally true that the more consistent and simpler the
language is, the easier it is to learn.

One of LiveCode's strengths is the fact that there are many possible solutions
to a given problem, and the xtalk language allows much flexibility in solving
it.

Yes; but that presupposes LiveCode is going to be burdened with the
"it's an xTalk dialect" label forever, and whether "xTalk"
continues to make sense seeing how far the xTalk outgrowths from
HyperCard have diverged.

For a problem placed before any three coders, you will find at least four
different solutions. Limiting the language limits the ways in which a problem
may be thought of - that's the basis of the linguistic relativism, and it
applies to programming languages as well as to natural languages.

Of course.

--
Mark Wieder
ahsoftw...@gmail.com

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: synonyms

2017-06-26 Thread Richmond Mathewson via use-livecode

I think that it is probably generally true that the more synonyms and 
ways of saying the same thing a language has,

the easier it is to learn.

This is also borne out by Linguistic research.

Today I had 7 children who ALL wrote LiveCode scripts to do a Bubble 
Sort fo 6 fields containing numbers; they

were all different to greater or lesser degress, and they all did the job!

Thankyou HyperCard, MetaCard and LiveCode for making your programming 
"thingy" the way you did!


Richmond.

On 6/26/17 8:59 pm, Mark Wieder via use-livecode wrote:

On 06/26/2017 03:55 AM, Mark Waddingham via use-livecode wrote:

I think it is probably generally true that the more consistent and 
simpler the language is, the easier it is to learn.


...and I would follow that with the (long-running by now) argument 
that synonyms provide for an ease-of-use facility in coding and 
therefore a simpler approach to using the language. For the trivial 
case here, if I can't remember whether the language supports "is" or 
"=" for variable assignments, I can use one or the other without 
having to interrupt my train of thought to look it up in the 
dictionary/guides.


One of LiveCode's strengths is the fact that there are many possible 
solutions to a given problem, and the xtalk language allows much 
flexibility in solving it. For a problem placed before any three 
coders, you will find at least four different solutions. Limiting the 
language limits the ways in which a problem may be thought of - that's 
the basis of the linguistic relativism, and it applies to programming 
languages as well as to natural languages.




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


On 06/26/2017 11:48 AM, Mark Waddingham via use-livecode wrote:

I'm against synonyms being part of the core language - they have no place there 
as they are 'tailorings'. Indeed a good part of the argument for them could be 
solved by better tooling - e.g. autocomplete and suggested tokens if one isn't 
quite right.


Heh. Autocomplete, I think, works well when you already have an idea 
where you're going. I don't think it would help much with a line like


"if x "

You and I have this discussion about synonyms regularly, and I don't 
expect that either of us will ever convince the other. I'm happy that 
you are the one in charge of shepherding the language, and I'll continue 
my role as proponent from the sidelines.




Every single property in the engine could have synonyms and some many (see the 
recent discussion about clipsToRect). An attempt to 'normalise' hilite and its 
various compound forms would have resulted in 40 (iirc) additions to the token 
table.


My PR for 'hilite' wasn't to 'normalise' the term, but to be consistent 
about its use. To this day I can't remember where 'highlight' is 
acceptable and where 'hilite' is proscribed, my distaste for 'hilite' as 
a word notwithstanding.



Moreover every single synonym reduces the set of possibilities of things we 
could add in the future and can cause backwards compatibility issues in 
existing scripts (as they become for all intents and purposes reserved).


Point taken, but do you seriously believe it would be a good idea to 
have different meanings for "hilite" and "highlight"? I can't imagine 
that repurposing either of these for the same syntax would help in 
anyone's comprehension of the language or ease in scripting. Making the 
two words synonyms is the only thing that makes sense to me.



There is no easy way to administer synonym additions centrally and each one 
increases the maintenance burden in the current architecture.


Having submitted several rejected PRs for synonyms I can vouch for the 
fact that they're not that hard to add.



So, I get the reasoning behind them (although I still think it better to train 
people implicitly to use canonical forms via better tooling, as if everyone 
'sings' with the same language, uniform understanding is increased) so in the 
future everyone will be able to 'knock themselves out'...


That may be the basis of our disagreement then... I'd prefer that 
everyone *not* be stamped from the same mold.


--
 Mark Wieder
 ahsoftw...@gmail.com

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

Re: How do we access the clipboard on mobile devices?

For this case, though, it will have to be called up specially, not made to look 
like it was already there.

The field in question also allows users to put in images - something I don't 
think native fields can do. So the app would have an enter text button that 
calls up the native field, where the user can type or paste text that is then 
inserted into the LC field.

Sent from my iPhone

> On Jun 26, 2017, at 3:21 PM, Dave Kilroy via use-livecode 
>  wrote:
> 
> OK good, the visible bits of a native field (border, background colour etc) 
> could all be provided by background graphics so when you switch fields no 
> visible change can be seen - you might even be able to use the 
> inputTextChanged message instead of a button which the user has to press
> 
> BTW you’ll have to delete the native field instead of just hiding it as it’ll 
> be in the top layer and could interfere with user interactions…
> 
> Dave
> 
> 
>> Hi Dave - I think that might help 
>> 
>> I could give the user a button for opening up a pastable field. They could 
>> paste into that and LC could process it and put it into the regular field. 
>> It's not a bad idea. 
> ___
> 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: How do we access the clipboard on mobile devices?

2017-06-26 Thread Dave Kilroy via use-livecode

OK good, the visible bits of a native field (border, background colour etc) 
could all be provided by background graphics so when you switch fields no 
visible change can be seen - you might even be able to use the inputTextChanged 
message instead of a button which the user has to press

BTW you’ll have to delete the native field instead of just hiding it as it’ll 
be in the top layer and could interfere with user interactions…

Dave


> Hi Dave - I think that might help 
> 
> I could give the user a button for opening up a pastable field. They could 
> paste into that and LC could process it and put it into the regular field. 
> It's not a bad idea. 
___
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 do we access the clipboard on mobile devices?

Hi Dave - I think that might help

I could give the user a button for opening up a pastable field. They could 
paste into that and LC could process it and put it into the regular field. It's 
not a bad idea.




Sent from my iPhone

> On Jun 26, 2017, at 2:39 PM, Dave Kilroy via use-livecode 
>  wrote:
> 
> Jonathan if you use a native field you can access it’s contents (which a user 
> could have pasted into it) via something like the inputEndEditing message, 
> and from there hide/delete the native field, reveal a LiveCode field, place 
> the relevant data into it etc etc - would this help your situation?
> 
> Dave
> ___
> 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: synonyms

2017-06-26 Thread Mark Waddingham via use-livecode

I'm against synonyms being part of the core language - they have no place there 
as they are 'tailorings'. Indeed a good part of the argument for them could be 
solved by better tooling - e.g. autocomplete and suggested tokens if one isn't 
quite right.

Every single property in the engine could have synonyms and some many (see the 
recent discussion about clipsToRect). An attempt to 'normalise' hilite and its 
various compound forms would have resulted in 40 (iirc) additions to the token 
table.

Moreover every single synonym reduces the set of possibilities of things we 
could add in the future and can cause backwards compatibility issues in 
existing scripts (as they become for all intents and purposes reserved).

There is no easy way to administer synonym additions centrally and each one 
increases the maintenance burden in the current architecture.

So the only 'synonyms' which it makes sense to adopt right now are the ones 
which help move the current syntax to having a consistent and sensible 
canonical form which is easy to document and explain.

This allows, in the future, for a far more general and decentralised way to 
tailor syntax *in general* whilst ensuring there will always be one canonical 
form to which scripts can be translated to enable them to be compiled and (more 
importantly) be translated to people's preferred form.

So, I get the reasoning behind them (although I still think it better to train 
people implicitly to use canonical forms via better tooling, as if everyone 
'sings' with the same language, uniform understanding is increased) so in the 
future everyone will be able to 'knock themselves out'...

However, I'd point out that the primary reason for the architecture to allow 
that is specifying custom syntax, and non-English language variants. The fact 
that the 'synonym problem' would also be 'fixed' by it Is but a happy 
by-product.

Warmest Regards,

Mark.

Sent from my iPhone

> On 26 Jun 2017, at 18:59, Mark Wieder via use-livecode 
>  wrote:
> 
>> On 06/26/2017 03:55 AM, Mark Waddingham via use-livecode wrote:
>> 
>> I think it is probably generally true that the more consistent and simpler 
>> the language is, the easier it is to learn.
> 
> ...and I would follow that with the (long-running by now) argument that 
> synonyms provide for an ease-of-use facility in coding and therefore a 
> simpler approach to using the language. For the trivial case here, if I can't 
> remember whether the language supports "is" or "=" for variable assignments, 
> I can use one or the other without having to interrupt my train of thought to 
> look it up in the dictionary/guides.
> 
> One of LiveCode's strengths is the fact that there are many possible 
> solutions to a given problem, and the xtalk language allows much flexibility 
> in solving it. For a problem placed before any three coders, you will find at 
> least four different solutions. Limiting the language limits the ways in 
> which a problem may be thought of - that's the basis of the linguistic 
> relativism, and it applies to programming languages as well as to natural 
> languages.
> 
> -- 
> Mark Wieder
> ahsoftw...@gmail.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

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

2017-06-26 Thread Tore Nilsen via use-livecode



> 26. jun. 2017 kl. 19:59 skrev Mark Wieder via use-livecode 
> :
> 
>  Limiting the language limits the ways in which a problem may be thought of - 
> that's the basis of the linguistic relativism, and it applies to programming 
> languages as well as to natural languages.

And it also applies to problem solving in itself. In our culture, abstract 
thinking and the use of language are intertwined, it is hard to imagine one 
exists without the other. Flexibility in the language can add to the users 
ability to solve problems. 

Regards
Tore Nilsen
___
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 do we access the clipboard on mobile devices?

2017-06-26 Thread Dave Kilroy via use-livecode

Jonathan if you use a native field you can access it’s contents (which a user 
could have pasted into it) via something like the inputEndEditing message, and 
from there hide/delete the native field, reveal a LiveCode field, place the 
relevant data into it etc etc - would this help your situation?

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

synonyms


On 06/26/2017 03:55 AM, Mark Waddingham via use-livecode wrote:

I think it is probably generally true that the more consistent and 
simpler the language is, the easier it is to learn.


...and I would follow that with the (long-running by now) argument that 
synonyms provide for an ease-of-use facility in coding and therefore a 
simpler approach to using the language. For the trivial case here, if I 
can't remember whether the language supports "is" or "=" for variable 
assignments, I can use one or the other without having to interrupt my 
train of thought to look it up in the dictionary/guides.


One of LiveCode's strengths is the fact that there are many possible 
solutions to a given problem, and the xtalk language allows much 
flexibility in solving it. For a problem placed before any three coders, 
you will find at least four different solutions. Limiting the language 
limits the ways in which a problem may be thought of - that's the basis 
of the linguistic relativism, and it applies to programming languages as 
well as to natural languages.


--
 Mark Wieder
 ahsoftw...@gmail.com

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

Re: Set the imagesource of a character to a built in graphic

2017-06-26 Thread hh via use-livecode

Bob S. wrote:
"if the hidden of line tStartLine to tEndLine of me is 
then set the hidden of line tStartLine to tEndLine of me to "

Yes, but depends on the scenario: Sometimes I find it more safe to walk
through the range (for j=tStartLine to tEndLine) and check the hidden
of each single line, because the hidden of a range may have been changed
by changing the range elsewhere.

Also: Did you already try to use the metadata property for a chunk instead
of relying on spaces?

___
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: Set the imagesource of a character to a built in graphic

2017-06-26 Thread ** Clarence P Martin ** via use-livecode

Richard, that is kind of what I was seeing with replace in field. Very dicey. 
So I decided to see if I could use the hidden propery method to work. Here is 
what I came up with. Remember that char 1 of the 1st level lines are spaces, 
and the 1st char spaces in those lines have the imageData set to a + graphic so 
clicking on the + will expand and collapse the line. The second level lines do 
not start with spaces, so I can use that to discriminate between first level 
lines and others (I supose I could have checked for the imageData but what the 
hell):

on mouseUp
   put the clickChar into tChar
   if tChar is not space then exit mouseUp
   put word 2 of the clickLine into tLine -- the line number of the line clicked
   put the text of me into tText
   put tLine +1 into tStartLine

   repeat with i = tStartLine to the number of lines of tText
  if char 1 of line i of tText is space then
 exit repeat
  end if

  put i into tEndLine
   end repeat
   
   if char 1 of line tEndLine of me is space then exit mouseUp -- there are no 
sub-lines

   if the hidden of line tStartLine to tEndLine of me is true then
  set the hidden of line tStartLine to tEndLine of me to false
   else
  set the hidden of line tStartLine to tEndLine of me to true
   end if
end mouseUp

Bob S



___
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: Set the imagesource of a character to a built in graphic

OK, I didn't know about the paragraph property.

set the visible of paragraph 2 of fld "fldList" to false
 this does make a line disappear, but apparently keeps the value in memory
so that it can be restored.

Sincerely,

Clarence Martin
Email: chi...@themartinz.com
Cell: 626 6965561

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of ** Clarence P Martin ** via use-livecode
Sent: Monday, June 26, 2017 9:46 AM
To: 'How to use LiveCode' 
Cc: ** Clarence P Martin ** 
Subject: RE: Set the imagesource of a character to a built in graphic

Can you supply a code sample of hiding a line of text in a list?

Sincerely,

Clarence Martin
Email: chi...@themartinz.com
Cell: 626 6965561

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Bob Sneidar via use-livecode
Sent: Monday, June 26, 2017 9:24 AM
To: How to use LiveCode 
Cc: Bob Sneidar 
Subject: Re: Set the imagesource of a character to a built in graphic

That does indeed work and is a lot cleaner. 

Bob S


> On Jun 26, 2017, at 09:11 , Bob Sneidar via use-livecode
 wrote:
> 
> Oh nice I didn't know a line of text could be hidden! I will check 
> that
out. Meanwhile I got it working right by using htmlText. :-)
> 
> Bob S
> 
> 
>> On Jun 26, 2017, at 09:10 , hh via use-livecode
 wrote:
>> 
>> Eventually you are showing/hiding lines, so:
>> 
>> Did you already try to use the hidden property?

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


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


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

Re: Set the imagesource of a character to a built in graphic

Mark Waddingham wrote:

> There's a form of replace which preserves styling in fields these days
> (an FE we ran quite a while ago) - take a look at the replace entry in
> the dictionary.

It works seemingly well, even with chunk expressions, e.g.:

  replace "i" with "X" in line 1 of fld 1 preserving styles

But I found it also does something very weird:  in my test the 
imageSource was applied to the first "i" in the field, and after the 
replace command there was now an "X" immediately before the rendered image.

So while it was good to see the image still rendered, if the "i" was now 
replaced with "X" and the "X" is visible, what is the imageSource 
attached to?

It seems it's attached to nothing.  Getting the htmlText of the field 
after the replace command shows no  tag at all.

Reported, with sample stack:
http://quality.livecode.com/show_bug.cgi?id=19956

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

Re: Set the imagesource of a character to a built in graphic

set the hidden of line 1 to  3 of field "myField" to true -- only works with 
fields not text in variables

Bob S


> On Jun 26, 2017, at 09:46 , ** Clarence P Martin ** via use-livecode 
>  wrote:
> 
> Can you supply a code sample of hiding a line of text in a list?
> 
> Sincerely,
> 
> Clarence Martin


___
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: Set the imagesource of a character to a built in graphic

2017-06-26 Thread ** Clarence P Martin ** via use-livecode

I looked at the widget. Not sure how to use it. I got an object with a + 
control which apparently creates custom property keys and displays it in the 
field. I could probably make that work, but I probably won't have a lot of 
control over the appearance. I got the thing working by manipulating the HTML 
text. 

The goal will be to create an object library where I can select an object, be 
it a group, button, field or menu (I know it's a glorified button) and then in 
a palette add that object to a list where each object class is 
expandable/collapsable. 

I have certain fields and buttons which have custom scripts and properties 
which control how they behave in my apps. I am trying to create a kind of 
Library app that will allow me to change a few settings then "drop" the object 
onto a card. 

I will have to be able to add and delete objects to this list, while copying 
the actual object to the library somehow. If it works the way I would like, I 
will be able to create and customize objects one time, then drop them any 
number of times. 

Behaviors work well for scripts, but there is no "behaviors" for properties. I 
suppose they would be called "templates" if they existed. I suppose I could 
simply provide a list of properties and let the user check off the ones they 
want to include in a "template" but there are so many properties this would 
become cumbersome pretty quickly. Also, that would not handle more complex 
objects like groups. 

Bob S

> On Jun 26, 2017, at 08:38 , J. Landman Gay via use-livecode 
>  wrote:
> 
> The tree widget might be useful here. Alternately, don't use replace, use 
> text chunking instead to add or remove lines.

___
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: Set the imagesource of a character to a built in graphic

Can you supply a code sample of hiding a line of text in a list?

Sincerely,

Clarence Martin
Email: chi...@themartinz.com
Cell: 626 6965561

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Bob Sneidar via use-livecode
Sent: Monday, June 26, 2017 9:24 AM
To: How to use LiveCode 
Cc: Bob Sneidar 
Subject: Re: Set the imagesource of a character to a built in graphic

That does indeed work and is a lot cleaner. 

Bob S


> On Jun 26, 2017, at 09:11 , Bob Sneidar via use-livecode
 wrote:
> 
> Oh nice I didn't know a line of text could be hidden! I will check that
out. Meanwhile I got it working right by using htmlText. :-)
> 
> Bob S
> 
> 
>> On Jun 26, 2017, at 09:10 , hh via use-livecode
 wrote:
>> 
>> Eventually you are showing/hiding lines, so:
>> 
>> Did you already try to use the hidden property?

___
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: Set the imagesource of a character to a built in graphic

That does indeed work and is a lot cleaner. 

Bob S


> On Jun 26, 2017, at 09:11 , Bob Sneidar via use-livecode 
>  wrote:
> 
> Oh nice I didn't know a line of text could be hidden! I will check that out. 
> Meanwhile I got it working right by using htmlText. :-)
> 
> Bob S
> 
> 
>> On Jun 26, 2017, at 09:10 , hh via use-livecode 
>>  wrote:
>> 
>> Eventually you are showing/hiding lines, so:
>> 
>> Did you already try to use the hidden property?

___
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: Set the imagesource of a character to a built in graphic

Oh nice I didn't know a line of text could be hidden! I will check that out. 
Meanwhile I got it working right by using htmlText. :-)

Bob S


> On Jun 26, 2017, at 09:10 , hh via use-livecode 
>  wrote:
> 
> Eventually you are showing/hiding lines, so:
> 
> Did you already try to use the hidden property?


___
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: Set the imagesource of a character to a built in graphic

2017-06-26 Thread hh via use-livecode

Eventually you are showing/hiding lines, so:

Did you already try to use the hidden property?

___
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: Set the imagesource of a character to a built in graphic

2017-06-26 Thread J. Landman Gay via use-livecode

The tree widget might be useful here. Alternately, don't use replace, use 
text chunking instead to add or remove lines.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



On June 26, 2017 10:24:11 AM Bob Sneidar via use-livecode 
 wrote:


Ok so no combination of replace in field will allow me to put something 
before or after a line without borking the imagedata. The only way to do it 
is to reapply the imageData each time I touch the field text. I was hoping 
to come up with some king of widget eventially that allowed you to 
manipulate an expanding list to show and hide subMenu items.


If no one else has done this already, I will just hack one out.

Bob S



___
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: Set the imagesource of a character to a built in graphic

Ok so no combination of replace in field will allow me to put something before 
or after a line without borking the imagedata. The only way to do it is to 
reapply the imageData each time I touch the field text. I was hoping to come up 
with some king of widget eventially that allowed you to manipulate an expanding 
list to show and hide subMenu items. 

If no one else has done this already, I will just hack one out. 

Bob S



___
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: Set the imagesource of a character to a built in graphic