Re: Size of Image in RAM

2017-02-07 Thread Scott Rossi via use-livecode
If your image was 256 colors, the Index > Mode menu would show Indexed Color 
checked, instead of RGB Color.

The RGB/8 Bit you’re seeing in the Photoshop menu actually reads “8 
Bits/Channel” — an RGB image is 3 channels (red, green, blue), 8 bits each, so 
24 bit color.

Again, if you really want your image limited to 256 colors, convert it to 
Indexed Color and save as PNG or GIF.

Regards,

Scott Rossi 
Creative Director 
Tactile Media, UX/UI Design 

> On Feb 7, 2017, at 10:17 PM, Sannyasin Brahmanathaswami via use-livecode 
>  wrote:
> 
> @ Scott:
> 
> That's not what I get if I open this image in Photoshop.  (CC 2017)
> 
> 
> 
> 575 X 1000 
> 
> http://wiki.hindu.org/uploads/img37.jpg
> 
> 
> It is a JPEG, but under the mode menu it shows "RGB/8 Bit" and if I look 
> under indexed colors it says "256"  definitely not 16bit (in which case we 
> should see 65536 colors)
> 
> So, somehow this IS a JPG that at least reports in PS as 8 bit but shows it 
> is taking 2.17 MB in RAM, which it would if it were 16 bit.
> 
> Scott Rossi wrote:
> 
>When I generate an 8 bit indexed color image in Photoshop and look at the 
> Save As menu, JPEG is not an option.  If I instead choose Save for Web which 
> allows saving as JPEG, the resulting image re-opens in Photoshop in RGB (24 
> bit color) mode.
> 
> But, and this is interesting: if I save as PNG Photoshop offers the option to 
> change turn off transparency and save as  bit… the resulting images on disk 
> is 1/3 bigger I size  (jpeg,:229K, png:353K)  But the former/jpg opens in 
> photoshop at 2.17MB and not the 8-bit PNG opens at 739K in RAM  
> 
> This tends to confirm your theory and Photoshop is miss reporting the bit 
> depth on the jpg (or something!)  … very interesting. the PNG at half the 
> size in RAM is visually indistinquishable from the JPG (at least to my eyes)
> 
> http://wiki.hindu.org/uploads/img37.png
> 
> So we have a trade off: use 8 bit PNG and pack more data than we have room 
> for in the mobile app package. or optimize really small JPG's on disk that 
> then take up twice the room in RAM!
> 
> 
> 
> ___
> 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: Size of Image in RAM

2017-02-07 Thread hh via use-livecode
Scott is right:
JPEG has exactly one _color_ mode: 16M = 2^24 (seen apart of 256 gray-color 
mode).

What you interpret as "8bit-color-mode" relates to the _compression_ mode which
also explains the relation filesize vs (uncompressed) size in memory.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: Browser Widget Appears to be caching data (JavaScript)?

2017-02-07 Thread Sannyasin Brahmanathaswami via use-livecode
Are you serving this content yourself from your web server? If so there are 
"cb" (cache busting) methods already well worked out.

e.g. 

logo.jpg  # on disk
logo-cb123455678.jpg  # in the html code

and mod-rewrite handles the translation back to the original image. So you can 
update "logo.jpg" without changing it's name, but your content assembly system 
appends the cache busting string to the outgoing html… (Ralf does this in 
RevIgniter)

BR
 

On 2/6/17, 7:07 AM, "use-livecode on behalf of Ralph DiMola via use-livecode" 
 wrote:

To refresh a browser cache I put an argument on the URL that is different
from the last request and the cache will be invalidated. In LC I put
"=12345678" at the end of the URL arguments or if there are no
arguments then I put "?seconds=12345678" where "12345678" is the LC "the
seconds". This only helps if there is no more than 1 request per second. 

___
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: Size of Image in RAM

2017-02-07 Thread Sannyasin Brahmanathaswami via use-livecode
@ Scott:

That's not what I get if I open this image in Photoshop.  (CC 2017)



575 X 1000 

http://wiki.hindu.org/uploads/img37.jpg


It is a JPEG, but under the mode menu it shows "RGB/8 Bit" and if I look under 
indexed colors it says "256"  definitely not 16bit (in which case we should see 
65536 colors)

So, somehow this IS a JPG that at least reports in PS as 8 bit but shows it is 
taking 2.17 MB in RAM, which it would if it were 16 bit.

Scott Rossi wrote:

When I generate an 8 bit indexed color image in Photoshop and look at the 
Save As menu, JPEG is not an option.  If I instead choose Save for Web which 
allows saving as JPEG, the resulting image re-opens in Photoshop in RGB (24 bit 
color) mode.

But, and this is interesting: if I save as PNG Photoshop offers the option to 
change turn off transparency and save as  bit… the resulting images on disk is 
1/3 bigger I size  (jpeg,:229K, png:353K)  But the former/jpg opens in 
photoshop at 2.17MB and not the 8-bit PNG opens at 739K in RAM  

This tends to confirm your theory and Photoshop is miss reporting the bit depth 
on the jpg (or something!)  … very interesting. the PNG at half the size in RAM 
is visually indistinquishable from the JPG (at least to my eyes)

