Re: Storing and saving a setting in a stand alone

[AndyP]

This restriction in Yosemite causes big issue if you want to hack the
LiveCode ide. On Windows the LC ide stacks are stored in a sub directory of
the users AppData folder which allows modifications to be made to the LC ide
stacks. You cannot now do this in Yosemite and it will prevent any plugins
utilities (including my Script Editor Themer) that need to amend the LC ide
from working correctly. 

A workaround which one of my customers is using is to move the whole LC app
bundle outside of the App directory but obviously this is not ideal.

Added this to  http://quality.runrev.com/show_bug.cgi?id=14295
  



-
Andy Piddock 


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

Copy the new cloud space, get your free 15GB space now:
Get Copy 


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/Storing-and-saving-a-setting-in-a-stand-alone-tp4687858p4687895.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: Possible insanity, or is it LC 7.0.1?

[Peter Alcibiades]

Yes, verified this - new stack, new button, put this script onto it, and this
is what it does.  This is Debian, 7.0 Community Edition.  Also verified it
in multiline message box and tried a couple of other things.

What is really weird is that if you just change 1.884956 to 1.88495, it
seems to run fine.  Also, if you change the +0 to +1 it seems to run fine
with 1.884956.

Then if you add 3 to the number as in 1.884956, ie 1.8849563 it runs fine
with +0.  Then if you change 1.884956 to 1.884955 it runs fine.

What on earth can it be?

Peter



Brahmanathaswami wrote
> You are not crazy and it's not just your machine
> 
> confirmed here Yosemite 10.10 LC 7.0.1
> 
> on mouseUp
>   put 1.884956 into tVar
>put value(tVar + 0)
> end mouseUp
> 
> button "Button": execution error at line 3 (value: error executing 
> expression) near "1.884956", char 1
> 
> BR
> 
> 
> 
> Graham Samuel wrote:
>> Thanks to those who replied. So, I am going crazy! I suppose it is
>> something very particular about my setup. I did find one other way to
>> show the anomaly, which was to put
>>
>>put 1.884956 into it; put value(it+0)
>>
>> this gives me the error
>> "Message execution error:
>> Error description: value: error executing expression
>> Hint: 1.884956"
> 
> ___
> use-livecode mailing list

> use-livecode@.runrev

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





--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Possible-insanity-or-is-it-LC-7-0-1-tp4687816p4687894.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: Script to Generate Concurrent Times

[William Prothero]

That is hilarious, in a gruesome way.
Bill
> On Jan 15, 2015, at 8:10 PM, Simon  wrote:
> 
> Then there is this;
> https://www.youtube.com/watch?v=-5wpm-gesOY
> 
> Simon
> 
> 
> 
> --
> View this message in context: 
> http://runtime-revolution.278305.n4.nabble.com/Script-to-Generate-Concurrent-Times-tp4687781p4687891.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


___
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: Storing and saving a setting in a stand alone

[J. Landman Gay]

On 1/15/2015 9:31 PM, Kay C Lan wrote:

Yes Scott,you are right it's still a valid method, but it's not a method
that works for all platforms and for a product who's key feature is that it
is cross platform, desktop and mobile, I see it being counter productive to
provide an example that isn't.


I'm a little confused. The bug we were talking about in this thread 
refers to a change in an OS X app's bundle structure, rather than where 
user data is stored. Apple changed where files should go in bundles, and 
to accomodate, LC now scans for our embedded files in a couple of places 
in order to keep our code the same on all platforms. The engine will 
manage file lookups behind the scenes so we can use the same file paths 
everywhere. It's a good solution but there's a bug where it doesn't 
always work. As soon as they fix that, our internal app paths will work 
consistently as they always have, on any OS.



Because everyone has rolled their own user data path handlers,
user data is being saved in the correct place, whether it's a txt file, a
data stack or one of the many other methods you mention.


The bug only applies to files that are stored as part of the app itself, 
like documentation, images, video, and peripheral stacks. Where we, as 
developers, store user data is a different thing. I haven't had any 
trouble with the splash stack method aside from needing the bundle file 
paths to be fixed in 6.7.


--
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: Script to Generate Concurrent Times

[Simon]

Then there is this;
https://www.youtube.com/watch?v=-5wpm-gesOY

Simon



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Script-to-Generate-Concurrent-Times-tp4687781p4687891.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

The Internet Date on Cento OS / LiveCode Server Returns Zulu Time

[Brahmanathaswami]

Anyone know

a) why Livecode returns zulu time (no UTC offset) for the internet date 
on a web server  in San Francisco?


b) how to fix that?

On my machine (HST)

the internet date returns:

Thu, 15 Jan 2015 18:00:57 -1000

And the web server (in SF) CentOS shell --- system itself returns the 
internet date off set with UTC -0800 which is correct for PST


[root@sat brahma]# date -R
Thu, 15 Jan 2015 20:02:05 -0800
[root@sat brahma]#


But from LiveCode Server, from my "dates.lc" script:


*The LiveCode Internet Date is: * Fri, 16 Jan 2015 03:53:14 + # Why 
Zulu time for a machine in San Franscisco?


*The shell returns, for Local time: San Francisco*: Thu, 15 Jan 2015 
19:53:14 -0800 #This is correct.



