Re: I Hate Full Screen!

[Brian Milby via use-livecode]

Looks like a regression in 8 from 7. Just did a quick test and don’t see
the issue in 7.1.4 but do in 8/9.

Bug 18213
On Sun, Oct 29, 2017 at 9:55 PM Roger Guay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Why can’t I set the decorations of a stack to only “Title” without that
> damnable green ball coming in every time?
>
> LC 8.1.6 and Mac OS 10.13.
>
> Thanks,
>
> Roger
> ___
> 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

I Hate Full Screen!

[Roger Guay via use-livecode]

Why can’t I set the decorations of a stack to only “Title” without that 
damnable green ball coming in every time?

LC 8.1.6 and Mac OS 10.13.

Thanks,

Roger
___
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: Relative Paths in Property Inspector

[Mike Kerner via use-livecode]

What I meant was not that you shouldn't file a QR, but that I think that
all the requests for relative paths should be combined because I think
relative paths across LC would be beneficial.  Sorry for not being clear
about that.
I have four obvious cases, where I see a benefit:
1) Using multiple machines - unless usernames are the same, absolute paths
won't be the same
2) Using multiple platforms.
3) Using network syncing tools.  If I use a syncing tool, the absolute
paths won't match, either, unless both the username and the os are the same
4) Using network file storage.  The path for syncing and storage won't be
the same - for example, if on a lappie you use a network file storage tool
to save disk space, the path will start with a network drive letter.  If
you use a syncing tool for the same service on a desktop, the path will
start with some local drive and will be at least one level deeper.

On Sun, Oct 29, 2017 at 10:30 PM, Sannyasin Brahmanathaswami via
use-livecode  wrote:

> BR: are you keeping your stacks next to the images?
>
> like this
>
> ~/Dropbox/Pet Project/animals.livecode
> ~/Dropbox/Pet Project/img/dangerous-pets/tiger.jpg
>
> and if you set the image filename to "img/dangerous-pets/tiger.jpg"
>
> it fails?
>
> --
>
> Mike Kerner wrote:
>
> it is related.  As soon as I saw your post I said "gee, that looks
> familiar".
>
> Brahmanathaswami wrote:
>
> [snip] now you can
> >
> > a) manually chop of the lead down to this in the property inspector
> >
> > img/thumbs/little-rooster.jpg
> >
> > # and it works… this is also portable if you include "img/*" in the
> > stackfiles when create your standalone and the filename is saved
> relative
> > to the stack, and, assuming you keep the folder structure intact you
> don't
> > have to even mess with defaultfolder or even
> specialFolderPath("engine")
> > because the "relativity" of the path is respected in any and all
> contexts
> > (I think…)
> >
> > so you can also programatically do this
> >
> > set the filename of img "myPet" to "img/thumbs/little-rooster.jpg"
>
> > So, why can't we just a relative path in the Property Inspector
> itself?
> > The browser tool will always return full path from User down to the
> > "asset.jpg"… if I send that stack to someone else, or use a GIT work
> flow
> > where these stacks are "pure views" (i.e. no actual imported images
> > anywhere)  along with the images. the paths are broken.  So, long
> way of
> > asking:
> >
> > Do we need an enhancement request for a check box in the PI to set
> the
> > path as relative to the stack? Seems like that would be super usefu
> >
> > Mikey has this request in since May '16… which feels related
> >
> > http://quality.livecode.com/show_bug.cgi?id=17705
> >
> > but the suggestion for having this in the PI seems a bit different,
> and
> > might not actually solve his issue for using a cloud instance of his
> > project.
> >
> > Brahmanathaswami
> >
> >
> >
> >
> >
> > ___
> > 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
>
> ___
> 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: Relative Paths in Property Inspector

[Brian Milby via use-livecode]

So the ask is for a check box in the PI (near the source field with a label
like “Relative path”)? And when checked, the PI would automatically trim
the path to be relative to the stack file (probably with the assumption
that it only goes down the hierarchy).

Or are you asking for a preference that would default to relative path
names when choosing files in the PI?