http://wiki.hindu.org/uploads/img37.png

So we have a trade off: use 8 bit PNG and pack more data than we have room for 
in the mobile app package. or optimize really small JPG's on disk that then 
take up twice the room in RAM!



___
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: Size of Image in RAM

2017-02-07 Thread Scott Rossi via use-livecode
You say the mode is 8 bit.  I might be wrong, but I don’t believe JPEG supports 
8 bit (256 color) images.  Even if it does technically, the format is not 
really intended for 8 bit images, but rather 16 bit or higher.

When I generate an 8 bit indexed color image in Photoshop and look at the Save 
As menu, JPEG is not an option.  If I instead choose Save for Web which allows 
saving as JPEG, the resulting image re-opens in Photoshop in RGB (24 bit color) 
mode.

So as I read question, you’re getting a 24 bit image because you’re saving in 
JPEG format.

If you really want to save as 8 bit color, use PNG or GIF.

Regards,

Scott Rossi 
Creative Director 
Tactile Media, UX/UI Design 

> On Feb 7, 2017, at 7:45 PM, Sannyasin Brahmanathaswami via use-livecode 
>  wrote:
> 
> I'm trying to optimize for Mobile.  Photoshop is playing tricks on me
> 
> given a 38K  jpg;
> 
> rect 3 X 5
> 
> 552px w
> 736 px h
> 72 dpi (irrelevant for screen)
> 
> Open in Photoshop: it indicates 1.16M in RAM, but mode is 8 bit… but
> 
> but the online calculation sites for file size for that rect/bit-depth should 
> make it only take up 398k or so, in RAM.
> 
> If I change the online calculator for that rect to "24 bit" it returns the 
> exactly size  (1.16M) I'm seeing in photoshop…roughly 3X the size of the 8 
> bit, which is what we would expect.
> 
> So
> 
> 1) Why is Photoshop reporting the files size as if it were 24 bit? and
> 2) Does LC have a function to check the size of an image in terms of RAM 
> consumed? I couldn't find one in the dictionary.
> 
> BR  (thinking about affinity these days!)
> ___
> 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: Size of Image in RAM

2017-02-07 Thread Peter Bogdanoff via use-livecode
I think I can answer the Photoshop question. It seems that 1.6 Mb size is the 
file size for PS to do its work in the application. If you save that file as a 
.psd, I suspect you’ll see a file size of 1.6 Mb.

I find the Save for Web dialog (in the File>Export menu) useful. You can choose 
the file type, compression amount, and see the original and compressed file 
size there.

Peter
 
> On Feb 7, 2017, at 10:45 PM, Sannyasin Brahmanathaswami via use-livecode 
>  wrote:
> 
> I'm trying to optimize for Mobile.  Photoshop is playing tricks on me
> 
> given a 38K  jpg;
> 
> rect 3 X 5
> 
> 552px w
> 736 px h
> 72 dpi (irrelevant for screen)
> 
> Open in Photoshop: it indicates 1.16M in RAM, but mode is 8 bit… but
> 
> but the online calculation sites for file size for that rect/bit-depth should 
> make it only take up 398k or so, in RAM.
> 
> If I change the online calculator for that rect to "24 bit" it returns the 
> exactly size  (1.16M) I'm seeing in photoshop…roughly 3X the size of the 8 
> bit, which is what we would expect.
> 
> So
> 
> 1) Why is Photoshop reporting the files size as if it were 24 bit? and
> 2) Does LC have a function to check the size of an image in terms of RAM 
> consumed? I couldn't find one in the dictionary.
> 
> BR  (thinking about affinity these days!)
> ___
> 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

Size of Image in RAM

2017-02-07 Thread Sannyasin Brahmanathaswami via use-livecode
I'm trying to optimize for Mobile.  Photoshop is playing tricks on me

given a 38K  jpg;

rect 3 X 5

552px w
736 px h
72 dpi (irrelevant for screen)

Open in Photoshop: it indicates 1.16M in RAM, but mode is 8 bit… but

but the online calculation sites for file size for that rect/bit-depth should 
make it only take up 398k or so, in RAM.

If I change the online calculator for that rect to "24 bit" it returns the 
exactly size  (1.16M) I'm seeing in photoshop…roughly 3X the size of the 8 bit, 
which is what we would expect.

So

1) Why is Photoshop reporting the files size as if it were 24 bit? and
2) Does LC have a function to check the size of an image in terms of RAM 
consumed? I couldn't find one in the dictionary.

BR  (thinking about affinity these days!)
___
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: Help: Does anyone use legacy message box behavior?

2017-02-07 Thread Richard Gaskin via use-livecode

Monte Goulding wrote:

>> On 8 Feb 2017, at 11:02 am, Richard Gaskin wrote:
>>
>> Monte Goulding wrote:
>> > ...You might think we don’t need to touch it but it has
>> > been touched recently because of a change in the way we
>> > retain object references.
>>
>> Now I'm curious: anything interesting there in terms of features,
> performance, or memory handling?
>
> The main advantage is stability.