(see http://dev.himalayanacademy.com/tests/dates.lc)


Swasti Astu, Be Well!
Brahmanathaswami

Kauai's Hindu Monastery
www.HimalayanAcademy.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: Storing and saving a setting in a stand alone

[Kay C Lan]

On Fri, Jan 16, 2015 at 8:40 AM, Richard Gaskin 
wrote:

On the contrary, as the rest of your post points out, it's increasingly
> useful as OS file system permissions get ever more restrictive.
>

Yes Scott,you are right it's still a valid method, but it's not a method
that works for all platforms and for a product who's key feature is that it
is cross platform, desktop and mobile, I see it being counter productive to
provide an example that isn't.

Thanks Richard but I don't need your data path handlers because as you say,
everyone's written their own; which goes back to your original question and
my answer. Because everyone has rolled their own user data path handlers,
user data is being saved in the correct place, whether it's a txt file, a
data stack or one of the many other methods you mention.

This problem comes up when those new to programming and/or LC follow an
example How-To that doesn't work for all platforms and/or goes against OS
guidelines. Saving User Data is a basic app requirement, the example given
should work on ALL platforms.

IMO if the How-To example used one of the many other options, but one that
works on ALL platforms, then we'd get less 'How do I save User Data
questions'. Certainly less than 'How do I save my App and User Data in a
single location and still have it work'.
___
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: Script to Generate Concurrent Times

[Brahmanathaswami]

Roger Eller wrote:

So that's where the old saying, "your singing would bring a jersey cow to
tears" comes from.


LOL!

Hmmm back on topic:

Requirement: Generate current time list for a *future* time (for 
scheduled webinar)


OK,  so it is easy enough to get world time from the linux system.

and FYI: LC "internet date" is, happily, using the standard RFC 2822 
format  and we can invoke this also in the shell:


 -R, --rfc-2822
  output  date  and time in RFC 2822 format.  Example: Mon, 
07 Aug

  2006 12:34:56 -0600

Check it out now

http://dev.himalayanacademy.com/tests/dates.lc
---

?lc

# copied the list from html source at:
# http://www.timezoneconverter.com/cgi-bin/tzc.tzc  


put url "file:/home/devhap/public_html/tests/zones.txt" into tZones

repeat for each line x in tZones
 set the itemdel to "/"
 if (the number of items of x) = 1 then
 put x into tCity
 else
  put item 2 of x into tCity
 end if
  put x into $TZ
  put shell("date -R") into tDTstring
  put tCity&  ": "&  tDTstring&  "" after tWorldTimes
end repeat

 put tWorldTimes
-

but that doesn't actually meet my requirement.
Sure: We get all the times to answer "what time is it now?"

But what if I want to a future time e.g. February 1, 1:30PM HST

and get a list of all dates/times across the globe that are concurrent with 
that future date/time?

Maybe I'll ask that on Expert's Exchange... man timezone isn't getting me 
anything.

I suppose one algorithm using LC native timedate conversion tools could be.

(the future date in seconds) - (Current time in seconds local time) = 
advanceToFutureIncrement

repeat for each concurrent time for now for all cities
put (city[x] Time Right Now) + advanceToFutureIncrement  into 
tFutureWebinarTimeInCity[x]
put tFutureWebinarTimeInCity[x]  &  "" after tListOfNextWebinarTimes
end repeat

of course the above needs a bit more code, but not much more...

 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: Free IP Calculator

[Skip Kimpel]

That's a lot of notes to yourself :)

Thanks for sharing!

SKIP

> On Jan 15, 2015, at 6:17 PM, Bob Sneidar  wrote:
> 
> Change this line to:
> 
>  — usablecount
>  set the itemdelimiter to “.”
> 
> won’t work without it. Another note to self: Don’t try to modify code posted 
> in an email.
> 
> Bob S
> 
> 
> 
> On Jan 15, 2015, at 15:18 , Bob Sneidar 
> mailto:bobsnei...@iotecdigital.com>> wrote:
> 
>  -- usablecountset the itemdelimiter to "."
> 
> ___
> 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

Getting the URL out of

[Shawn Blc]

How would I go about getting a random URL out of an XML file like the
following?  There's several of these CDATA tags.



My brain is about to explode.
___
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 to solve "can't find stack" error

[Robert Brenstein]

On 14.01.2015 at 17:01 Uhr -0800 tbodine apparently wrote:

Hi all.

Looking for some insight here... I have a desktop program built in LC 6.5.1
that uses LC stacks as user files for storing user data in fields and
cprops. Mostly this works well. However, I get occasional Error Reports when
a few users have tried to reopen a file they created. Error type is "Chunk:
can't find stack". I know the file exists because the user just picked it
with the answer file command.

The error occurs at a line where I first read a cprop from the stack. And
the line just prior to that loads the stack with "go invisible to card 1 of
stack tFullFilePath"


Have you tried adding a check after the go command to see whether it 
is successful? Some versions of LC had issues with some chars in the 
path, for example. Does your file selector allows to pick only LC 
stacks?


RObert

___
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: Storing and saving a setting in a stand alone

[Richard Gaskin]

Kay C Lan wrote:

* It would probably be wise for RunRev to remove any mention of the Splash
Stack method on their how-to site as it is clearly not an approach that
should be used any more.


On the contrary, as the rest of your post points out, it's increasingly 
useful as OS file system permissions get ever more restrictive.


The only question is where to put the stack.

I could dig up my user data path handlers and post 'em, but I'd figured 
everyone already had their own.


But even with that there's the larger question of whether we really want 
to be saving data bound to the UI.


The anchor stack (as we called it back in the early '90s in the 
SuperCard world) design pattern is any standalone that contains only 
enough code to find some other stack that contains most of the UI.


Even when the UI is stored external to the app (a majority of the 
projects I'm working on now store the UI stacks on a server), the 
question of whether to bind data to the UI or store it in a separate 
file remains.


There are many reasons to separate data from UI, not the least of which 
is the freedom to update your app's UI without encumbering the user with 
a complicated export/import.


In our local user group we discussed how we might craft a library to 
make it easy for folks accustomed to storing data in UI stacks to 
externalize that data.


But not far into it we realized we all store data differently. 
Sometimes it's a delimited text file, sometimes it's in custom props in 
a stack file, sometimes it's in a database, other times in encoded array 
files.


Each method requires different handling methods, though we could 
conceivably craft a library to help populate a UI and manage data 
binding a la MVC, with each data store as a sort of plugin to handle the 
storage-specific mechanics in this framework.


And not far into that we realized no one wanted to even document such a 
system, let alone write it.  :)  It's very easy to craft ad hoc 
solutions for data, and orders of magnitude harder to craft a 
generalized solution for all possible apps.


But looking at the small corners of this, if a couple handlers for 
knowing the path to store files on OS X, Win and Linux would be helpful 
I can dig mine up.


--
 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: Storing and saving a setting in a stand alone

[Scott Rossi]

RunRev may need to edit the description of the method but why remove it?  What 
is preventing developers from placing their primary stacks in the Documents 
folder or any other writable folder?

AFAICT, using the splash stack technique is still valid, but you may not be 
able to save the stack in as many locations as was previously possible.

Regards,

Scott Rossi 
Creative Director 
Tactile Media, UX/UI Design 

On Jan 15, 2015, at 4:21 PM, Kay C Lan  wrote:

> * It would probably be wise for RunRev to remove any mention of the Splash
> Stack method on their how-to site as it is clearly not an approach that
> should be used any more.

___
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: Storing and saving a setting in a stand alone

[Kay C Lan]

On Fri, Jan 16, 2015 at 3:57 AM, Richard Gaskin 
wrote:

>
> Why do you suppose this has survived so long with no one discovering it
> until now?
>

Whilst I may be a Mac fanboy, I'm definitely anti-iOSing of OS X. That
said, one of the few side effects may be the herding of LCers to store User
data in the correct place.

For me, a splash stack was simple. It was popular, there were several
online* and many LIst archive posts on how to achieve it. That's what I
did. With iOS that was not approved so you had to look else where. So the
beauty of LC is supposedly you can use one set of code for OS X and iOS so
it seemed silly to me to use one approach to store data on OS X and a
completely different one for iOS. So I looked at specialFolderPath() and
it's all clearly spelled out there where you should store User data. That
was a long time ago. Having gone down that route I now find that I HAVEN'T
been bitten by the change in OS X signing policy.

Having said that, the solution is still not one code for all platforms.
It's specialFolderPath("library") for iOS, specialFolderPath("Preferences")
or specialFolderPath("Support") for OS X, specialFolderPath("Support") Win
and not really sure for Linux... specialFolderPath("Desktop")?. At least
it's nice that for non-Preference type data, for documents that your User
makes with your app,  can all be sent to specialFolderPath("documents"),
except Linux.

Just had a thought, wouldn't it be nice if there was a specialFolderPath("
PrefData") which the engine naturally translated to "library" for iOS,
"support" for OS X & Win, "documents" for android, and whatever for Linux.
This should mean one code for all platforms for most basic apps and if
anything more complex was needed then you're back to where we are now;
writing different code for each platform.

* It would probably be wise for RunRev to remove any mention of the Splash
Stack method on their how-to site as it is clearly not an approach that
should be used any more.
___
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: Free IP Calculator

[Bob Sneidar]

Change this line to:

  — usablecount
  set the itemdelimiter to “.”

won’t work without it. Another note to self: Don’t try to modify code posted in 
an email.

Bob S



On Jan 15, 2015, at 15:18 , Bob Sneidar 
mailto:bobsnei...@iotecdigital.com>> wrote:

  -- usablecountset the itemdelimiter to "."

___
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: Free IP Calculator

[Bob Sneidar]

OK I took some time today to really go through this IPCalc function. Note to 
self: Don’t try to write publicly distributable code quickly. 

That being said, I’ve been asked to include this function in the library of 
commands and functions everyone’s been talking about. So I am going to post the 
code here, and anyone wanting a shot at breaking it (as if you could) give it a 
go. NOTE: There is no error checking as of yet so you *could* break it by 
passing an invalid value like 256.256.256.0 for a subnet address. 

Meanwhile I am going to write some pretty thorough error checking before I 
submit it for public consumption, so that there are no values you can pass to 
it that would break it or otherwise return bad values. 

function IPCalc theIPAddress, theSubnetMask
   -- pass either CIDR notation in theIPAddress or else a standard IP and 
subnet mask
   -- returns an array of the following values:
   -- bcastaddr
   -- cidraddr
   -- cidrdepth
   -- firstaddr
   -- ipaddress
   -- lastaddr
   -- subnetaddr
   -- subnetmask
   -- usablecountset the itemdelimiter to "."

   set the itemdelimiter to "."
   
   -- initial setup
   set the numberFormat to ""
   
   -- detemine format
   if theIPAddress contains "/" then
  put offset("/", theIPAddress) into theCIDRDelim
  put char theCIDRDelim +1 to -1 of theIPAddress into theCIDRDepth
  put charx("1", theCIDRDepth) & charx("0", 32-theCIDRDepth) into 
theBinSubnetMask
  put baseconvert(char 1 to 8 of theBinSubnetMask, 2, 10) into item 1 of 
theSubnetMask
  put baseconvert(char 9 to 16 of theBinSubnetMask, 2, 10) into item 2 of 
theSubnetMask
  put baseconvert(char 17 to 24 of theBinSubnetMask, 2, 10) into item 3 of 
theSubnetMask
  put baseconvert(char 25 to 32 of theBinSubnetMask, 2, 10) into item 4 of 
theSubnetMask
  put char 1 to theCIDRDelim -1 of theIPAddress into theIPAddress
   else
  -- convert the subnet mask to binary
  put 0 into whichOctet
  repeat for each item theOctet in theSubnetMask
 add 1 to whichOctet
 put value(baseConvert(theOctet, 10, 2)) after theBinSubnetMask
  end repeat
  put offset("0", theBinSubnetMask) -1 into theCIDRDepth
   end if
   
   -- convert the ip address to binary
   put 0 into whichOctet
   repeat for each item theOctet in theIPAddress
  add 1 to whichOctet
  put baseConvert(theOctet, 10, 2) into theBinValue
  add 0 to theBinValue
  put theBinValue after theBinIPAddress
   end repeat
   
   -- calculate the binary subnet address
   put char 1 to theCIDRDepth of theBinIPAddress into theBinNetworkAddr
   put char theCIDRDepth +1 to -1 of theBinIPAddress into theBinNodeAddr
   put theBinNodeAddr into theBinSubnetNodeAddr
   set the numberFormat to "0"
   replace "1" with "0" in theBinSubnetNodeAddr
   put theBinNetworkAddr & theBinSubnetNodeAddr into theBinSubnetAddr
   
   -- convert the binary subnet address to decimal
   put baseconvert(char 1 to 8 of theBinSubnetAddr, 2, 10)  into item 1 of 
theSubnetAddr
   put baseconvert(char 9 to 16 of theBinSubnetAddr, 2, 10)  into item 2 of 
theSubnetAddr
   put baseconvert(char 17 to 24 of theBinSubnetAddr, 2, 10)  into item 3 of 
theSubnetAddr
   put baseconvert(char 25 to 32 of theBinSubnetAddr, 2, 10)  into item 4 of 
theSubnetAddr
   
   -- calculate the first usable IP address
   put theSubnetAddr into theFirstAddr
   add 1 to item 4 of theFirstAddr
   
   -- calculate the binary broadcast address
   put theBinNodeAddr into theBinBcastNodeAddr
   replace "0" with "1" in theBinBcastNodeAddr
   put theBinNetworkAddr & theBinBcastNodeAddr into theBinBcastAddr
   
   -- convert the binary broadcast address to decimal
   put baseconvert(char 1 to 8 of theBinBcastAddr, 2, 10) into item 1 of 
theBcastAddr
   put baseconvert(char 9 to 16 of theBinBcastAddr, 2, 10) into item 2 of 
theBcastAddr
   put baseconvert(char 17 to 24 of theBinBcastAddr, 2, 10) into item 3 of 
theBcastAddr
   put baseconvert(char 25 to 32 of theBinBcastAddr, 2, 10) into item 4 of 
theBcastAddr
   
   -- calculate the last usable IP address
   put theBcastAddr into theLastAddr
   subtract 1 from item 4 of theLastAddr
   
   -- calculate the number of usable addresses
   -- put item 4 of theLastAddr - item 4 of theFirstAddr +1 into theAddrCount
   put baseconvert(theBinBcastNodeAddr, 2, 10) -1 into theAddrCount
   
   -- calculate the CIDR notation
   put theSubnetAddr & "/" & theCIDRDepth into theCIDRAddr
   
   -- create array
   put theIPAddress into ipdata ["ipaddress"]
   put theSubnetMask into ipdata ["subnetmask"]
   put theSubnetAddr into ipdata ["subnetaddr"]
   put theFirstAddr into ipdata ["firstaddr"]
   put theBcastAddr into ipdata["bcastaddr"]
   put theLastAddr into ipdata ["lastaddr"]
   put theCIDRDepth into ipdata ["cidrdepth"]
   put theAddrCount into ipdata ["usablecount"]
   put theCIDRAddr into ipdata ["cidraddr"]
   return ipdata
end IPCalc
___
use-li

URL affected by default browser?

[Mike Kerner]

Is the URL keyword affected by the default browser?  It seems that if I do
a put url, the result is directly dependent upon the default browser
selected by the user.  So, for instance, on Windows, with IE as the
default, if the URL pointed to an invalid page, I would get an empty
result, but if I switched the default browser to Chrome, I would get a
bracketed error message.

-- 
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: Which version...

[Richard Gaskin]

Richmond wrote:

> On 15/01/15 21:51, Richard Gaskin wrote:
>> Throughout the forums and the bugs reports I've been following
>> I've seen fairly regular references to Ubuntu 14.04 LTS, the
>> most recent Long-Term Support release the project has.
>
> That's good to know :)
>
> Last I heard they were using a 2008 version. Would be grateful if you
> check back with the Mothership.

As I noted, I've already seen many comments from many RunRev staff 
noting that they're using a wide range of Linux installs, most commonly 
right now Ubuntu 14.04 - here are a few reports in which their staff 
notes using very recent versions:







Given the great many OSes they have installed on both metal and in VMs, 
I wouldn't be surprised if one from 2008 is among them.  Heck, I keep an 
XP VM here for the few clients who like to live that dangerously.  But 
if you search the bug DB or read the forums regularly you'll see that 
when RR staff mention a specific Linux version it's usually very current.


--
 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: Storing and saving a setting in a stand alone

[J. Landman Gay]

On 1/15/2015 2:54 PM, J. Landman Gay wrote:

my main project is still done in LC 6.5.x


Oops, that should be 6.6.5. I'm not THAT far behind. ;)

--
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: Storing and saving a setting in a stand alone

[J. Landman Gay]

On 1/15/2015 1:57 PM, Richard Gaskin wrote:

J. Landman Gay wrote:

 > On 1/15/2015 10:05 AM, Richard Gaskin wrote:
 >> While the absence of reports related to general file access in the
 >> bundle would seem to suggest this change was implemented well in the
 >> engine, René's report shows this workaround for Apple's new security
 >> policy needs to be added to the SQLite external as well.
 >
 > It's more general than that, see my bug report comment. The problem
 > occurs not only in Yosemite but also in Mavericks, and applies to any
 > file that is moved to the new location, not just databases.

Thanks for adding your note to the report.  With the original submission
focused on SQLite and subsequent notes involving writing to the app
bundle, your note will help clarify what's going on.

Why do you suppose this has survived so long with no one discovering it
until now?



I don't know. In my case I didn't need to build a new standalone until 
yesterday, coupled with the fact that my main project is still done in 
LC 6.5.x for other reasons. I've only recently started using 6.7, and 
only for a few newer projects.


--
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: Which version...

[Richmond]

On 15/01/15 21:51, Richard Gaskin wrote:

Richmond wrote:

>> On 15/01/15 16:34, Dr. Hawkins wrote:
>>
>> Pretty much standardized.
...
>> An RC believes that all bugs are taken care of, and is only making
>> sure of this.
>
> Why do I have a funny feeling that RunRev probably know that?

Because they're described in similar terms at the top of RunRev's 
Downloads page:



It's helpful to clarify that "all bugs taken care of" is both close to 
impossible and almost never happens with any software in the history 
of the industry.


Instead, what's aimed for as a software gets close to release is that 
all *critical* bugs are addressed, and of course the only ones that 
can be addressed are those that are *known* at the time.


With most projects, from Apple's OS X to Adobe's Photoshop to RunRev's 
LiveCode, minor issues may get put off for another version beyond the 
one being tested.


Many here note that they only begin testing after release, and then 
report bugs no one else has seen.  With complex systems in which the 
interaction of commands creates a combinatorial explosion of possible 
states, it's practically impossible to identify all possible issues 
prior to release.  Awareness of this basic driver of all software 
engineering of similar scope can be helpful in encouraging us to test 
new builds with our scripts to ensure a new version will do what we 
uniquely require of it.


It would be nice if all software shipped completely bug-free, but I've 
never seen such a thing.  As a practical matter project teams tend to 
prioritize issues and address the most critical first.



> Although, having said that, they did "confess" that they test their
> Linux versions on a horribly outdated version of Ubuntu.

Where did they write that?  Throughout the forums and the bugs reports 
I've been following I've seen fairly regular references to Ubuntu 
14.04 LTS, the most recent Long-Term Support release the project has.




That's good to know :)

Last I heard they were using a 2008 version. Would be grateful if you 
check back with the Mothership.


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: Storing and saving a setting in a stand alone

[Richard Gaskin]

J. Landman Gay wrote:

> On 1/15/2015 10:05 AM, Richard Gaskin wrote:
>> While the absence of reports related to general file access in the
>> bundle would seem to suggest this change was implemented well in the
>> engine, René's report shows this workaround for Apple's new security
>> policy needs to be added to the SQLite external as well.
>
> It's more general than that, see my bug report comment. The problem
> occurs not only in Yosemite but also in Mavericks, and applies to any
> file that is moved to the new location, not just databases.

Thanks for adding your note to the report.  With the original submission 
focused on SQLite and subsequent notes involving writing to the app 
bundle, your note will help clarify what's going on.


Why do you suppose this has survived so long with no one discovering it 
until now?


--
 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: Which version...

[Richard Gaskin]

Richmond wrote:

>> On 15/01/15 16:34, Dr. Hawkins wrote:
>>
>> Pretty much standardized.
...
>> An RC believes that all bugs are taken care of, and is only making
>> sure of this.
>
> Why do I have a funny feeling that RunRev probably know that?

Because they're described in similar terms at the top of RunRev's 
Downloads page:



It's helpful to clarify that "all bugs taken care of" is both close to 
impossible and almost never happens with any software in the history of 
the industry.


Instead, what's aimed for as a software gets close to release is that 
all *critical* bugs are addressed, and of course the only ones that can 
be addressed are those that are *known* at the time.


With most projects, from Apple's OS X to Adobe's Photoshop to RunRev's 
LiveCode, minor issues may get put off for another version beyond the 
one being tested.


Many here note that they only begin testing after release, and then 
report bugs no one else has seen.  With complex systems in which the 
interaction of commands creates a combinatorial explosion of possible 
states, it's practically impossible to identify all possible issues 
prior to release.  Awareness of this basic driver of all software 
engineering of similar scope can be helpful in encouraging us to test 
new builds with our scripts to ensure a new version will do what we 
uniquely require of it.


It would be nice if all software shipped completely bug-free, but I've 
never seen such a thing.  As a practical matter project teams tend to 
prioritize issues and address the most critical first.



> Although, having said that, they did "confess" that they test their
> Linux versions on a horribly outdated version of Ubuntu.

Where did they write that?  Throughout the forums and the bugs reports 
I've been following I've seen fairly regular references to Ubuntu 14.04 
LTS, the most recent Long-Term Support release the project has.


--
 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: Storing and saving a setting in a stand alone

[J. Landman Gay]

On 1/15/2015 10:05 AM, Richard Gaskin wrote:

While the absence of reports related to general file access in the
bundle would seem to suggest this change was implemented well in the
engine, René's report shows this workaround for Apple's new security
policy needs to be added to the SQLite external as well.


It's more general than that, see my bug report comment. The problem 
occurs not only in Yosemite but also in Mavericks, and applies to any 
file that is moved to the new location, not just databases.


--
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: Which version...

[Richmond]

On 15/01/15 20:31, Dr. Hawkins wrote:

On Thu, Jan 15, 2015 at 9:49 AM, Richmond 
wrote:


On 15/01/15 16:34, Dr. Hawkins wrote:


On Wed, Jan 14, 2015 at 11:56 PM, John Dixon 
wrote:5.5 if you want stability; it is late-beta quality.

Some report stability on 6.6, apparently.

6.7 and 7.0 are late and early alpha quality, respectively.



  I wonder how you work that out.

Is that using any standardised criteria, or is that just your
opinion?


Pretty much standardized.  (although 5.5 should have been labeled "release
candidate" or "silver master").

Alpha releases execute and function, but are expected to
crash/explode/whatever.  They are possibly feature complete, but the jury
would still be out.

Betas should generally function and be usable, but are still looking for
bugs.  The big ones are supposedly gone.  Features are set for release
(barring something catastrophic), andwon't be added or subtracted.

An RC believes that all bugs are taken care of, and is only making sure of
this.  Features are locked, and the release number will actually change if
features are changed.



Why do I have a funny feeling that RunRev probably know that?

Although, having said that, they did "confess" that they test their 
Linux versions on

 a horribly outdated version of Ubuntu.

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: Which version...

[Dr. Hawkins]

On Thu, Jan 15, 2015 at 9:49 AM, Richmond 
wrote:

> On 15/01/15 16:34, Dr. Hawkins wrote:
>
>> On Wed, Jan 14, 2015 at 11:56 PM, John Dixon 
>> wrote:5.5 if you want stability; it is late-beta quality.
>>
>> Some report stability on 6.6, apparently.
>>
>> 6.7 and 7.0 are late and early alpha quality, respectively.
>>
>>

>  I wonder how you work that out.
>
> Is that using any standardised criteria, or is that just your
> opinion?
>

Pretty much standardized.  (although 5.5 should have been labeled "release
candidate" or "silver master").

Alpha releases execute and function, but are expected to
crash/explode/whatever.  They are possibly feature complete, but the jury
would still be out.

Betas should generally function and be usable, but are still looking for
bugs.  The big ones are supposedly gone.  Features are set for release
(barring something catastrophic), andwon't be added or subtracted.

An RC believes that all bugs are taken care of, and is only making sure of
this.  Features are locked, and the release number will actually change if
features are changed.

-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
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: Which version...

[Richmond]

On 15/01/15 16:34, Dr. Hawkins wrote:

On Wed, Jan 14, 2015 at 11:56 PM, John Dixon  wrote:


Yes, but my question really is..
'What is the reason for having all theses different versions being updated
more or less at the same time ?'...
Life was much simpler when you knew the version with the largest number
stuck on the end of it was the one to use and the rest, as they say, were
history ?

being pedantic, but I will ask again... Which is the version to use ?...


5.5 if you want stability; it is late-beta quality.

Some report stability on 6.6, apparently.

6.7 and 7.0 are late and early alpha quality, respectively.




I wonder how you work that out.

Is that using any standardised criteria, or is that just your
opinion?

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: Player object

[Peter Haworth]

Hi Martin,
Thanks for the tip.  Unfortunately it doesn't seem to work for audio files,
at least with LC 6.6.2 and OSX 10.7.4.

That would be a nice feature though.  Looks like it could be accommodated
by varying the playrate property.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 

On Thu, Jan 15, 2015 at 3:22 AM, Martin Koob  wrote:

> Oh forgot to say don't know how this works for audio files.
>
> Martin Koob
>
>
>
> --
> View this message in context:
> http://runtime-revolution.278305.n4.nabble.com/Player-object-tp4687755p4687857.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
>
___
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: Storing and saving a setting in a stand alone

[Peter Haworth]

On Thu, Jan 15, 2015 at 8:05 AM, Richard Gaskin 
wrote:

> Hanson's confirmation there suggests they're working on it now, and given
> how widely SQLite is used I'd be surprised if the fix isn't in the next
> build.


Hopefully they will take the opportunity to get the SQLite library up to
date.  Current version is 3.8.7.4 released 12/9/2014.  LC includes version
3.8.3.1 released 2/11/2014, 10 months and 11 releases old.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 
___
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: Storing and saving a setting in a stand alone

[Richard Gaskin]

René Micout wrote:

>> Le 15 janv. 2015 à 15:17, dunbarx at aol.com a écrit :
>>
>> You know, recently I tried to make a "splash" standalone in 6.7,
>> the first I needed to in a while (the last was in 5.x) and it
>> would not work. I thought it was something I was doing wrong,
>> but was not on my front burner to figure out.
>>
>>
>> Anyone else? This is big if true, but how could it have gone
>> unnoticed?
>
> Hello Craig,
> See bug report 14295 !

This is apparently related to a relatively recent change by Apple to 
security handling in OS X.


From the Release Notes included in all 6.7.x builds from 6.7.0rc2 on:

Non-executable file redirection on Mac (6.7.0-rc-2)

Mac AppStore rules require that only executables (including
bundles and apps) are present within the Contents/MacOS
folder in the application bundle.

However, historically (for cross-platform purposes), LiveCode
applications traditional place resources relative to the
engine executable, resulting in non-executable files to be
present in the Contents/MacOS folder which violates AppStore
signing policy.

To remedy this situation without requiring users to change
scripts, a simple redirection facility has been implemented
in the engine:

If an attempt is made to open a file for read which falls
within Contents/MacOS and does not exist, the engine will
attempt to open the same path but under Contents/Resources
/_MacOS instead.

If an attempt is made to list files in a folder which falls
within Contents/MacOS, the engine will list files in that
folder and concatenate them will files within the same folder
under Contents/Resources/_MacOS. Additionally the standalone
builder has had an extra processing step added on Mac:

After the Mac bundle has been built, the S/B recurses through
Contents/MacOS and creates an identical folder structure based
at Contents/Resources/_MacOS. All non-executable files in any
folders under Contents/MacOS are moved to the same folder under
Contents/Resources/_MacOS whereas any Mach-O executable files
are left where they are.

The result of this is that after building a standalone, from
a script's point of view nothing has changed; but the app bundle
will conform to the rules required for signing for the Mac
AppStore.


While the absence of reports related to general file access in the 
bundle would seem to suggest this change was implemented well in the 
engine, René's report shows this workaround for Apple's new security 
policy needs to be added to the SQLite external as well.


Hanson's confirmation there suggests they're working on it now, and 
given how widely SQLite is used I'd be surprised if the fix isn't in the 
next build.



There is one remaining issue however:  René's last comment in the report 
suggests an expectation that files within the bundle will also be 
writable, but write access to anything within the Applications folder is 
generally disallowed on most systems, including OS x.


Does OS X now allow user-data to be written within an app bundle?

It would seem simpler to store user data in one of the user-writable 
folders within the user's Home folder, perhaps Application Support or 
another relevant path obtainable with the specialFolderPath function.


--
 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: Storing and saving a setting in a stand alone

[René Micout]

> Le 15 janv. 2015 à 15:17, dunb...@aol.com a écrit :
> 
> Rene.
> 
> 
> OOOH.
> 
> 
> You know, recently I tried to make a "splash" standalone in 6.7, the first I 
> needed to in a while (the last was in 5.x) and it would not work. I thought 
> it was something I was doing wrong, but was not on my front burner to figure 
> out.
> 
> 
> Anyone else? This is big if true, but how could it have gone unnoticed?

Hello Craig,
See bug report 14295 !
René


___
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: Storing and saving a setting in a stand alone

[Richard Gaskin]

Shawn Blc wrote:

Can someone point me in the right direction?
I want to save a setting in stand alone application. This setting will be
different for each person (name).

Once it's set, the user won't be prompted to enter again.


OSes don't allow applications to modify themselves.   Back in the olden 
days Mac Classic did, but that was due to a bifurcated file system long 
since recognized as needing replacement, so Apple discourages use of the 
resource fork in modern apps.  And without a resource fork, runtime 
modification of an executable isn't possible.  Most other OSes have had 
this convention in place since their beginnings.


Data can be stored outside of the executable in a nearly infinite range 
of formats, including SQLite, text files, XML, JSON, encoded arrays, or 
even stack files using custom properties.


When storing user data, it's helpful to put it into the user-writable 
folders recommended by the OS vendor - see the specialFolderPath 
function for details on that.


Sarah Reichelt's article describes this in more detail, and includes 
tips for working with externally-stored data:



--
 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: Which version...

[Richard Gaskin]

John Dixon wrote:


Why are there different versions of liveCode being updated..

LC 7.0- updated 23 October 2014
LC 7.0.1 - updated 18 December 2014

LC 6.7.0 - updated 18 December 2014
LC 6.7.1 - updated   9 January 2015

Which one is considered to be the 'one' to use ?


As with most software, version numbers indicate the evolution of the 
code base over time, with higher numbers reflecting a more recent build.


Just as OS X 10.1 has been superseded by OS X 10.10, older versions of 
LiveCode are generally just that, lacking in fixes and/or features found 
in more recent versions.


When a trinomial version number is used, the most common pattern employs 
this set of unique communicative roles for each element:


 .  . 

So the differences between 6.0.0 and 7.0.0 can be understood to be very 
significant, between 6.6.0 and 6.7.0 less so, and the differences 
between 7.0.0 and 7.0.1 can be expected to be comprised primarily of 
just bug fixes.  There may be occasions when a point-point release may 
also include new features, but those are very rare.



The 'one' so use is version 8, which will include all features 
implemented to date plus the Open Language/Widgets framework needed to 
complete the rest of the items remaining on the current Road Map.


But version 8 does not yet exist.  It's coming soon, but in the meantime 
we're in a transitional state between the old world of relatively minor 
changes in the engine and, as Tiemo calls it, the "brave new world" of 
an xTalk far more capable than anything before it.


V6.7's focus was Cocoa for Mac, a very major overhaul to object handling 
and messaging that has on the whole gone surprisingly well.


V7.0's focus is Unicode for all platforms and GTK integration for Linux. 
 V7 includes all changes  done in v6.7, making it the most 
feature-complete version available at this time.


V7 is also the first version to deliver a 64-bit compatible Linux 
engine, making it essential on many Linux desktops and most Linux servers.



When you see X.X.0 and X.X.1 versions, it's generally good to upgrade to 
the latter.  Being a point-point release there are few if any new 
features meaning less likelihood of regression errors, but more useful 
is that its purpose is to deliver fixes for issues found in the X.X.0 
build that weren't found during test of that version prior to release.


As a general rule, you can expect the version with the highest version 
number listed as "Stable" here to be the most feature-complete:




All that said, V7 is measurably slower than earlier versions for many 
operations, understandable given the scope of Unicode and how that 
affects so many elements throughout the language.


This speed difference is often negligible on the desktop, but coupled 
with a suboptimal boot sequence makes it not merely measurably slower on 
servers, but noticeably so.


Since v7 is necessary for modern 64-bit servers and performance in 
general is recognized as a valuable feature for all platforms, the team 
is exploring options for optimizing v7 to bring its performance more in 
line with that of v6.7.  I don't think any of us expected we'd have both 
feature completion and optimization in the same build, so the necessity 
of this optimization phase is appreciated even if it requires some patience.


Given the tradeoffs between the two version currently maintained, v6.7.x 
and v7.0.x, those whose work is critically dependent on performance 
often use v6.7.x, while those who need Unicode use v.7.0.x.


--
 Richard Gaskin
 LiveCode Community Manager
 rich...@livecode.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: Which version...

[Dr. Hawkins]

On Wed, Jan 14, 2015 at 11:56 PM, John Dixon  wrote:

> Yes, but my question really is..
> 'What is the reason for having all theses different versions being updated
> more or less at the same time ?'...
> Life was much simpler when you knew the version with the largest number
> stuck on the end of it was the one to use and the rest, as they say, were
> history ?
>
> being pedantic, but I will ask again... Which is the version to use ?...
>

5.5 if you want stability; it is late-beta quality.

Some report stability on 6.6, apparently.

6.7 and 7.0 are late and early alpha quality, respectively.


-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
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: Storing and saving a setting in a stand alone

[dunbarx]

Rene.


OOOH.


You know, recently I tried to make a "splash" standalone in 6.7, the first I 
needed to in a while (the last was in 5.x) and it would not work. I thought it 
was something I was doing wrong, but was not on my front burner to figure out.


Anyone else? This is big if true, but how could it have gone unnoticed?


Craig 



-Original Message-
From: René Micout 
To: How to use LiveCode 
Sent: Thu, Jan 15, 2015 9:14 am
Subject: Re: Storing and saving a setting in a stand alone



> Le 15 janv. 2015 à 15:08, dunb...@aol.com a écrit :
> 
> Hi.
> 
> 
> Are you talking about the fact that a single stack, which is the executable 
> if 
you save it as a standalone, cannot save to itself? If so, there are several 
threads on the forums that address this. My favorite is the "splash stack" 
method. 
> 
> 
> Look here:
> 
> 
> 
> Stack data i/o question

Yes, I use it… but after LC 6.6.3, that don’t works !


___
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: Storing and saving a setting in a stand alone

[René Micout]

> Le 15 janv. 2015 à 15:08, dunb...@aol.com a écrit :
> 
> Hi.
> 
> 
> Are you talking about the fact that a single stack, which is the executable 
> if you save it as a standalone, cannot save to itself? If so, there are 
> several threads on the forums that address this. My favorite is the "splash 
> stack" method. 
> 
> 
> Look here:
> 
> 
> 
> Stack data i/o question

Yes, I use it… but after LC 6.6.3, that don’t works !


___
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: Storing and saving a setting in a stand alone

[dunbarx]

Hi.


Are you talking about the fact that a single stack, which is the executable if 
you save it as a standalone, cannot save to itself? If so, there are several 
threads on the forums that address this. My favorite is the "splash stack" 
method. 


Look here:



Stack data i/o question


Craig Newman



-Original Message-
From: Shawn Blc 
To: How to use LiveCode 
Sent: Thu, Jan 15, 2015 8:28 am
Subject: Storing and saving a setting in a stand alone


Can someone point me in the right direction?
I want to save a setting in stand alone application. This setting will be
different for each person (name).

Once it's set, the user won't be prompted to enter again.
___
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

Storing and saving a setting in a stand alone

[Shawn Blc]

Can someone point me in the right direction?
I want to save a setting in stand alone application. This setting will be
different for each person (name).

Once it's set, the user won't be prompted to enter again.
___
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: Player object

[Martin Koob]

Oh forgot to say don't know how this works for audio files.

Martin Koob



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Player-object-tp4687755p4687857.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: Player object

[Martin Koob]

If you hold the shift key and click on the step forward/step backward buttons
on the right of the controller you get a scrub control that allows you to
vary the player's playrate forward and backward from - 3x to 3x.  

Martin Koob



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Player-object-tp4687755p4687856.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

AW: Which version...

[Tiemo Hollmann TB]

Brave new world

-Ursprüngliche Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag
von John Dixon
Gesendet: Donnerstag, 15. Januar 2015 11:50
An: How to use LiveCode
Betreff: RE: Which version...


Just made a standalone for a stack I'm working on...

from LC 6.7 -   2.8 mb in size
from LC 7.0 - 28.0 mb in size

Where did all that bloat appear from !?

Dixie

> Date: Thu, 15 Jan 2015 02:37:28 -0800
> From: d...@applicationinsight.com
> To: use-revolut...@lists.runrev.com
> Subject: Re: Which version...
> 
> As far as I know (which isn't saying much):
> 
> LC 6.6.x = maintenance of 'old generation' versions (e.g. carbon) LC 
> 6.7.x = 'new generation' stuff like cocoa, excluding UniCode LC 7.x.x 
> = all 'new generation' stuff, including Unicode
> 
> LC 6.6 is for working on legacy stacks LC 6.7 is for those wanting 
> 'new generation' features but who don't want UniCode LC 7 is the 
> future and the base on which they are building LC 8 (and presumabely 
> HTML5 too)
> 
> So - as to which version you should use - depends on what you're working
on! 
> 
> If you are close to releasing an app and don't need 'new generation'
> features then probably you are best with 6.6.x
> 
> If you don't expect to release you app very soon and think that 'new 
> generation' bugs are both necessary in your app likely to have been 
> ironed out by the time you launch your app then I would say go with 
> 7.x.x
> 
> Unless there is some reason why you don't want the new way LC supports 
> UniCode, in which case go with 6.7.x
> 
> Dave
> 
> 
> 
> -
> "Some are born coders, some achieve coding, and some have coding 
> thrust upon them." - William Shakespeare & Hugh Senior
> 
> --
> View this message in context: 
> http://runtime-revolution.278305.n4.nabble.com/Which-version-tp4687842
> p4687852.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
  
___
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: Which version...

[Dave Kilroy]

I believe it's resources needed to make their new handling of UniCode work
(also believe they are looking at ways of slimming down file sizes...)


John Dixon wrote
> from LC 6.7 -   2.8 mb in size
> from LC 7.0 - 28.0 mb in size
> 
> Where did all that bloat appear from !?





-
"Some are born coders, some achieve coding, and some have coding thrust upon 
them." - William Shakespeare & Hugh Senior

--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Which-version-tp4687842p4687854.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: Which version...

[John Dixon]

Just made a standalone for a stack I'm working on...

from LC 6.7 -   2.8 mb in size
from LC 7.0 - 28.0 mb in size

Where did all that bloat appear from !?

Dixie

> Date: Thu, 15 Jan 2015 02:37:28 -0800
> From: d...@applicationinsight.com
> To: use-revolut...@lists.runrev.com
> Subject: Re: Which version...
> 
> As far as I know (which isn't saying much):
> 
> LC 6.6.x = maintenance of 'old generation' versions (e.g. carbon)
> LC 6.7.x = 'new generation' stuff like cocoa, excluding UniCode
> LC 7.x.x = all 'new generation' stuff, including Unicode
> 
> LC 6.6 is for working on legacy stacks
> LC 6.7 is for those wanting 'new generation' features but who don't want
> UniCode
> LC 7 is the future and the base on which they are building LC 8 (and
> presumabely HTML5 too)
> 
> So - as to which version you should use - depends on what you're working on! 
> 
> If you are close to releasing an app and don't need 'new generation'
> features then probably you are best with 6.6.x
> 
> If you don't expect to release you app very soon and think that 'new
> generation' bugs are both necessary in your app likely to have been ironed
> out by the time you launch your app then I would say go with 7.x.x 
> 
> Unless there is some reason why you don't want the new way LC supports
> UniCode, in which case go with 6.7.x
> 
> Dave
> 
> 
> 
> -
> "Some are born coders, some achieve coding, and some have coding thrust upon 
> them." - William Shakespeare & Hugh Senior
> 
> --
> View this message in context: 
> http://runtime-revolution.278305.n4.nabble.com/Which-version-tp4687842p4687852.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
  
___
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: Which version...

[Dave Kilroy]

As far as I know (which isn't saying much):

LC 6.6.x = maintenance of 'old generation' versions (e.g. carbon)
LC 6.7.x = 'new generation' stuff like cocoa, excluding UniCode
LC 7.x.x = all 'new generation' stuff, including Unicode

LC 6.6 is for working on legacy stacks
LC 6.7 is for those wanting 'new generation' features but who don't want
UniCode
LC 7 is the future and the base on which they are building LC 8 (and
presumabely HTML5 too)

So - as to which version you should use - depends on what you're working on! 

If you are close to releasing an app and don't need 'new generation'
features then probably you are best with 6.6.x

If you don't expect to release you app very soon and think that 'new
generation' bugs are both necessary in your app likely to have been ironed
out by the time you launch your app then I would say go with 7.x.x 

Unless there is some reason why you don't want the new way LC supports
UniCode, in which case go with 6.7.x

Dave



-
"Some are born coders, some achieve coding, and some have coding thrust upon 
them." - William Shakespeare & Hugh Senior

--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Which-version-tp4687842p4687852.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: [OT] I'm going to go live in a cave

[Kay C Lan]

Whoops, don't know what happened there:

http://www.amazon.com/Cyber-Clean-25055-Office-Pop-up/dp/B00375JBL4
___
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: Which version...

[Graham Samuel]

There seems to be another oddity, which is that I just found out that when you 
report a bug, you’re currently asked which of three or four versions of 7.0.1 
you have - but when I look at the version I’m actually using, there’s no 
reference in the ‘About’ box to any of these versions! FWIW I think this level 
of confusion about versions is counterproductive.

Graham

> On 15 Jan 2015, at 09:12, Tiemo Hollmann TB  wrote:
> 
> Hi John,
> 
> the 7.x line is the new world, based on cocoa, full unicode support, etc.
> which will developed further on.
> The 6.x line is the old world without full Unicode support and is just
> maintained from runrev a little further for the old school guys (like me),
> who can't switch to the new world (yet)
> 
> Tiemo
> 
> 
> -Ursprüngliche Nachricht-
> Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag
> von John Dixon
> Gesendet: Donnerstag, 15. Januar 2015 08:57
> An: How to use LiveCode
> Betreff: RE: Which version...
> 
> 
> Hi Dave,
> 
> Yes, but my question really is.. 
> 'What is the reason for having all theses different versions being updated
> more or less at the same time ?'... 
> Life was much simpler when you knew the version with the largest number
> stuck on the end of it was the one to use and the rest, as they say, were
> history ?
> 
> being pedantic, but I will ask again... Which is the version to use ?...
> 
> Dixie
> 
> 
>> Date: Wed, 14 Jan 2015 23:47:31 -0800
>> From: d...@applicationinsight.com
>> To: use-revolut...@lists.runrev.com
>> Subject: Re: Which version...
>> 
>> Hi John
>> 
>> I do know that on the 5th of January Frazer put out community 6.7.1 
>> for Windows again because the installer wasn't working properly - and 
>> I could add LC 6.7.2 to your list which also is dated on the 9th...
> 
> 
> ___
> 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: Possible insanity, or is it LC 7.0.1?

[Graham Samuel]

Now reported as a bug (14386) - I’ve included a reference to this thread to 
show that my observation is backed up by many listers. Thanks everyone. Thanks 
Jacque for doubting the sanity of SANE.

Graham


> On 15 Jan 2015, at 10:00, Henk van der Velden  wrote:
> 
> I get the same error here, same setup: OS X 10.10.1, LC7.0.1 build 10023
> So it’s definitely not just you!
> Henk
> 
>> On 15 Jan 2015, at 09:12, use-livecode-requ...@lists.runrev.com wrote:
>> 
>> Message: 6
>> Date: Thu, 15 Jan 2015 00:06:12 +0100
>> From: Graham Samuel mailto:livf...@mac.com>>
>> To: How to use LiveCode > >
>> Subject: Re: Possible insanity, or is it LC 7.0.1?
>> Message-ID: <35c0aead-5c56-420c-810e-24fcacc70...@mac.com 
>> >
>> Content-Type: text/plain; charset=utf-8
>> 
>> Thanks to those who replied. So, I am going crazy! I suppose it is something 
>> very particular about my setup. I did find one other way to show the 
>> anomaly, which was to put
>> 
>> put 1.884956 into it; put value(it+0)
>> 
>> this gives me the error
>> "Message execution error:
>> Error description: value: error executing expression
>> Hint: 1.884956"
>> But of course YMMV. I am quite happy to be told it?s my fault, but the fact 
>> is that this is just an abstraction of something that has arisen in the 
>> middle of a loop that produces a table of values based on input parameters 
>> which are all very similar: the loop suddenly hits an error only on this 
>> particular value. It has worked in earlier versions of LC, but now I?m 
>> wedded to Unicode, it?s got to work with LC 7.
>> 
>> If I ever get an explanation, I?ll tell the list about it.
>> 
>> Cheers
>> 
>> Graham
>> 


___
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: Possible insanity, or is it LC 7.0.1?

[Henk van der Velden]

I get the same error here, same setup: OS X 10.10.1, LC7.0.1 build 10023
So it’s definitely not just you!
Henk

> On 15 Jan 2015, at 09:12, use-livecode-requ...@lists.runrev.com wrote:
> 
> Message: 6
> Date: Thu, 15 Jan 2015 00:06:12 +0100
> From: Graham Samuel mailto:livf...@mac.com>>
> To: How to use LiveCode  >
> Subject: Re: Possible insanity, or is it LC 7.0.1?
> Message-ID: <35c0aead-5c56-420c-810e-24fcacc70...@mac.com 
> >
> Content-Type: text/plain; charset=utf-8
> 
> Thanks to those who replied. So, I am going crazy! I suppose it is something 
> very particular about my setup. I did find one other way to show the anomaly, 
> which was to put
> 
>  put 1.884956 into it; put value(it+0)
> 
> this gives me the error
> "Message execution error:
> Error description: value: error executing expression
> Hint: 1.884956"
> But of course YMMV. I am quite happy to be told it?s my fault, but the fact 
> is that this is just an abstraction of something that has arisen in the 
> middle of a loop that produces a table of values based on input parameters 
> which are all very similar: the loop suddenly hits an error only on this 
> particular value. It has worked in earlier versions of LC, but now I?m wedded 
> to Unicode, it?s got to work with LC 7.
> 
> If I ever get an explanation, I?ll tell the list about it.
> 
> Cheers
> 
> Graham
> 

___
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] I'm going to go live in a cave

[Richmond]

On 01/15/2015 02:04 AM, Kay C Lan wrote:

On Wed, Jan 14, 2015 at 7:24 PM, FlexibleLearning.com  wrote:


where did I put those cotton swabs?


Cotton swabs? I've tried micro nozzle attachments that connect to your
vacuum cleaner but by far the most effective way of cleaning all the nooks
and crannies of anything, not just electronic equipment, is CyberClean:

https://mail.google.com/mail/u/0/#label/Mobile/14ae5a2c442d19f0


All that happens when I click on that address above is that I end up in 
my gmail

account on Firefox.

Richmond.


That listing is pretty expensive. My 500g tub cost me $12 and has lasted
several years. The stuff sort of oozes and deforms to any shape - see the
photo in the link of cleaning the fan vents of the Mac Pro - but it doesn't
come apart. It is slightly tacky so it picks up all the dirt and fluff. I
use a ball about a quarter of the size shown in the photos. I attack each
key individually, push down really hard with the palm of my hand to force
the goop into all the crevices and then use a circular polishing motion to
ensure all four sides of the key are done. You can see the stuff being
picked up and just keep going until it's all gone, then move onto the next
key.
___
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

AW: Which version...

[Tiemo Hollmann TB]

... I forgot to answer your question which version to use.
If you need one of the new features of version 7 (see version info), then
you go with 7.x
If not, I personally would stay with 6.x until 7.x is more stable and more
bugs are solved (see list)
This is only my personal advice
Tiemo

-Ursprüngliche Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag
von Tiemo Hollmann TB
Gesendet: Donnerstag, 15. Januar 2015 09:12
An: 'How to use LiveCode'
Betreff: AW: Which version...

Hi John,

the 7.x line is the new world, based on cocoa, full unicode support, etc.
which will developed further on.
The 6.x line is the old world without full Unicode support and is just
maintained from runrev a little further for the old school guys (like me),
who can't switch to the new world (yet)

Tiemo


-Ursprüngliche Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag
von John Dixon
Gesendet: Donnerstag, 15. Januar 2015 08:57
An: How to use LiveCode
Betreff: RE: Which version...


Hi Dave,

Yes, but my question really is.. 
'What is the reason for having all theses different versions being updated
more or less at the same time ?'... 
Life was much simpler when you knew the version with the largest number
stuck on the end of it was the one to use and the rest, as they say, were
history ?

being pedantic, but I will ask again... Which is the version to use ?...

Dixie


> Date: Wed, 14 Jan 2015 23:47:31 -0800
> From: d...@applicationinsight.com
> To: use-revolut...@lists.runrev.com
> Subject: Re: Which version...
> 
> Hi John
> 
> I do know that on the 5th of January Frazer put out community 6.7.1 
> for Windows again because the installer wasn't working properly - and 
> I could add LC 6.7.2 to your list which also is dated on the 9th...

  
___
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

AW: Which version...

[Tiemo Hollmann TB]

Hi John,

the 7.x line is the new world, based on cocoa, full unicode support, etc.
which will developed further on.
The 6.x line is the old world without full Unicode support and is just
maintained from runrev a little further for the old school guys (like me),
who can't switch to the new world (yet)

Tiemo


-Ursprüngliche Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag
von John Dixon
Gesendet: Donnerstag, 15. Januar 2015 08:57
An: How to use LiveCode
Betreff: RE: Which version...


Hi Dave,

Yes, but my question really is.. 
'What is the reason for having all theses different versions being updated
more or less at the same time ?'... 
Life was much simpler when you knew the version with the largest number
stuck on the end of it was the one to use and the rest, as they say, were
history ?

being pedantic, but I will ask again... Which is the version to use ?...

Dixie


> Date: Wed, 14 Jan 2015 23:47:31 -0800
> From: d...@applicationinsight.com
> To: use-revolut...@lists.runrev.com
> Subject: Re: Which version...
> 
> Hi John
> 
> I do know that on the 5th of January Frazer put out community 6.7.1 
> for Windows again because the installer wasn't working properly - and 
> I could add LC 6.7.2 to your list which also is dated on the 9th...

  
___
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