I think I know the behavior script that would need to trim the file name
(for images). Not quite sure how to get the path of the stack file in that
context yet.
On Sun, Oct 29, 2017 at 8:02 PM Mike Kerner via use-livecode <
use-livecode@lists.runrev.com> wrote:

> it is related.  As soon as I saw your post I said "gee, that looks
> familiar".
>
> On Sun, Oct 29, 2017 at 3:02 PM, Sannyasin Brahmanathaswami via
> use-livecode  wrote:
>
> > Backstory:
> >
> > Sometime back in a round with HQ we got the engine to "remember" relative
> > path settings for the filenames of images/players etc.. such that it
> would
> > not default to full path from root on the drive which makes the path
> unique
> > to that user and no longer portable… so "relativity" go supported/sticky
> in
> > different dev scenarios…
> >
> > so far so good… if you set the filename in an image in a stack that lives
> > here:
> >
> > User/MyDrive/myProject/coolAnimals.livecode
> >
> > with images here to:
> >
> > User/MyDrive/myProject/img/thumbs/little-rooster.jpg
> >
> > # it, obviously works But, now you can
> >
> > a) manually chop of the lead down to this in the property inspector
> >
> > img/thumbs/little-rooster.jpg
> >
> > # and it works… this is also portable if you include "img/*" in the
> > stackfiles when create your standalone and the filename is saved relative
> > to the stack, and, assuming you keep the folder structure intact you
> don't
> > have to even mess with defaultfolder or even specialFolderPath("engine")
> > because the "relativity" of the path is respected in any and all contexts
> > (I think…)
> >
> > so you can also programatically do this
> >
> > set the filename of img "myPet" to "img/thumbs/little-rooster.jpg"
> >
> > and that also works  though you do need to use "specialFolderPath"
> > functions on mobile.
> >
> > Again, so far so good…
> >
> > End backstory (please correct anything you see that is wrong)
> >
> > So, why can't we just a relative path in the Property Inspector itself?
> > The browser tool will always return full path from User down to the
> > "asset.jpg"… if I send that stack to someone else, or use a GIT work flow
> > where these stacks are "pure views" (i.e. no actual imported images
> > anywhere)  along with the images. the paths are broken.  So, long way of
> > asking:
> >
> > Do we need an enhancement request for a check box in the PI to set the
> > path as relative to the stack? Seems like that would be super usefu
> >
> > Mikey has this request in since May '16… which feels related
> >
> > http://quality.livecode.com/show_bug.cgi?id=17705
> >
> > but the suggestion for having this in the PI seems a bit different, and
> > might not actually solve his issue for using a cloud instance of his
> > project.
> >
> > Brahmanathaswami
> >
> >
> >
> >
> >
> > ___
> > 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
___
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: Radio button scaling

[Sannyasin Brahmanathaswami via use-livecode]

Christer

I have had some success with 

a) create icon in a vector program
b) no gradients!
c) set background as transparent
d) save as PNG at the largest size you might need.
e) scale down (never up) dynamically run time before display.

whether it is "non-smooth" will vary depending on the image.

some appear very nicely; others do break down even when scaling down…there is a 
"lower limit" after which point the edges of the image will start to become 
jaggy.   I recently did this myself for radio buttons, creating a circle in 
Illlustrator…. one for the "checked" state and one for the unchecked state. 

On 10/29/17, 12:48 AM, "use-livecode on behalf of hh via use-livecode" 
 wrote:

This is solvable as soon as icons are settable using SVG.
Other scaling would result in non-smooth displays as the icons are images.

___
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: Relative Paths in Property Inspector

[Sannyasin Brahmanathaswami via use-livecode]

BR: are you keeping your stacks next to the images?

like this

~/Dropbox/Pet Project/animals.livecode
~/Dropbox/Pet Project/img/dangerous-pets/tiger.jpg

and if you set the image filename to "img/dangerous-pets/tiger.jpg"  

it fails?

-- 

Mike Kerner wrote:

it is related.  As soon as I saw your post I said "gee, that looks
familiar".

Brahmanathaswami wrote:

[snip] now you can
>
> a) manually chop of the lead down to this in the property inspector
>
> img/thumbs/little-rooster.jpg
>
> # and it works… this is also portable if you include "img/*" in the
> stackfiles when create your standalone and the filename is saved relative
> to the stack, and, assuming you keep the folder structure intact you don't
> have to even mess with defaultfolder or even specialFolderPath("engine")
> because the "relativity" of the path is respected in any and all contexts
> (I think…)
>
> so you can also programatically do this
>
> set the filename of img "myPet" to "img/thumbs/little-rooster.jpg"

> So, why can't we just a relative path in the Property Inspector itself?
> The browser tool will always return full path from User down to the
> "asset.jpg"… if I send that stack to someone else, or use a GIT work flow
> where these stacks are "pure views" (i.e. no actual imported images
> anywhere)  along with the images. the paths are broken.  So, long way of
> asking:
>
> Do we need an enhancement request for a check box in the PI to set the
> path as relative to the stack? Seems like that would be super usefu
>
> Mikey has this request in since May '16… which feels related
>
> http://quality.livecode.com/show_bug.cgi?id=17705
>
> but the suggestion for having this in the PI seems a bit different, and
> might not actually solve his issue for using a cloud instance of his
> project.
>
> Brahmanathaswami
>
>
>
>
>
> ___
> 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

___
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: Relative Paths in Property Inspector

[Mike Kerner via use-livecode]

it is related.  As soon as I saw your post I said "gee, that looks
familiar".

On Sun, Oct 29, 2017 at 3:02 PM, Sannyasin Brahmanathaswami via
use-livecode  wrote:

> Backstory:
>
> Sometime back in a round with HQ we got the engine to "remember" relative
> path settings for the filenames of images/players etc.. such that it would
> not default to full path from root on the drive which makes the path unique
> to that user and no longer portable… so "relativity" go supported/sticky in
> different dev scenarios…
>
> so far so good… if you set the filename in an image in a stack that lives
> here:
>
> User/MyDrive/myProject/coolAnimals.livecode
>
> with images here to:
>
> User/MyDrive/myProject/img/thumbs/little-rooster.jpg
>
> # it, obviously works But, now you can
>
> a) manually chop of the lead down to this in the property inspector
>
> img/thumbs/little-rooster.jpg
>
> # and it works… this is also portable if you include "img/*" in the
> stackfiles when create your standalone and the filename is saved relative
> to the stack, and, assuming you keep the folder structure intact you don't
> have to even mess with defaultfolder or even specialFolderPath("engine")
> because the "relativity" of the path is respected in any and all contexts
> (I think…)
>
> so you can also programatically do this
>
> set the filename of img "myPet" to "img/thumbs/little-rooster.jpg"
>
> and that also works  though you do need to use "specialFolderPath"
> functions on mobile.
>
> Again, so far so good…
>
> End backstory (please correct anything you see that is wrong)
>
> So, why can't we just a relative path in the Property Inspector itself?
> The browser tool will always return full path from User down to the
> "asset.jpg"… if I send that stack to someone else, or use a GIT work flow
> where these stacks are "pure views" (i.e. no actual imported images
> anywhere)  along with the images. the paths are broken.  So, long way of
> asking:
>
> Do we need an enhancement request for a check box in the PI to set the
> path as relative to the stack? Seems like that would be super usefu
>
> Mikey has this request in since May '16… which feels related
>
> http://quality.livecode.com/show_bug.cgi?id=17705
>
> but the suggestion for having this in the PI seems a bit different, and
> might not actually solve his issue for using a cloud instance of his
> project.
>
> Brahmanathaswami
>
>
>
>
>
> ___
> 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: Socket help needed for API

[Monte Goulding via use-livecode]

Hi Richard