That's a feature.  And a good one.  In my community meeting with Peter 
last week he outlined some of the effort going into v9 stability 
improvements, and I was quite impressed.


> You might remember that in one of the early 8 releases (not sure
> which one as it was just before I started) the memory management
> of objects changed so they would be released sooner if deleted
> within tight script loops instead of waiting for the next main
> loop to released them. It was a response to a bug where creating
> and deleting lots of objects in a loop bloated memory use I believe.
> Well deleting them earlier resulted in *lots* of instability where
> there were references to objects (say the internal defaultStack
> global for example) but the object had been deleted. Things like
> scripts still executing on objects that are meant to be deleted
> or setting the defaultStack to a stack that has just been deleted.
> Anyway in order to make it easier for us to resolve these issues
> Fraser wrote a class to use as an object handle whenever we want
> to keep a reference to an object. So now we can do stuff like
> t_stack.IsValid() before doing something with t_stack.
>
> For example one crash that I just fixed is this one: 
https://github.com/livecode/livecode/pull/5143 


>
> In that crash we were getting the stack of an object when it is being
> sent a message then using it later but the particular crashing code
> was deleting the stack the target object was on in a frontScript
> which was executed between getting the reference to the stack and
> using it. So the change now uses an object handle so we can check
> it’s still valid before sending the message after the frontScripts
> are executed ;-)

Sounds like a very good change.  Thanks for that background.  Even 
though I almost never write in C anymore, that under-the-hood stuff is 
very helpful for understanding how the engine works.




>> Thanks for running this by the community.
>
> It’s worth remembering that almost all of what we do is run by the
> community because everyone is free to subscrib to our github feed
> and comment on our PRs.

An excellent reminder.  The Github tools have made the process 
wonderfully visible.


--
 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: Help: Does anyone use legacy message box behavior?

2017-02-07 Thread Monte Goulding via use-livecode

> On 8 Feb 2017, at 11:02 am, Richard Gaskin via use-livecode 
>  wrote:
> 
> Monte Goulding wrote:
> 
> >> On 8 Feb 2017, at 3:04 am, Richard Gaskin wrote:
> >>
> >> My Message Box replacement sets the revMessageBox redirect to empty
> >> when it closes, and after doing so the LC IDE Message Box resumes
> >> normal behavior.
> >
> > Yes it does use it but it also (at least the single line msg box)
> > happens to conform to the old spec too (stack is named “Message
> > Box”). Also it sets it when loading the message box so that might
> > be fixing it for you.
> >>
> >> Is it necessary to remove the old behavior?
> >
> > Not overly so, however, every line removed is something we don’t
> > need to waste time maintaining. You might think we don’t need to
> > touch it but it has been touched recently because of a change in
> > the way we retain object references.
> 
> Now I'm curious: anything interesting there in terms of features, 
> performance, or memory handling?

The main advantage is stability. You might remember that in one of the early 8 
releases (not sure which one as it was just before I started) the memory 
management of objects changed so they would be released sooner if deleted 
within tight script loops instead of waiting for the next main loop to released 
them. It was a response to a bug where creating and deleting lots of objects in 
a loop bloated memory use I believe. Well deleting them earlier resulted in 
*lots* of instability where there were references to objects (say the internal 
defaultStack global for example) but the object had been deleted. Things like 
scripts still executing on objects that are meant to be deleted or setting the 
defaultStack to a stack that has just been deleted. Anyway in order to make it 
easier for us to resolve these issues Fraser wrote a class to use as an object 
handle whenever we want to keep a reference to an object. So now we can do 
stuff like t_stack.IsValid() before doing something with t_stack.

For example one crash that I just fixed is this one: 
https://github.com/livecode/livecode/pull/5143 


In that crash we were getting the stack of an object when it is being sent a 
message then using it later but the particular crashing code was deleting the 
stack the target object was on in a frontScript which was executed between 
getting the reference to the stack and using it. So the change now uses an 
object handle so we can check it’s still valid before sending the message after 
the frontScripts are executed ;-)
> 
> 
> > BTW our internal discussions have led us to consider dropping the
> > message box redirect entirely and just sending msgChanged to the
> > defaultStack which is inline with other messages. The less special
> > cases in the way we do things the better. The IDE pubsub library
> > can dispatch ideMsgChanged to any subscribers and they can do what
> > they like. If it’s unhandled or passed to the engine then it can be
> > sent to the appropriate system logs (or stdout… not sure which just
> > yet and perhaps will depend on if its in no ui mode as there’s a
> > legacy there).
> 
> My first inclination would be as you'd anticipated, that it would be such a 
> low priority as to be barely worth the net trade-off of trimming some code in 
> one place while writing other code elsewhere.
> 
> But if we're at last in a place where the IDE spec we're working with will 
> finally settle down, I'm okay with rewriting my stuff to work with it.
> 
> And best of all, since both the IDE code and our code will be coming from an 
> engine-borne message (I like msgChanged), I have options for how I handle 
> that, either through the IDE pubsub or in a well-managed frontscript as all 
> my other tools tend to use (which is why they don't generally break with IDE 
> changes ), and that freedom is as important to me as being able to rely on 
> the message within a standalone when I need to do that too.
> 
> In short, go for it. :)