LiveCode does not currently have websocket support. As this has come up 
recently in a number of areas I had a quick look at the spec 
(https://tools.ietf.org/html/rfc6455 ). It 
looks relatively feasible to implement on top of our current socket support in 
LiveCode script. Possibly as part of libURL or a separate library.

Cheers

Monte

> On 29 Oct 2017, at 10:49 pm, Richard Miller via use-livecode 
>  wrote:
> 
> I have been using LC to access an API through conventional means, but that 
> site has now changed to a socket protocol. I have tried various methods, but 
> just can’t get it to work.
> 
> I would appreciate it if someone familiar with sockets could take a look and 
> show me how to do this. I only need to know how to establish a connection and 
> receive data. I can take it from there.
> 
> The information I am looking to receive is what is produced through this now 
> deprecated API. It is a list of all of the digital tokens being traded at 
> this site. (Note: you may have to send this link a few times in order to get 
> a response. The site is often overloaded.)
> 
> put https://api.etherdelta.com/returnTicker
> 
> I want to receive the same information, but using the new socket-based API 
> shown here.
> 
> https://github.com/etherdelta/etherdelta.github.io/blob/master/docs/API.md
> https://github.com/etherdelta/etherdelta.github.io/tree/master/bots
> 
> Thank you very much for help with this.
> Richard Miller
> 
> ___
> 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

Relative Paths in Property Inspector

[Sannyasin Brahmanathaswami via use-livecode]

Backstory:

Sometime back in a round with HQ we got the engine to "remember" relative path 
settings for the filenames of images/players etc.. such that it would not 
default to full path from root on the drive which makes the path unique to that 
user and no longer portable… so "relativity" go supported/sticky in different 
dev scenarios…

so far so good… if you set the filename in an image in a stack that lives here:

User/MyDrive/myProject/coolAnimals.livecode

with images here to:

User/MyDrive/myProject/img/thumbs/little-rooster.jpg

# it, obviously works But, now you can

a) manually chop of the lead down to this in the property inspector

img/thumbs/little-rooster.jpg

# and it works… this is also portable if you include "img/*" in the stackfiles 
when create your standalone and the filename is saved relative to the stack, 
and, assuming you keep the folder structure intact you don't have to even mess 
with defaultfolder or even specialFolderPath("engine")  because the 
"relativity" of the path is respected in any and all contexts (I think…)

so you can also programatically do this

set the filename of img "myPet" to "img/thumbs/little-rooster.jpg"

and that also works  though you do need to use "specialFolderPath" functions on 
mobile.

Again, so far so good…

End backstory (please correct anything you see that is wrong)

So, why can't we just a relative path in the Property Inspector itself? The 
browser tool will always return full path from User down to the "asset.jpg"… if 
I send that stack to someone else, or use a GIT work flow where these stacks 
are "pure views" (i.e. no actual imported images anywhere)  along with the 
images. the paths are broken.  So, long way of asking:

Do we need an enhancement request for a check box in the PI to set the path as 
relative to the stack? Seems like that would be super usefu

Mikey has this request in since May '16… which feels related

http://quality.livecode.com/show_bug.cgi?id=17705

but the suggestion for having this in the PI seems a bit different, and might 
not actually solve his issue for using a cloud instance of his project.

Brahmanathaswami





___
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: Radio button scaling

[Pyyhtiä Christer via use-livecode]

Thank you!

1. In the mean while built just a double button scheme, let's see how it looks 
with the devices.  Look forward to simplifying back to single buttons with the 
new icons for checkBox and radio buttons.  "When" is my 2-3 year old question, 
though.  Just ask a nerd nearby to do the job.

2.  Still on Mac OS/X 10.12 level.  Thanks for the warning.  The source of the 
problem may be that I am using different 2nd screens at the different desks I 
work at.  Not a nice problem.

rgds


From: hh >
To: use-livecode@lists.runrev.com 
Subject: Re: Radio button scaling
Message-ID: >
Content-Type: text/plain;   charset=us-ascii

Answer 1.
This is solvable as soon as icons are settable using SVG.
Other scaling would result in non-smooth displays as the icons are images.