;-) OK

> 
> Thanks for running this by the community.

It’s worth remembering that almost all of what we do is run by the community 
because everyone is free to subscrib to our github feed and comment on our PRs.

Cheers

Monte
___
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: Help: Does anyone use legacy message box behavior?

2017-02-07 Thread Richard Gaskin via use-livecode

Monte Goulding wrote:

>> On 8 Feb 2017, at 3:04 am, Richard Gaskin wrote:
>>
>> My Message Box replacement sets the revMessageBox redirect to empty
>> when it closes, and after doing so the LC IDE Message Box resumes
>> normal behavior.
>
> Yes it does use it but it also (at least the single line msg box)
> happens to conform to the old spec too (stack is named “Message
> Box”). Also it sets it when loading the message box so that might
> be fixing it for you.
>>
>> Is it necessary to remove the old behavior?
>
> Not overly so, however, every line removed is something we don’t
> need to waste time maintaining. You might think we don’t need to
> touch it but it has been touched recently because of a change in
> the way we retain object references.

Now I'm curious: anything interesting there in terms of features, 
performance, or memory handling?



> BTW our internal discussions have led us to consider dropping the
> message box redirect entirely and just sending msgChanged to the
> defaultStack which is inline with other messages. The less special
> cases in the way we do things the better. The IDE pubsub library
> can dispatch ideMsgChanged to any subscribers and they can do what
> they like. If it’s unhandled or passed to the engine then it can be
> sent to the appropriate system logs (or stdout… not sure which just
> yet and perhaps will depend on if its in no ui mode as there’s a
> legacy there).

My first inclination would be as you'd anticipated, that it would be 
such a low priority as to be barely worth the net trade-off of trimming 
some code in one place while writing other code elsewhere.


But if we're at last in a place where the IDE spec we're working with 
will finally settle down, I'm okay with rewriting my stuff to work with it.


And best of all, since both the IDE code and our code will be coming 
from an engine-borne message (I like msgChanged), I have options for how 
I handle that, either through the IDE pubsub or in a well-managed 
frontscript as all my other tools tend to use (which is why they don't 
generally break with IDE changes ), and that freedom is as important 
to me as being able to rely on the message within a standalone when I 
need to do that too.


In short, go for it. :)

Thanks for running this by the community.

--
 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: Nested groups

2017-02-07 Thread Richard Gaskin via use-livecode

J. Landman Gay wrote:

>> On 2/7/2017 5:01 PM, J. Landman Gay via use-livecode wrote:
> Curiosity question: Do multiple nested groups (3 or 4 levels deep)
> affect CPU and memory performance? Are fewer nested groups easier
> on the engine?
...
> I'm working with a stack that has some memory issues which includes
> many image-rich nested groups. I don't think this is contributing
> directly to the problem but wondered if reducing the number of
> groups might help.

For both performance and memory, each object adds some overhead.  But 
the group object would seem slim in both respects, so I wouldn't imagine 
an extra level of nesting would make much difference either performance 
or RAM.


Images, however, are among the most RAM-intensive objects LC handles. 
Each exists at least initially in its compressed form, then in its 
unpacked bitmap form when rendered (width * height * color depth, 
possibly also + alpha width * height if PNG), and often both exist at 
the same time.


If there's a way to reduce the number of images, or their size, or their 
quality (if JPEG), you'll likely get much farther with reducing memory 
requirements than by removing groups.


--
 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: Nested groups

2017-02-07 Thread Paul Dupuis via use-livecode
On 2/7/2017 5:19 PM, J. Landman Gay via use-livecode wrote:
> On 2/7/17 4:07 PM, Paul Dupuis via use-livecode wrote:
>> On 2/7/2017 5:01 PM, J. Landman Gay via use-livecode wrote:
>>> On 2/7/17 2:13 PM, Richard Gaskin via use-livecode wrote:
 J. Landman Gay wrote:

> Curiosity question: Do multiple nested groups (3 or 4 levels deep)
> affect CPU and memory performance? Are fewer nested groups easier
> on the engine?

 Because they effectively deepen the message path, I'd wager there is
 some difference, at least in terms of initializing the message path as
 the objects are unpacked before preOpenCard.

 That said, given the speed of the natural message path I'd wager it
 would be small enough to be unnoticeable, and perhaps even
 difficult to
 measure.

>>>
>>> I was thinking about the amount of redrawing the engine would need to
>>> do to render them.
>>>
>>
>> I have a number of stack with a lot of controls in multiple nested
>> groups. For me, the groups are primarily for organizing objects on the
>> card so I can find what I am looking for as a developer. OR when I want
>> to move a set of related control around. In all such cases, I have never
>> noticed a visible difference in rendering of the cards vs card with few
>> groups or fewer controls in a similar number of groups.
>>
>> This is just human perception. I have never timed renderings to compare.
>
> Thanks. I'm working with a stack that has some memory issues which
> includes many image-rich nested groups. I don't think this is
> contributing directly to the problem but wondered if reducing the
> number of groups might help.
>

My guess is it is more probably related to the number of images than the
number of groups. I am NOT very knowledgeable about all the details of
image optimization in LiveCode, but there are people on the list who are.



___
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: Nested groups

2017-02-07 Thread J. Landman Gay via use-livecode

On 2/7/17 4:07 PM, Paul Dupuis via use-livecode wrote:

On 2/7/2017 5:01 PM, J. Landman Gay via use-livecode wrote:

On 2/7/17 2:13 PM, Richard Gaskin via use-livecode wrote:

J. Landman Gay wrote:


Curiosity question: Do multiple nested groups (3 or 4 levels deep)
affect CPU and memory performance? Are fewer nested groups easier
on the engine?


Because they effectively deepen the message path, I'd wager there is
some difference, at least in terms of initializing the message path as
the objects are unpacked before preOpenCard.

That said, given the speed of the natural message path I'd wager it
would be small enough to be unnoticeable, and perhaps even difficult to
measure.



I was thinking about the amount of redrawing the engine would need to
do to render them.



I have a number of stack with a lot of controls in multiple nested
groups. For me, the groups are primarily for organizing objects on the
card so I can find what I am looking for as a developer. OR when I want
to move a set of related control around. In all such cases, I have never
noticed a visible difference in rendering of the cards vs card with few
groups or fewer controls in a similar number of groups.

This is just human perception. I have never timed renderings to compare.


Thanks. I'm working with a stack that has some memory issues which 
includes many image-rich nested groups. I don't think this is 
contributing directly to the problem but wondered if reducing the number 
of groups might help.


--
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: Help: Does anyone use legacy message box behavior?

2017-02-07 Thread Monte Goulding via use-livecode

> On 8 Feb 2017, at 3:04 am, Richard Gaskin via use-livecode 
>  wrote:
> 
> I sent this a while ago, and oddly enough another message I'd sent lae came 
> in but this one did not.
> 
> After thinking about this some more, I wonder:  are you sure the LC IDE 
> doesn't rely on this?
> 
> My Message Box replacement sets the revMessageBox redirect to empty when it 
> closes, and after doing so the LC IDE Message Box resumes normal behavior.

Yes it does use it but it also (at least the single line msg box) happens to 
conform to the old spec too (stack is named “Message Box”). Also it sets it 
when loading the message box so that might be fixing it for you.
> 
> Is it necessary to remove the old behavior?

Not overly so, however, every line removed is something we don’t need to waste 
time maintaining. You might think we don’t need to touch it but it has been 
touched recently because of a change in the way we retain object references.

BTW our internal discussions have led us to consider dropping the message box 
redirect entirely and just sending msgChanged to the defaultStack which is 
inline with other messages. The less special cases in the way we do things the 
better. The IDE pubsub library can dispatch ideMsgChanged to any subscribers 
and they can do what they like. If it’s unhandled or passed to the engine then 
it can be sent to the appropriate system logs (or stdout… not sure which just 
yet and perhaps will depend on if its in no ui mode as there’s a legacy there).

Cheers

Monte
___
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: Nested groups

2017-02-07 Thread Paul Dupuis via use-livecode
On 2/7/2017 5:01 PM, J. Landman Gay via use-livecode wrote:
> On 2/7/17 2:13 PM, Richard Gaskin via use-livecode wrote:
>> J. Landman Gay wrote:
>>
>>> Curiosity question: Do multiple nested groups (3 or 4 levels deep)
>>> affect CPU and memory performance? Are fewer nested groups easier
>>> on the engine?
>>
>> Because they effectively deepen the message path, I'd wager there is
>> some difference, at least in terms of initializing the message path as
>> the objects are unpacked before preOpenCard.
>>
>> That said, given the speed of the natural message path I'd wager it
>> would be small enough to be unnoticeable, and perhaps even difficult to
>> measure.
>>
>
> I was thinking about the amount of redrawing the engine would need to
> do to render them.
>

I have a number of stack with a lot of controls in multiple nested
groups. For me, the groups are primarily for organizing objects on the
card so I can find what I am looking for as a developer. OR when I want
to move a set of related control around. In all such cases, I have never
noticed a visible difference in rendering of the cards vs card with few
groups or fewer controls in a similar number of groups.

This is just human perception. I have never timed renderings to compare.


___
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: Nested groups

2017-02-07 Thread J. Landman Gay via use-livecode

On 2/7/17 2:13 PM, Richard Gaskin via use-livecode wrote:

J. Landman Gay wrote:


Curiosity question: Do multiple nested groups (3 or 4 levels deep)
affect CPU and memory performance? Are fewer nested groups easier
on the engine?


Because they effectively deepen the message path, I'd wager there is
some difference, at least in terms of initializing the message path as
the objects are unpacked before preOpenCard.

That said, given the speed of the natural message path I'd wager it
would be small enough to be unnoticeable, and perhaps even difficult to
measure.



I was thinking about the amount of redrawing the engine would need to do 
to render them.


--
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: Different result in LC 6 to LC 8 when copying field text into Excel?

2017-02-07 Thread Paul Hibbert via use-livecode
Tiemo,