But you could make a set of images for different "resolutions" and use
these images as "icons" for the buttons, dependent on your scale.
Also you could make a radio button widget (don't forget the radio-grouping).

Answer 2.
In case you are using MacOS 10.13, then the culprit is the OS, not LiveCode.
MacOS 10.13 is horrible. Sometimes the prefs of some Apps, not only LiveCode,
are reset to default in between working. What you describe sounds like that.

> Christer P. wrote:
> Question 1:
> What is the problem with getting the radio buttons "tick boxes" scalable?
> Trying to remember, I asked about it for a few years ago, and the answer by 
> LC team was, it is about the icon??
> I tried using switch button widgets, but the scaling of those isn't linear 
> (width / height) as any other objects.
> So, do I need to do my own radio buttons (i.e. use a round hilite button + 
> text button) or would there be another solution?
> 
> Question 2:
> LC 8.1.7 rc-3; there is instability in retaining setups.  For example, 
> upgrading from the previous G version the path to SDK was lost.  Also various 
> setups seem to move, the background of the screen goes all grey.  Anyone 
> experiencing oddities like this?


___
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

Socket help needed for API

[Richard Miller via use-livecode]

I have been using LC to access an API through conventional means, but 
that site has now changed to a socket protocol. I have tried various 
methods, but just can’t get it to work.


I would appreciate it if someone familiar with sockets could take a look 
and show me how to do this. I only need to know how to establish a 
connection and receive data. I can take it from there.


The information I am looking to receive is what is produced through this 
now deprecated API. It is a list of all of the digital tokens being 
traded at this site. (Note: you may have to send this link a few times 
in order to get a response. The site is often overloaded.)


    put https://api.etherdelta.com/returnTicker

I want to receive the same information, but using the new socket-based 
API shown here.


https://github.com/etherdelta/etherdelta.github.io/blob/master/docs/API.md
https://github.com/etherdelta/etherdelta.github.io/tree/master/bots

Thank you very much for help with this.
Richard Miller

___
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: Radio button scaling

[hh via use-livecode]

Answer 1.
This is solvable as soon as icons are settable using SVG.
Other scaling would result in non-smooth displays as the icons are images.

But you could make a set of images for different "resolutions" and use
these images as "icons" for the buttons, dependent on your scale.
Also you could make a radio button widget (don't forget the radio-grouping).

Answer 2.
In case you are using MacOS 10.13, then the culprit is the OS, not LiveCode.
MacOS 10.13 is horrible. Sometimes the prefs of some Apps, not only LiveCode,
are reset to default in between working. What you describe sounds like that.

> Christer P. wrote:
> Question 1:
> What is the problem with getting the radio buttons "tick boxes" scalable?
> Trying to remember, I asked about it for a few years ago, and the answer by 
> LC team was, it is about the icon??
> I tried using switch button widgets, but the scaling of those isn't linear 
> (width / height) as any other objects.
> So, do I need to do my own radio buttons (i.e. use a round hilite button + 
> text button) or would there be another solution?
> 
> Question 2:
> LC 8.1.7 rc-3; there is instability in retaining setups.  For example, 
> upgrading from the previous G version the path to SDK was lost.  Also various 
> setups seem to move, the background of the screen goes all grey.  Anyone 
> experiencing oddities like this?

___
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

Radio button scaling

[Pyyhtiä Christer via use-livecode]

1.  Question 1:

What is the problem with getting the radio buttons "tick boxes" scalable?

Trying to remember, I asked about it for a few years ago, and the answer by LC 
team was, it is about the icon??

I tried using switch button widgets, but the scaling of those isn't linear 
(width / height) as any other objects.

So, do I need to do my own radio buttons (i.e. use a round hilite button + text 
button) or would there be another solution?

2.  Question 2:

LC 8.1.7 rc-3; there is instability in retaining setups.  For example, 
upgrading from the previous G version the path to SDK was lost.  Also various 
setups seem to move, the background of the screen goes all grey.  Anyone 
experiencing oddities like this?


Christer Pyyhtiä
chris...@mindcrea.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