I’m not sure if this will help because I’m testing on Mac, but I did a little 
bit of experimenting with the new ‘rawClipboardData’, it allows plain text to 
be copied out of LC, just to prove it, here’s a button script copied via my now 
modified Script Buddy plugin…

on mouseUp
   local tClip

   if the selectedText is empty then
  set the clipBoardData["text"] to fld “myTextField"
   else
  copy the selectedText
   end if
   
   if the altKey is down then -- Convert the clipBoard to plain text
  put the clipBoardData["text"] into tClip
  lock the clipBoard
  ## Use some code lifted from the LiveCode Dictionary…
  set the rawClipBoardData to empty -- Clear ALL ClipboardData
  if the platform is "Linux" then set the 
rawClipboardData["text/plain;charset=utf-8"] \
to textEncode(tClip, "UTF-8" ) -- Linux
  if the platform is "Win32" then set the rawClipboardData["CF_UNICODE"] \
to textEncode(tClip, "UTF-16" ) -- Windows
  if the platform is "MacOS" then set the 
rawClipboardData["public.utf8-plain-text"] \
to textEncode(tClip, "UTF-8" ) -- OSX
  unlock the clipboard
   end if
end mouseUp

At last, no extra line spacing! :-)

Normally when I paste from LC into Mail I see extra line spacing, and I would 
have to copy and paste via a plain text editor to remove it. Emptying the 
clipBoard and setting the rawClipboardData as above seems to work, on Mac at 
least, hopefully it should work with Excel on Windows too.

Paul




> On Feb 3, 2017, at 6:25 AM, Tiemo Hollmann TB via use-livecode 
>  wrote:
> 
> Can anybody on Windows with LC 8 confirm this:
> 
> - create a new stack
> - create a scrolling list field
> - enter three lines of text, each with one word
> - enter into the message box: *set the clipboarddata["text"] to fld 1*
> - open MS Excel (in my case Windows 10, Excel 2013)
> - paste
> - see an extra empty line between each line of text
> 
> Pasted in a text editor there are no extra lines and up to LC 7 there also
> was no extra line in Excel.
> 
> Can anybody confirm this behavior or even has an idea for a workaround?
> 
> Thanks
> Tiemo
> 
> 
> 
> -Ursprüngliche Nachricht-
> Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag
> von Tiemo Hollmann TB via use-livecode
> Gesendet: Donnerstag, 2. Februar 2017 12:13
> An: LiveCode User Liste senden 
> Cc: Tiemo Hollmann TB 
> Betreff: Different result in LC 6 to LC 8 when copying field text into
> Excel?
> 
> Hello,
> 
> I have a standard scrolling list field with multiple lines of text. I copy
> the text by:
> 
> *set the clipboarddata["text"] to fld "List"*
> 
> The User now can past the text into MS Excel on Windows. With LC 6 the text
> was pasted into Excel line by line, as it showed up in LC. In LC 8.1.2 the
> text is pasted with an extra space line between each two lines.
> 
> I checked the line ends in both versions. There is only one "LF"
> (byteToNum=10) at the end of each line and it looks the same in both
> versions.
> 
> What has changed in LC 8 to cause such a different behavior? Is this again a
> Unicode thing what I don't understand? I already tried different
> clipboarddata keys, without success.
> 
> It can't be an Excel option, because I tested it with the same Excel version
> on the same machine.
> 
> Any idea, what has to be changed to get the same clipboard result as in LC
> 6?
> 
> Thank you
> 
> Tiemo
> 
> 
> 
> 
> 
> ___
> 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: [OT] DevDocs.io doesn't have "LiveCode"

2017-02-07 Thread AndyP via use-livecode
Thanks for the pointer to  https://devdocs.io/   

I haven't come across this before...great resource



-
Andy Piddock 


My software never has bugs. It just develops random features. 

TinyIDE a Free alternative minimalist IDE Plugin for LiveCode
TinyIDE 


Script editor Themer for LC http://2108.co.uk  

PointandSee is a FREE simple but full featured under cursor colour picker / 
finder.
http://www.pointandsee.co.uk  - made with LiveCode
--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/OT-DevDocs-io-doesn-t-have-LiveCode-tp4712281p4712286.html
Sent from the Revolution - User mailing list archive at Nabble.com.

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


Re: Nested groups

2017-02-07 Thread Richard Gaskin via use-livecode

J. Landman Gay wrote:

> Curiosity question: Do multiple nested groups (3 or 4 levels deep)
> affect CPU and memory performance? Are fewer nested groups easier
> on the engine?

Because they effectively deepen the message path, I'd wager there is 
some difference, at least in terms of initializing the message path as 
the objects are unpacked before preOpenCard.


That said, given the speed of the natural message path I'd wager it 
would be small enough to be unnoticeable, and perhaps even difficult to 
measure.


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


Fwd: Re: Help: Does anyone use legacy message box behavior?

2017-02-07 Thread Richard Gaskin via use-livecode
I sent this a while ago, and oddly enough another message I'd sent lae 
came in but this one did not.


After thinking about this some more, I wonder:  are you sure the LC IDE 
doesn't rely on this?


My Message Box replacement sets the revMessageBox redirect to empty when 
it closes, and after doing so the LC IDE Message Box resumes normal 
behavior.


I don't mind modifying mine if needed, but since an empty revMessageBox 
redirect allows the LC IDE to resume use of its own Message Box, and 
since the LC IDE's Message Box stack is still named "Message Box", it 
would seem the engine behavior you describe is still in use.


Please let me know if I misunderstand.  But FWIW one nice thing about 
that behavior is that it keeps things simple, allowing a useful default 
in the IDE even if the revMessageBoxRedirect is set to not restored to a 
valid field reference.


Is it necessary to remove the old behavior?

- rg


 Forwarded Message 
Subject: Re: Help: Does anyone use legacy message box behavior?
Date: Tue, 7 Feb 2017 07:37:30 -0800
From: Richard Gaskin 
To: use-livecode@lists.runrev.com

Monte Goulding wrote:


I’m in the midst of making the message box redirect work in all
engines (https://github.com/livecode/livecode/pull/5156
) and it would seem
that there’s a legacy message box behavior that could be removed from
the engine. It’s not used by the IDE. The behavior is if no message
box redirect is set then it looks for a stack named “Message Box”,
sets the text of the first field then raises the stack. As this is
only an IDE thing I strongly suspect we are ok to remove the code
but while I’m waiting for the team to wake up in Scotland I thought
I’d check here!

It would be easy to work around even if you have been depending on it
because it’s just setting the property and then handling msgChanged
to put msg where ever you want.


IIRC what you describe is the original engine behavior which drove the 
MC IDE.  I believe that was also used by early versions of the LC IDE.


The revMessageBoxRedirect global property was a solution added to 
satisfy a request I had for being able to use the MC IDE as a plugin 
within LC.  If the LC IDE now also uses that property itself that would 
seem a cleaner implementation.


Removing the engine behavior you describe will break the MC IDE, but 
given how few people use it these days I don't think that should be a 
reason to clutter the code base.  Those interested could easily add the 
one line of code needed to use revMessageBoxRedirect instead.


Personally, I don't use anything dependent on the older behavior, but I 
do use revMessageBoxRedirect very extensively; among other things I've 
been using a custom Terminal-like Message Box replacement for years.


Being able to use my custom Message Box in a standalone would be a 
godsend.  If removing the old behavior makes a cleaner way to do that I 
say go for it.


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

Nested groups

2017-02-07 Thread J. Landman Gay via use-livecode
Curiosity question: Do multiple nested groups (3 or 4 levels deep) 
affect CPU and memory performance? Are fewer nested groups easier on the 
engine?


--
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: [OT] DevDocs.io doesn't have "LiveCode"

2017-02-07 Thread Mike Kerner via use-livecode
Part of my "attack the docs" project (
http://forums.livecode.com/viewtopic.php?f=67=28731) includes doing this,
so please add your voice and your ideas over there.

There are several important functions within LC that maybe should be
outsourced so the team can work on what I think are more important tasks,
(like adding functionality and platforms, and completing the support for
some of the underserved existing platforms).
1) Documentation rendering - there are several of these, and different
people might like different ones.  Why not make the documentation work with
several of the more popular ones, and get the metadata into a form that
will make it easy to add more?
2) Code editing - Do we like the LC script editor better than one of the
editors that folks are using to work on lcs files?
3) There are a multitude of layout and prototyping tools, and subscription
services from artists and designers who are creating objects and themes
that would be wonderful to use.  Why not use one of those tools to make our
projects more beautiful?


On Tue, Feb 7, 2017 at 1:51 PM, Roger Eller via use-livecode <
use-livecode@lists.runrev.com> wrote:

>  This is another place where LiveCode could receive some great exposure, if
> represented.
>
> A great resource for many language API docs in one convenient location.
>
> https://devdocs.io/
>
> ~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
>



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


[OT] DevDocs.io doesn't have "LiveCode"

2017-02-07 Thread Roger Eller via use-livecode
 This is another place where LiveCode could receive some great exposure, if
represented.

A great resource for many language API docs in one convenient location.

https://devdocs.io/

~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: Checking out the "Resources" button in LC9

2017-02-07 Thread Richmond Mathewson via use-livecode
I'm trying to keep off the LiveCode for a day :)

On Tue, Feb 7, 2017 at 3:18 PM, Thomas McGrath III via use-livecode <
use-livecode@lists.runrev.com> wrote:

> By the way, Happy Birthday Richmond!!!
>
> Hope you have a great day.
>
> Tom McGrath
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 

This communication may be unlawfully collected and stored by the Agents
of a large number of governments in secret. The parties to this email do
not consent to the retrieving or storing of this communication and any
related metadata, as well as printing, copying, re-transmitting,
disseminating, or otherwise using it. If you believe you have received
this communication in error, please delete it immediately.
___
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: Help: Does anyone use legacy message box behavior?

2017-02-07 Thread Richard Gaskin via use-livecode

Monte Goulding wrote:

> I’m in the midst of making the message box redirect work in all
> engines (https://github.com/livecode/livecode/pull/5156
> ) and it would seem
> that there’s a legacy message box behavior that could be removed from
> the engine. It’s not used by the IDE. The behavior is if no message
> box redirect is set then it looks for a stack named “Message Box”,
> sets the text of the first field then raises the stack. As this is
> only an IDE thing I strongly suspect we are ok to remove the code
> but while I’m waiting for the team to wake up in Scotland I thought
> I’d check here!
>
> It would be easy to work around even if you have been depending on it
> because it’s just setting the property and then handling msgChanged
> to put msg where ever you want.

IIRC what you describe is the original engine behavior which drove the 
MC IDE.  I believe that was also used by early versions of the LC IDE.


The revMessageBoxRedirect global property was a solution added to 
satisfy a request I had for being able to use the MC IDE as a plugin 
within LC.  If the LC IDE now also uses that property itself that would 
seem a cleaner implementation.


Removing the engine behavior you describe will break the MC IDE, but 
given how few people use it these days I don't think that should be a 
reason to clutter the code base.  Those interested could easily add the 
one line of code needed to use revMessageBoxRedirect instead.


Personally, I don't use anything dependent on the older behavior, but I 
do use revMessageBoxRedirect very extensively; among other things I've 
been using a custom Terminal-like Message Box replacement for years.


Being able to use my custom Message Box in a standalone would be a 
godsend.  If removing the old behavior makes a cleaner way to do that I 
say go for it.


--
 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: Help: Does anyone use legacy message box behavior?

2017-02-07 Thread Richard Gaskin via use-livecode

Graham Samuel wrote:

> ...how would you use this feature, specifically in debugging a
> standalone, and what’s wrong with it now?

The revMessageBox redirect allows you to use any field to display data 
that would otherwise go to LC's Message Box; that is, any "put" without 
a specified destination.


When combined with an input field for triggering commands and querying 
functions and properties, you can effectively make a satisfyingly 
full-featured Message Box replacement.


This allows you to query information at runtime in a standalone.

When these fields are part of a separate window they can be useful in 
desktop apps, but they can also be contained within a group, which could 
be shown and hidden as needed, for debugging in mobile apps as well.


I had thought revMessageBoxRedirect was already part of the standalone 
engine, but apparently not.  Making it available to standalones opens up 
very flexible options for poking around in a LC app.


--
 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: Help: Does anyone use legacy message box behavior?

2017-02-07 Thread Bob Sneidar via use-livecode
what the heck is that?

Bob S


On Feb 6, 2017, at 19:28 , Monte Goulding via use-livecode 
> wrote:

message box redirect

___
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: Checking out the "Resources" button in LC9

2017-02-07 Thread Thomas McGrath III via use-livecode
By the way, Happy Birthday Richmond!!!

Hope you have a great day.

Tom McGrath

___
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: Help: Does anyone use legacy message box behavior?

2017-02-07 Thread Graham Samuel via use-livecode
Forgive my stupidity, but how would you use this feature, specifically in 
debugging a standalone, and what’s wrong with it now?

TIA

Graham

> On 7 Feb 2017, at 07:16, J. Landman Gay via use-livecode 
>  wrote:
> 
> On 2/6/17 9:28 PM, Monte Goulding via use-livecode wrote:
>> Hi Folks
>> 
>> I’m in the midst of making the message box redirect work in all
>> engines (https://github.com/livecode/livecode/pull/5156
>> ) and it would seem
>> that there’s a legacy message box behavior that could be removed from
>> the engine. It’s not used by the IDE. The behavior is if no message
>> box redirect is set then it looks for a stack named “Message Box”,
>> sets the text of the first field then raises the stack. As this is
>> only an IDE thing I strongly suspect we are ok to remove the code but
>> while I’m waiting for the team to wake up in Scotland I thought I’d
>> check here!
>> 
>> It would be easy to work around even if you have been depending on it
>> because it’s just setting the property and then handling msgChanged
>> to put msg where ever you want.
> 
> Do whatever it takes, I've been waiting for this for years. I could really 
> use it right now. Debugging standalones is an exercise in frustration.
> 
> -- 
> 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


___
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: Checking out the "Resources" button in LC9

2017-02-07 Thread Richmond Mathewson via use-livecode
That is interesting about the appendix!

And, taking advantage of that information and someone else's observation,
it might not be a bad thing if some apparently obsolete "organs" were
retuned and returned to full functionality (err, did I hear a small voice
softly calling
"application browser" ?) again?

Richmond.

On Feb 6, 2017 4:07 PM, "Bob Sneidar via use-livecode" <
use-livecode@lists.runrev.com> wrote:

> This is an unfortunate anology. I like you, were taught this in biology,
> but since then it seems medical science has discovered that the appendix is
> a functional organ.
>
> http://www.sciencefocus.com/news/what-does-appendix-do-
> lot-more-we-thought%E2%80%A6
>
> Bob S
>
>
> On Feb 6, 2017, at 02:47 , Richmond Mathewson via use-livecode <
> use-livecode@lists.runrev.com>
> wrote:
>
> LC 9 is a bit like a human being who has an appendix because millions of
> years ago his/her ancestors were eating a high fibre diet in the depths of
> the Pangean jungle: full of old, outdated stuff that has been overlooked in
> the relentess onward drive.
>
> Richmond.
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode