Re: override HTTPS certificate failure

[Lyn Teyla]

Bob Sneidar wrote:

> True, but isn't the issue that a malformed cert including self signed certs 
> are rejected? A self signed cert is not insecure, it's just less secure than 
> a root signed cert, and only because a background check has been done against 
> the cert owner. Otherwise a self signed cert is just as valid if you know you 
> can trust it, as when connecting to you domain controller or copier for the 
> first time on a LAN. After that, the cert theoretically cannot be spoofed.

That only applies if the client app is specifically coded to _also_ perform the 
following additional steps:

1. When connecting to a secure server and receiving invalid and unknown 
certificate details, present them to the user and allow them to trust or reject 
the certificate.

2. If the user elects to trust the certificate, save the certificate details 
received from the server during that first connection.

3. During subsequent connections, compare the saved certificate details to 
those received, and only proceed if the details are identical.

This is what web browsers, email clients and FTP apps do when instructed by a 
user to trust an invalid certificate.

libURL doesn’t currently offer a handler that allows one to retrieve 
certificate data, so one would need to utilize raw sockets or call a command 
line utility such as openssl to obtain the data.

Simply setting libURLSetSSLVerification to false (even just for specific hosts) 
doesn’t do any of that, which is why spoofing could still occur.

Lyn




___
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: override HTTPS certificate failure

[Lyn Teyla]

Ben Rubinstein wrote:

> If an "https" site has a misconfigured certificate, most browsers will tell 
> you what the problem is - and generally give you an option (more or less 
> hidden) to ignore the warning and load the resource anyway.
> 
> Loading the same resource from LC using libURL, the result is "error 
> application verification failure".
> 
> Is there any way to override the normal test in LC, as one can in a browser, 
> to request that the resource be returned anyway?

With libURL you’d use:

libURLSetSSLVerification false

With tsNet you’d use:

tsNetVerifySSLPeer false

Remember to leave it set to true for production, though. Otherwise, malicious 
parties could intercept data transmissions whilst presenting their own fake 
certificates, negating the whole point of encrypting data in transit.

Lyn :)




___
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: LC Server: Getting a file list when filenames use UTF8

[Lyn Teyla]

I opened a bug report in August concerning this issue:

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

Lyn


> Tim Selander wrote:
> 
> Thanks for confirming that for me Ralf.
> 
> I wonder if the team can look into this
> 
> Tim Selander
> Tokyo, Japan
> 
> On 2016/10/17 20:02, Ralf Bitter wrote:
>> Seems that I can confirm your findings.
>> Did a test on diesel using server version 8.1.1-rc-2.
>> If there is a file "こんにちは.txt" the file list retrieved
>> is empty. To get a file list I have to remove the
>> Japanese file.
>> 
>> 
>> Ralf
>> 
>> 
>>> On 17.10.2016, at 10:21, Tim Selander  wrote:
>>> 
>>> Hi,
>>> 
>>> Using LC server as installed in my on-rev account.
>>> 
>>> This script
>>> >> set the defaultfolder to "/home/server-name/public_html/selander/201610"
>>> put the files
>>> ?>
>>> 
>>> Only returns files with English filenames to the resulting web page. 
>>> Japanese (utf8) filenames are ignored. If I change one of the Japanese 
>>> filenames to English, then it appears. If I change it back to Japanese, it 
>>> reverts to not appearing.
>>> 
>>> Any hints?
>>> 
>>> Thank you.
>>> 
>>> Tim Selander
>>> Tokyo, Japan
>> 
>> 
>> ___
>> 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: 9.0???

[Lyn Teyla]

Richmond wrote:

> The main question that worries me is what happens when the
> curve of the graph approaches a vertical line :P

The team has foreseen this issue, hence the Infinite LiveCode campaign.

Lyn



___
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: TSNet and proxies

[Lyn Teyla]

Charles Warwick wrote:

> If you are not using standard libUrl commands then you will need to call 
> tsNetSetProxy if the connection needs to go through a proxy server.

When calling tsNet commands directly, how does one obtain and pass 
tsNetSetProxy the _exact_ same set of proxy settings that tsNet would have 
automatically gotten had a libUrl command been used?

Checking the httpProxy property doesn’t cover all scenarios, since it won’t 
provide details relating to proxy login credentials, SOCKS, WPAD, etc. that 
(presumably) might otherwise have been automatically detected and passed on to 
tsNet had a libUrl command been issued.

Lyn




___
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: SSL Help

[Lyn Teyla]

Dan Friedman wrote:

> Other than this issue, LC 7.0.1 is working well.   Can you offer any support 
> for this issue with 7.0.1?  Or, do I just set libURLSetSSLVerification to 
> false and hope for the best?

If you’d like to stay on LC 7.0.1, then to avoid the SNI bug, you’ll need to 
ensure that your domain is hosted on a dedicated IP, and that no other domain 
on that IP has an SSL certificate installed.

Setting libURLSetSSLVerification to false is not recommended, as it increases 
the risk of man-in-the-middle attacks.

Lyn



___
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: SSL Help

[Lyn Teyla]

Dan Friedman wrote:

> I purchased a SSL certificate and installed it and set it as the default.  It 
> is working fine in every browser I try.  However, in LiveCode (7.0.1), it's 
> getting the previous self-signed SSL certificate and failing with this error:


It’s possible that you’re running into the SNI bug that’s been fixed since 
LiveCode 6.7.9-rc-1 and 7.1.2-rc-1. You can read more about the SNI bug at:

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

Lyn



___
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: Extracting list of errors from LiveCode 8

[Lyn Teyla]

Ali Lloyd wrote:

> You can use the global property
> 
> the scriptExecutionErrors
> 
> To obtain this list. Note that this does not work in a standalone so if you
> need it you'll have to set a custom property on an included stack or
> something like that.

Thanks Ali! It looks like the scriptExecutionErrors property is not documented 
in the dictionary. I’ve opened a bug report:

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

Lyn



___
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: Extracting list of errors from LiveCode 8

[Lyn Teyla]

Thierry Douez wrote:

> within LC 8.0, this works:
> 
> *put* the cErrorsList of stack "revErrorDisplay"


Thanks Thierry!

However, this doesn’t seem to work with 8.0.2 RC 4 and 8.1.0 DP 3.

Lyn



___
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

Extracting list of errors from LiveCode 8

[Lyn Teyla]

Hi all,

In LiveCode 7 and earlier, one could use the following to extract the list of 
errors:

the cErrorsList of cd 1 of stack "revErrorDisplay"

However, this no longer works in LiveCode 8.

What is the new method of extracting the list of errors?

TIA,
Lyn



___
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: LC and webviews

[Lyn Teyla]

Jerry Daniels wrote:

> I just read this article about Basecamp's use of webviews in their mobile 
> (Android in this case) apps. It got me thinking about LiveCode's htmlText. 
> Does it use some sort of CSS? If so, can one be set in its stead?

That's exactly the sort of thing the browser widget in LiveCode 8 allows you to 
do, and it really opens the door to all sorts of possibilities.

And, it works on all platforms, not just Android.

Once the Windows bug is fixed, it will get even better:

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

;)

In my opinion, the multi-platform browser widget, with the included support for 
communication via JavaScript, is one of the most important features the 
LiveCode team has implemented, and will allow many more to consider LiveCode as 
a possible tool for development and deployment.

You do need to know at least some rudimentary JavaScript (it's easy to pick up 
the essentials, though the more you know the better) so you can pass data back 
and forth between the browser widget and your LiveCode handlers.

This way, you get to do the bulk of your coding using LiveCode rather than 
JavaScript, whilst using one or more browser widgets (a.k.a. "web views") to 
handle the UI via HTML, CSS and JavaScript.

You can create any sort of polished UI that can be accomplished using web 
views, and use Angular, Bootstrap, and other established web-based UI 
frameworks to speed up the process.

You can place your UI code on a server and update it on the fly.

You can create reusable widgets and libraries based on HTML, CSS and/or 
JavaScript.

You can tap into the huge repository of existing JavaScript libraries to shave 
off chunks of coding time.

You can perform concurrent processing by handing stuff over to JavaScript in 
one or more browser widgets.

In short, the browser widget is a brilliant, much-welcomed feature.

Lyn



___
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 Livecode and Intego Virus Barrier

[Lyn Teyla]

Kay C Lan wrote:

>> The reason I say that is because if I downloaded any software and it
>> took 3 min to load I wouldn't use it. I don't care how good it
>> 'really' is, if it took 3 minutes to load the impression it would give
>> me is that it is very poorly written/performing app. I have no apps
>> that take more than a few seconds to start.

I do agree with this.

Although, Matthias does have a point in that new users are less likely to 
experience this due to LiveCodeToolsLog.txt probably being either non-existent 
or of a much smaller size.

But still — 3 minutes for a 2.8 MB file? I just checked the size of 
LiveCodeToolsLog.txt on my machine and it’s 13.3 MB. I wonder how long an 
Intego scan would have taken with that!

One wonders if perhaps:

1. The scanning algorithm or method used by Intego might not have been 
sufficiently optimized to perform well under certain circumstances;

and/or

2. The method used by LiveCode to write to LiveCodeToolsLog.txt (presumably 
multiple times) might not be ideal. Could be a "write to file" vs "put into 
url" issue.

Better yet, perhaps the writing to this log file should not be performed by 
default, unless a debug setting is set via Preferences.

It does sound like something suitable for a bug/enhancement report.

Lyn



___
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 retrieving data from a SQL database

[Lyn Teyla]

Paul Dupuis wrote:

> Does anyone have some really good (comprehensive) routines to escape and
> unescape text data for storing in a SQL database (like SQLite or MySQL)

HostM’s server-side demo stack comes with a function (look for the one named 
"se") that you can use:

https://www.hostm.com/tutorials/livecode/api-mariadb-mysql

Lyn :)



___
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: LC on VMWare?

[Lyn Teyla]

Dan Friedman wrote:

> I have a client that is trying to run my LiveCode Standalone (built with LC 
> 7.0.1) using VMWare.  They are trying to get it to run in VMWare so they can 
> run it from a Chromebook.  Problem is when they run the app remotely, it 
> crashes on launch with the message "AppName has stopped working".  Anyone 
> have any experience with this or know why a LC app would fail under VMWare?

Here are a couple of suggestions:

1. Have them right-click your app, select Properties, click the Unblock button 
(if it exists), then try opening the app again.

2. If you have access to a later version of LiveCode, try building your 
standalone with that to see if it makes a difference.

Lyn



___
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: Beeing a developer after 40

[Lyn Teyla]

Stephen Barncard wrote:

> obviously one hasn't been to a LC event lately.  More white hair and
> ponytails on old folks than an AES convention. The cool geeks club.

I’ve got nothing against younger or older people at all, but:

Whenever I come across photos of LiveCode events, and see white hair and 
baldness everywhere, it often makes me question my own sanity regarding my 
choice of programming language.

And then, I start questioning the sanity of younger people, who appear to 
_want_ to code using a non-English-like language, and multiple different 
languages at that, if deploying to different platforms.

Apparently, younger people, for some reason, don’t seem to want an English-like 
language (some even going as far as to avoid such languages as much as 
possible), or be able to use that same language to create desktop, mobile, 
server and web apps.

Should we be learning all sorts of non-English-like programming languages, just 
because everyone else is doing it, even though they’re less intuitive to use?

Does LiveCode Ltd have a sustainable business model given the apparent reality? 
Surely it can’t be reasoned away that young programmers don’t like going to 
events?

Am I mad? Has the world gone mad? Has common sense been thrown out the window?

/rant

Lyn



___
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: Multiple Threads

[Lyn Teyla]

Bob Sneidar wrote:

> So I think I've isolated why it is that virtually every post on this list 
> ends up creating multiple threads in my email application. Lots of people are 
> *STILL* using use-revolut...@lists.runrev.com. Because of this I start 
> reading the replies to a post before I ever see the original issue. 

Given that the company has changed its name to LiveCode Ltd and its corporate 
domain to livecode.com, even the @lists.runrev.com portion of the address seems 
rather outdated and potentially confusing.

Here’s a straightforward solution that LiveCode Ltd could implement:

1. Move the mailing list to use-livec...@lists.livecode.com.

2. Remove the existing email aliases/forwarding setup on 
use-revolut...@lists.runrev.com.

3. Set up an autoresponse for both use-revolut...@lists.runrev.com and 
use-livecode@lists.runrev.com that says something like this:

"Thank you for sending an email to use-revolut...@lists.runrev.com. Our mailing 
list email has changed to use-livec...@lists.livecode.com. Please resend your 
message (and all future list messages) to that address."

Bam! Bob’s multiple-thread issue is solved, and any potential confusion 
concerning the use of "runrev" is eliminated.

Lyn



___
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: HTML5 teaser

[Lyn Teyla]

Colin Holgate wrote:

> I may have missed a reply too. Which one covered the question of the PDF 
> remaining encrypted after the user has downloaded it?


You added the following 5 requirements after my response containing the 
suggested implementation:

1. The PDF file itself is also to be encrypted with a password.

2. The PDF encryption is not to be performed beforehand using Acrobat.

3. The PDF encryption is to be performed on the server.

4. The PDF file is to remain encrypted upon receipt.

5. The user is to be prompted to enter the password to unlock it.


With your above additional requirements in mind, the suggested implementation 
would be as follows:

- Store the PDF on the server, somewhere outside the web folder so it can’t be 
loaded directly by web visitors.

- Get the user to access the system via a HTTPS connection, which is needed for 
a secure login mechanism anyway.

- The HTTPS connection does all of the encrypting and decrypting so you don’t 
have to code it yourself.

- The user logs in via your LiveCode Server app, which handles the usual user 
authentication stuff using cookies and sessions.

- When the logged in user asks for the PDF file, have your LiveCode Server app 
generate a new password and send it to a command line app that has the ability 
to encrypt PDF files, such as PDFtk:

https://www.pdflabs.com/docs/pdftk-man-page/

- Have that command line app output the encrypted PDF file to a location 
outside the web folder so it can’t be loaded directly by web visitors.

- Have your LiveCode Server app display the newly-generated password on a page 
in the web browser, with an accompanying download link which calls your 
LiveCode Server app.

- When the user clicks the download link, have your LiveCode Server app read 
from the encrypted PDF file and write it out to the web browser (as with any 
other web content), and with the appropriate Content-Type HTTP header.

- Since you’re having all data transmitted over a HTTPS connection, the user’s 
login details as well as the PDF file are encrypted whilst in transit.

- Since your LiveCode Server app is the one deciding whether or not to display 
the PDF (and any other data) based on whether the user is signed in, access can 
be effectively limited to that user.


Lyn




___
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: HTML5 teaser

[Lyn Teyla]

Mark Wieder wrote:

> On 03/04/2016 06:38 PM, Lyn Teyla wrote:
> 
>> Using a HTTPS connection ensures that the PDF file is transmitted securely.
> 
> Uh, sorry, no.
> HTTPS by itself will (mostly) guarantee that you are connected to the server 
> you think you're connecting to. There's no encryption unless you enforce it 
> yourself. The connection itself isn't in cleartext after the initial 
> handshake, so someone listening in on the network traffic won't be able to 
> grab and view the pdf, but unless you're requiring a login and encrypting the 
> file, there's nothing to stop anyone from going to the https url and picking 
> up a copy of the file.


The whole point of HTTPS is _not_ just to authenticate the website, but also to 
encrypt the data in transit:

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

That’s precisely why online banking and ecommerce websites use HTTPS — to 
encrypt credit card and other important data during transmission. The same 
would apply to the PDF file being transmitted via HTTPS.

The OP’s question being answered here was "Does the PDF _travel_ securely?" and 
not "Can anyone go to the HTTPS URL and pick up a copy of the file?". My 
statement was in response to that specific question, which was clearly quoted 
immediate prior to the statement itself.

The latter question had already been addressed in my earlier reply, in which I 
described placing the PDF file outside the web folder on the server, as well as 
a user login mechanism being utilized, per the OP’s initial requirements.

Lyn



___
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: HTML5 teaser

[Lyn Teyla]

Colin Holgate wrote:

> Is LiveCode required in what you say?

You can use LiveCode Server (or any other server-side language) to perform 
those tasks.

> Does the PDF travel securely?

Using a HTTPS connection ensures that the PDF file is transmitted securely.

Lyn



___
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: HTML5 teaser

[Lyn Teyla]

Colin Holgate wrote:

> A PDF is online somewhere. A logged in user asks for it, and the server 
> encrypts it before sending over, using some sort of key that was in the 
> query. On receiving the data, the client side would have to unencrypted it, 
> and show it as the original PDF in a browser.

This only involves LiveCode Server and doesn’t require LiveCode HTML5, 
JavaScript, sending any keys in the query, or writing any PDF files to the 
user’s hard drive.

Here’s a general outline of the implementation:

- Store the PDF on the server, somewhere outside the web folder so it can’t be 
loaded directly by web visitors.

- Get the user to access the system via a HTTPS connection, which is needed for 
a secure login mechanism anyway.

- The HTTPS connection does all of the encrypting and decrypting so you don’t 
have to code it yourself.

- The user logs in via your LiveCode Server app, which handles the usual user 
authentication stuff using cookies and sessions.

- When the logged in user asks for the PDF file, have your LiveCode Server app 
read from the PDF file and write it out to the web browser (as with any other 
web content), and with the appropriate Content-Type HTTP header.

- Since you’re having all data transmitted over a HTTPS connection, the user’s 
login details as well as the PDF file are encrypted whilst in transit.

- Since your LiveCode Server app is the one deciding whether or not to display 
the PDF (and any other data) based on whether the user is signed in, access can 
be effectively limited to that user.

Lyn



___
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: connecting db sqlserver with my app livecode, how?

[Lyn Teyla]

David Alfredo Zuñiga Soto wrote:

> I have an application that I need to drive android.Esta app. gets its data 
> from SQL Server 2008 R2.I have a lot off problems, ps, I used to make free 
> hostings connection, and these are quite limited and my app does not give me 
> permission to coneccion.Al apparently can not make direct communication to 
> the Hosted bd in hosting. se need to use php to Communicate? Where can I 
> learn about it livecoded like server free ?.So, I tried using LiveCode 
> comunity server.but I am new to programming the server side and I have no 
> idea where to start.if someone could explain or tell me where I can start 
> serious pretty cool.

I had already posted a link to this previously, but here it is again:

https://www.hostm.com/tutorials/livecode/api-mariadb-mysql

All the code is there, both client-side and server-side.

You may need to adapt it slightly to suit your SQL Server 2008 R2 setup.

Hope this helps,
Lyn



___
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: mySQL Host access

[Lyn Teyla]

Peter Haworth wrote:

> Is this common practice when accessing mySQL on a host server?  If so, is
> there a better way to set about accessing a mySQL database in these
> circumstances, perhaps using php scripts on the server instead of accessing
> the db directly with the LC database functions?

One of my hosting providers HostM.com has been offering a free LiveCode-based 
MariaDB/MySQL API solution. It was previously available only to clients who 
needed this setup.

I told them about the widespread interest in the LiveCode community for such a 
solution, and they’ve kindly made their API demo available for free download by 
any LiveCode developer.

You can download it at:

https://www.hostm.com/tutorials/livecode/api-mariadb-mysql

Hope this helps!

Lyn



___
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: mySQL Host access

[Lyn Teyla]

Peter Haworth wrote:

> Thanks for that info, that will certainly help me when I start looking into
> LC server.  Unfortunately, I think I'm about 6 months into a 2-year
> contract with my current web host so probably could not switch at this
> point.

The stacks are a free download, and from what I can tell, don’t require you to 
be a HostM.com client. You just need to be able to run LiveCode Server.

Lyn



___
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: HTML5 update: why it is slow?

[Lyn Teyla]

Monte Goulding wrote:

> Personally I’d rather you declare force majeure on wait for HTML5 and apply 
> your considerable talents to implementing non-blocking versions of everything.

Agreed. Won’t the planned improvements to networking include asynchronous 
communication in any case?

If a stop-gap solution for HTTP request support is required, what about the 
suggestions listed at:

http://stackoverflow.com/questions/16987080/whats-the-c-side-of-an-emscripten-xmlhttprequest-call

Lyn



___
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: Charset problems with .lc web page

[Lyn Teyla]

Tim Selander wrote:

> When I first tried your tip, it didn't work for me. But when I looked at the 
> tutorial you linked to, I saw that the
> 
> was the very first line of the .lc file, before  or anything else.
> 
> When I tried that, it worked great!

Thanks for letting us know.

I’ll strive to be clearer next time whilst at the same time reducing message 
length (which has always been a challenge for me — it can be hard to balance 
the two).

Lyn



___
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: Charset problems with .lc web page

[Lyn Teyla]

Tim Selander wrote:

> 1)   --> must be the first line 
> of the .lc
> 2) set the outputTextEncoding to native   -->  must be the first line of the 
> first  script in the file
> 
> If you put "set the outputTextEncoding to native" later in the script, UTF-8 
> above that line will be garbled; after that line it will show properly.

This can get unnecessarily convoluted if you have to keep alternating between 
"native" and "utf-8" outputTextEncodings between different blocks of LiveCode 
script and HTML.

I can imagine that one would tend to forget to change the outputTextEncoding 
somewhere along the way.

Did you run into any problems with the "put header" method that I had 
suggested, where you only need to insert a single line at the top of the file?

I use the single-line solution and it works perfectly fine on many versions of 
revServer and LiveCode Server, including 3.5, 6.6.2 (the one you’re using), 
6.7.8, 7.1.1, and 8.0.0 DP 12.

This article on HostM.com also mentions the same solution. Perhaps it explains 
it better than I did:

https://www.hostm.com/tutorials/livecode/utf-8-output

Lyn



___
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: More questions regarding Server oddities

[Lyn Teyla]

Tim Selander wrote:

> Copy and paste the url into the browser, and the text loads up. The csv file 
> is in the very same directory as the .irev file 
> (http://www.pba.on-rev.com/ynh5today.irev). Both are in the root of the 
> public_html folder. But the {put URL 
> "http://pba.on-rev.com/ynh5list_UTF8.txt; into vlist} command returns a 404 
> error.

Since the CSV file resides on the same server, there’s no need to use "put url" 
with a HTTP URL.

Well, you *could* if you really wanted to, but then you’d be introducing 
unnecessary (albeit brief) wait time into the mix since it would to transmit 
the data over the HTTP network protocol.

Instead, simply read from the file locally using:

put url "binfile:ynh5list_UTF8.txt" into vlist

That said, using a HTTP URL, if you really wanted to, should still work, as 
mentioned above.

However, keep in mind that LiveCode Server (and its older cousin revServer) 
have had various bugs and other issues with performing network operations using 
"put url" before.

These have been largely resolved, so they should work fine if you use the 
latest versions of LiveCode Server.

You mentioned using revServer (which could be as old as version 3.5 on On-Rev’s 
servers!) and LiveCode 6.6.2, both of which are much older than 7.1.1.

There’s often not much point in trying to debug issues whilst running an older 
version of LiveCode. Always perform the same tests with the latest version to 
eliminate the possibility of an issue being caused by a bug in an older version.

Try 7.1.1, which is currently the highest version that’s labeled "stable". It 
can be downloaded at:

http://downloads.livecode.com/livecode/

Hope this helps!

Lyn



___
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: Happy Christmas!

[Lyn Teyla]

Kevin Miller wrote:

> Merry Christmas everybody. Thanks for making the LiveCode community what it 
> is. I hope you are all having a wonderful holiday. 

Peter TB Brett wrote:

> Happy Christmas to all our users and contributors!


Season’s greetings guys, and may you have a prosperous new year.

Lyn



___
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: More questions regarding Server oddities

[Lyn Teyla]

Alex Tweedly wrote:

> I think you both missed the point about Tim's original problem :
>   his page works with the OLD rev Server, and fails with the latest LC server 
> (6.6.2)
> 
> So while I agree that it is probably better to not pursue issues in old 
> versions, I don't think Tim has much choice, unless someone can come up with 
> some suggestions on the original issue.

6.6.2 is not the latest version of LiveCode Server.

The suggestion that I had put forth regarding the original issue was for Tim to 
perform both of the following:

1. Use the "put header" line provided;

and

2. Utilize any one of the latest versions of LiveCode: 6.7.8, 7.1.1 or 
8.0.0dp12.

That would indeed fix the original issue.

I had personally tested the above solution to confirm that it does indeed work 
with the said versions.

Hope this provides additional clarity! :)

Lyn



___
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: More questions regarding Server oddities

[Lyn Teyla]

Peter W A Wood wrote:

> I don’t think the problem is related to the HTTP Header. It is the same for 
> both Tim’s rev page and his lc page:
> 
>   

Having a "Content-Type" meta tag is not the same as implementing a 
"Content-Type" HTTP header via the "put header" command.

The former is generally used by a web browser when a HTTP header containing the 
desired charset is not present, typically when displaying local (offline) HTML 
pages, so it knows what to use.

When it comes to determining the charset of a page that’s served online, 
however, a web browser’s first port of call is the "Content-Type" HTTP header, 
which as mentioned in one of my earlier replies, can be specified using:

   put header "Content-Type: text/html; charset=" & quote & "utf-8" & quote

For more information about HTTP headers, visit:

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

If you’re curious as to why the meta tag happens to work with revServer 3.5 but 
not later versions of LiveCode Server such as 6.6.2:

The technical reason is that older versions such as revServer, by default, 
output the following HTTP header if the above "put header" statement isn’t 
specified:

   Content-Type: text/html

Since no charset is specified by default, some web browsers then take the meta 
tag into account.

Later versions of LiveCode Server (including the current versions), by default, 
output the following HTTP header if the above "put header" statement isn’t 
specified:

   Content-Type: text/html; charset=iso-8859-1

While this change in the default behavior of LiveCode Server is a somewhat 
unorthodox (I personally don’t agree with the concept of forcing a particular 
charset by default), it might be a stretch to call it a bug, since there’s a 
perfectly valid way of specifying the charset using the "put header" method.


> Tim doesn’t really have a choice over which version of the server to use with 
> the On-Rev service. The version is chosen by LiveCode.

It’s certainly true that Tim doesn’t have control over the built-in version of 
LiveCode Server with the On-Rev service. Nevertheless, he doesn’t have to be 
stuck with that at all, as he could install the desired version per the usual 
.htaccess method:

http://lessons.livecode.com/spaces/lessons/buckets/809/lessons/36655

Tim did mention that he had tried his scripts from a non On-Rev server, so I’m 
assuming he already knows how to install the desired version.


Feel free to let me know if anything requires further clarification.

Lyn



___
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: Scrolling Smoothly through Large Scripts

[Lyn Teyla]

Ray wrote:

> Does anybody know how to scroll just one line per mouse-wheel movement 
> through the script editor window?
> 
> I typically view several thousand lines at a time.  Each push of the little 
> scroll wheel on my mouse produces an abrupt 'jerk' of 10 or 15 lines.  It's 
> really hard on the eyes by the end of the day.


This is an important issue that affects not just current developers but also 
those looking at LiveCode as a possible tool for their projects.

The ability to not just scroll smoothly, but at the correct velocity based on 
user input, has been a basic requirement for any modern app for many years now.

It’s so fundamental that it’s become a subconscious requirement — end users and 
developers may not immediately realize what the issue is, but they know 
something’s not right.

It affects not just the script editor, but all LiveCode fields in general.

Some, like NASA (in-house apps) and EuroTalk (multimedia apps) may not care too 
much about this, but many do.

First impressions last, and what may seem like a tiny, low-priority issue is 
silently causing unnecessary attrition, affecting LiveCode’s revenue as well as 
those of LiveCode developers.

Please have a look at this bug report that I opened in 2008 and contribute any 
additional feedback to hopefully help bring it back into focus:

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

Many thanks! :)

Lyn



___
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: Charset problems with .lc web page

[Lyn Teyla]

Tim Selander wrote:

> I'm having trouble making a .lc web pages correctly show the charset.
> Anyone else having problems with this? Can .lc files not handle charset 
> correctly?

Try inserting the following 3 lines right at the top of your .lc script, 
leaving everything else untouched:




Hope this helps!

Lyn




___
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: Charset problems with .lc web page

[Lyn Teyla]

Lyn Teyla wrote:

> Try inserting the following 3 lines right at the top of your .lc script, 
> leaving everything else untouched:
> 
>  put header "Content-Type: text/html; charset=utf-8"
> ?>


There was a slight typo (missed the quotes); try this at the top of the script:




Lyn :)



___
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: Charset problems with .lc web page

[Lyn Teyla]

Tim Selander wrote:

> But I tried it, and it didn't solve the problem with .lc & . However, 
> without fail, using .irev as the filename extension and  tags in the 
> web page show utf8 Japanese correctly -- so I am content to use those. 
> Problem solved, as far as I'm concerned.

The “put header” method works just fine with current versions of LiveCode 
Server 6, 7, and 8, so you likely ran into bug that existed in 6.6.2.

Running any of the current versions of LiveCode Server resolves the issue, so 
there’s no need to report this as a bug.

Lyn



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

[Lyn Teyla]

Jeanne A. E. DeVoto wrote:

> This was changed because for very long scripts, indenting the entire script 
> (instead of just one handler) could cause a considerable pause when 
> indenting. (HyperCard did the whole script, but HyperCard also had a 32K 
> limit on a single script.)
> 
> This was quite a while ago, and it's possible that it would not be much of an 
> issue now with faster CPUs. But that's why it changed.

Thanks Jeanne for the info! :)

Lyn



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

[Lyn Teyla]

Peter TB Brett wrote:

> When I have the time, I'd really like to split the script indenting & 
> formatting code out from the script editor into a separate library.
> 
> That would make it much easier for people to use and re-use, not only in IDE 
> extensions etc. but also in other applications.  It might make it easier to 
> test/improve/maintain too!

Some years back, pressing the  key to trigger indenting used to affect the 
entire script, but then it got changed to only affect the current handler for 
some reason.

This could be a good opportunity to revive the previous behavior, which was a 
time-saver when triggered after pasting unformatted scripts containing multiple 
handlers.

Would this be considered a bug? If so, I could submit a bug report.

Lyn



___
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: ASK dialog box

[Lyn Teyla]

Hi Randy,

As Klaus mentioned, when the 'Cancel' button is pressed, not only is "it" set 
to empty, but "the result" is also set to "Cancel".

If the user leaves the dialog blank by pressed 'OK', then both "it" and "the 
result" are set to empty.

-

on mouseUp
   ask "Are you a bunny?"
   if the result is "Cancel" then...
   ...
end mouseUp

-

Lyn



> On Nov 25, 2015, at 6:17 PM, Randy Hengst  wrote:
> 
> Hi Klauss,
> 
> Yes, I did find that Cancel put EMPTY into it.
> 
> The catch is, so does selecting OK when the user leaves the dialog empty.
> 
> I’d like to respond in different ways depending on the user selecting Cancel 
> versus OK.
> 
> I can’t find a way to trap for which button is pressed since in both cases it 
> seems that EMPTY is placed in “it”
> 
> Thoughts?
> 
> be well,
> randy
> 
> Randy Hengst
> www.classroomFocusedSoftware.com
> 
> 
>> On Nov 24, 2015, at 11:47 AM, Klaus major-k  wrote:
>> 
>> Hi Randy,
>> 
>>> Am 24.11.2015 um 18:44 schrieb Randy Hengst :
>>> 
>>> Hi All,
>>> 
>>> I’ve include an ASK command in a new app. 
>>> 
>>> It was my understanding (though I don’t see this in the dictionary) that 
>>> “Cancel” is placed in the “it” variable when the user selects “Cancel."
>>> However, the “it” variable seems to be empty… which is the same way “it” 
>>> appears when no information is entered into the ASK dialog box and “OK” is 
>>> pressed.
>>> I’d like to do one thing when the user “Cancels” and another when the user 
>>> simply leaves the dialog blank, but presses OK.
>>> Is there a way to discern between an “OK” with no information added and a 
>>> “Cancel”?
>> 
>> If the user hits „Cancel":
>> IT = EMPTY
>> the result = Cancel
>> :-)
>> 
>>> be well,
>>> randy
>>> 
>>> Randy Hengst
>>> www.classroomFocusedSoftware.com
>> 
>> Best
>> 
>> Klaus
>> 
>> --
>> Klaus Major
>> http://www.major-k.de
>> kl...@major-k.de
>> 
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> ___
> 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: JSON library

[Lyn Teyla]

Ali Lloyd wrote:

> The JSON library is an extension and so you need to include it manually (at
> least at the moment) - you'll need to select com.livecode.library.json in
> the Copy Files pane of the standalone settings.


On a somewhat related note, how does one utilize this JSON library (and other 
libraries implemented as extensions) on LiveCode Server?

Lyn



___
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: Converting HTML to Jade?

[Lyn Teyla]

Terry Vogelaar wrote:

> Does anyone know if there is an easy way to convert HTML to Jade from within 
> a LiveCode script?

I use the html2jade command line tool:

https://github.com/donpark/html2jade

You can run it from within LiveCode using the "shell" or "open process" 
commands, thereby integrating it directly into your workflow.

Lyn



___
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: What happens when enabling Hi-DPI scaling?

[Lyn Teyla]

Tiemo Hollmann TB wrote:

> Do you enable "Hi-DPI scaling" in the standalone settings for windows since
> 6.7.7 by standard or never? (I can't test the difference myself, not having
> a Hi-DPI monitor)


There's currently a bug relating to the Windows Hi-DPI status in the standalone 
settings window.

It *is* enabled by default, but often incorrectly shows up as being disabled in 
the settings window.

A temporary fix was provided by Panos at:

http://quality.runrev.com/show_bug.cgi?id=15694

Lyn




___
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: Compare numeric strings with leading zeros

[Lyn Teyla]

Thierry Douez wrote:

> on mouseUp
>   local userTyping = 5
>   local myVeryStrongPassword = "005"
>   if matchText( userTyping, myVeryStrongPassword) then
>  answer "Great!"
>   else
>  answer "Too bad :( try again.."
>  put "005" into userTyping
>  if matchText( userTyping, myVeryStrongPassword) then answer "Great!"
>   end if
> end mouseUp

I would caution against using matchText for this purpose, because the second 
parameter is treated by the function as a regular expression.

For instance, matchText would return true if you were to reverse your example 
values:

   local userTyping = "005"
   local myVeryStrongPassword = 5

This is because 005 does indeed contain 5.

In addition, since passwords are typically allowed to contain any character, 
including those that have special meaning in regular expressions, something 
like this would also return true:

   local userTyping = "5"
   local myVeryStrongPassword = "^5$"

With this in mind, I would go with the method of first checking the length 
followed by the values as suggested by a couple of previous posters.

Since Ralph is looking to use this for password validation, I would throw in a 
case sensitivity check as well:

on mouseUp
   put stringsAreEqual("005", "5")
end mouseUp

function stringsAreEqual pString1, pString2
   set the caseSensitive to true
   if (len(pString1) = len(pString2)) and (pString1 = pString2) then
  return true
   end if
   return false
end stringsAreEqual


Hope this helps!

Lyn



___
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: Compare numeric strings with leading zeros

[Lyn Teyla]

Thierry Douez wrote:

> put  "\Q^5$\E"  into  myVeryStrongPassword
> if matchText( userTyping,  myVeryStrongPassword ) then ...

Here is indeed an example of the danger involved with the use of regular 
expressions.

It can be easy to miss things at times, which is why I simply cautioned against 
using it, rather than completely advise against it.

There are many ways to skin a cat, so yes, whilst it *is* possible to utilize 
Regex to perform certain tasks if done correctly, it's also easy to make 
mistakes (hence the caution) even for those who are comfortable with Regex.

> Ok, now I'm waiting for what I've missed...


Your revised example was missing a "^" at the beginning and a "$" at the end.

   put "^\Q^5$\E$" into myVeryStrongPassword

Here is an example showing the issue:



on mouseUp
   local userTyping = "00^5$6"
   local myVeryStrongPassword = "^5$"
   put stringsAreEqual(userTyping, myVeryStrongPassword) & cr into msg
   put stringsAreEqual.err(userTyping, myVeryStrongPassword) & cr after msg
end mouseUp

function stringsAreEqual pString1, pString2
   return matchText(pString1, "^\Q" & pString2 & "\E$")
end stringsAreEqual

function stringsAreEqual.err pString1, pString2
   return matchText(pString1, "\Q" & pString2 & "\E")
end stringsAreEqual.err



Hope this clarifies things.

Lyn



___
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: Open Source Kickstarter Report Card

[Lyn Teyla]

Ali Lloyd wrote:

 I doubt we will be writing a whole new script editor from scratch in one
 go. More likely we will replace individual elements with widgets (as has
 been done with the variables pane) to make sure all the components work as
 expected.

Assuming one of the elements to be replaced with widgets is the field control 
used to display code in the script editor, will it result in the following 
long-standing scrolling issue (opened since March 2008) being resolved?

http://quality.runrev.com/show_bug.cgi?id=6286

Scrolling a fixed number of pixels at a time (rather than pixel-by-pixel + 
delta parameter based on scrolling speed) might seem to some to be a seemingly 
insignificant issue that could result in it being assigned a low priority.

Unfortunately, it causes a very noticeable effect that makes the LiveCode IDE 
and standalone apps look less polished and native-like than modern apps.

Fixing the scrolling issue would greatly improve the scrolling experience 
within the script editor, the IDE, and standalone apps.

More people impressed by the LiveCode environment and its apps = more $$$ for 
LiveCode Ltd. :)

It's even possible that the code required to fix this already exists elsewhere 
within the engine (see comment 5 on that page).

Lyn



___
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: libCurl wrapper using LiveCode Builder [was: Re: SFTP support]

[Lyn Teyla]

Peter TB Brett wrote:

 The LiveCode engine can already do secure communication using SSL (Secure 
 Socket Layer).  It would *probably* be possible to use secure socket to 
 implement FTPS (FTP over SSL) in scripts, without any engine changes (i.e. in 
 libUrl).



Given the following:

1. libCurl already performs many useful protocols (both secure and standard) 
such as HTTP, HTTPS, FTP, FTPS, SFTP, IMAPS, SMTPS, etc.:

http://curl.haxx.se/libcurl/

2. libCurl appears to already be included by the LiveCode engine:

http://forums.livecode.com/viewtopic.php?f=66t=19561

3. LiveCode's roadmap includes a revamp of networking/sockets using the new 
open language feature:

https://livecode.com/resources/roadmap/



Have you guys at LiveCode Ltd thought about implementing this revamp of 
networking/sockets by simply writing a libCurl wrapper using LiveCode Builder?

There are a number of benefits to this:

1. The hard part would have been already taken care of by the libCurl people. 
Let them take care of all the protocol negotiation and keep up with any related 
security matters (which they do). No point re-inventing the wheel — just keep 
libCurl up-to-date with each new build of LiveCode.

2. LiveCode would support SFTP (among many others) right out of the box for all 
licenses, so Brahmanathaswami and others would be happy.

3. True non-blocking communication would presumably be possible, with it being 
handled by an LCB external rather than standard scripting.

4. Written in LiveCode Builder means more people from the community would be 
able to add to it if necessary.

5. We could have a full libUrl replacement (and more) by the time 8.0 is 
released.



If you guys at LiveCode Ltd could whip up a quick working LCB extension for the 
libCurl wrapper containing a couple of examples showing how it's done, I'm sure 
some members of the community (myself included) would be more than happy to 
help do the mundane work of fleshing it out per your instructions (so you can 
focus on other goals).

Any thoughts?

Lyn :)





___
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: libCurl wrapper using LiveCode Builder [was: Re: SFTP support]

[Lyn Teyla]

Peter TB Brett wrote:

 On 2015-08-19 20:27, Lyn Teyla wrote:
 
 Have you guys at LiveCode Ltd thought about implementing this revamp
 of networking/sockets by simply writing a libCurl wrapper using
 LiveCode Builder?
 
 Yes -- one of our very first, high priority ideas for an LCB-based project.  
 I even made a start on it, and I have an internal project [1] that would 
 really benefit from it.  However, it's not yet technically possible, I'm 
 afraid.
 
 I expect the necessary LCB language features to appear in a LiveCode 8.x 
 release, where x  0.  Some of them are floating around in Mark Waddingham's 
 GitHub repository in various states of completion.

Thanks for the info. Looking forward to it. :)

Just for clarity, could you elaborate on what you said earlier:

 The regular requests for SFTP support are noted and SFTP support is on our 
 internal list of feature requests -- indeed, I was recently discussing it 
 with Mark Waddingham.  However, it will be a large project that will involve 
 writing and thoroughly testing a lot of new, security-critical code.  When we 
 have the resources available to implement it, it will therefore very likely 
 be introduced an extension available to LiveCode Business customers.

If a libCurl wrapper using LCB is in development, wouldn't the above be a 
non-issue? That is, adding SFTP (or any other libCurl-supported protocol) 
shouldn't need to involve writing and testing a lot of new, security-critical 
code, since libCurl has already taken care of that? Or am I missing something?

Lyn



___
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: libCurl wrapper using LiveCode Builder [was: Re: SFTP support]

[Lyn Teyla]

Peter TB Brett wrote:

 On 2015-08-19 21:53, Lyn Teyla wrote:
 
 If a libCurl wrapper using LCB is in development, wouldn't the above
 be a non-issue? That is, adding SFTP (or any other libCurl-supported
 protocol) shouldn't need to involve writing and testing a lot of new,
 security-critical code, since libCurl has already taken care of that?
 Or am I missing something?
 
 It's not in development.  I started it (i.e. I wrote about 100 lines of 
 code and opened a massive can of worms in the process).  Then I stopped and 
 found a different solution.

Ah, didn't realize that. Thanks for the clarification.

 There's a *lot* of research and development still to do before we can produce 
 a generally-useful LCB URL library based on libcurl.  That doesn't mean that 
 we don't want to do it, or that we don't think it's worth doing!  It *does* 
 mean that, if we're talking about an internally-funded project, we're much 
 more likely to be able to provide a Business-only SFTP extension than do a 
 big refactor around LCB and libcurl.  This is just the reality of the 
 resources available.
 
 On the other hand, if there was external funding for such a project...

But that's just it — the network/sockets revamp using open language (presumably 
LCB) *is* one of the items on the roadmap from the Kickstarter campaign. While 
SFTP isn't specifically mentioned, that generally-useful LCB URL library is. 
Here's the roadmap again:

https://livecode.com/resources/roadmap/

What I'm trying to say is that if you were to go the libCurl (or another 
similar ready-made library) route, then not only would you have the 
generally-useful LCB URL library, but it'd then be much easier to add SFTP 
and other protocols via that same LCB library.

Otherwise, you guys would be spending extra time unnecessarily reinventing the 
SFTP wheel, yet still only benefit Business license holders, whilst not meeting 
one of the goals on the roadmap upon implementation (pretty much a 
lose-lose-lose situation).

You did just mention that it's a big refactor around LCB and libCurl, so it 
sounds like a lot of work is going to be involved just to get an LCB URL 
library ready.

I hadn't expected *that*, as my (possibly erroneous) impression during the 
fundraiser was that open language (LCB), once in place, would allow for the 
easy wrapping of just about any external library, since a revamp of the 
Database library via LCB is also listed on the roadmap.

TL;DR:

1. Business-only SFTP = waste of precious time that could have been spent on 
other things

2. LCB URL library = good use of time that meets a goal for something that 
*has* been funded!

I suppose what it comes down to is that you might have mistaken the LCB URL 
library to be an internally-funded project, when it's actually an externally 
funded one.

Hope this makes sense. :)

Lyn





___
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: Open Source Kickstarter Report Card

[Lyn Teyla]

Richard Gaskin wrote:

 On the one hand I don't recall any specific promises made about PDF rendering 
 in terms of licensing, but on the other hand that PDF widget was the example 
 used in Kevin's video from July 2014 to demonstrate the v8 architecture we 
 all funded in the Kickstarter campaign, so I doubt he intends that one to be 
 proprietary-only:
 https://livecode.com/the-next-generation-widgets-themes/
 
 Has anyone heard otherwise?

It's listed (under 'Add Ons you can get with credits') as Business-only on the 
pricing page:

https://livecode.com/products/livecode-platform/pricing/

Lyn



___
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: Business Application Framework

[Lyn Teyla]

Hi all,

I agree with many of the posters to this thread thus far that it would appear 
to be a mistake to offer, at this time, solely with the Business license, 
additional features such as built-in GIT compatibility, OOP and MVC.

I would go one step further and suggest, if I may, that it might, perhaps ;), 
be a good idea to have feature parity across all licenses, with the sole 
exception being password protection (but only due to its obvious 
incompatibility with the GPL).

Having feature parity would serve not only to reduce confusion, but also to 
allow the entire LiveCode community (paid + open source) to flourish more 
rapidly, which is one of the goals of LiveCode Ltd. These announced additional 
features are useful to many, not just Business licensees.


Just the built-in GIT compatibility alone, for example, would bring about the 
following benefits:

1. The open source community would flourish, with both individuals and groups 
all over the world sharing their code on GitHub. People link to their GitHub 
pages from their websites. Many would come to know that LiveCode is such an 
easy yet powerful language. This is a free and potent marketing channel i.e. 
more $$$ for LiveCode Ltd.

2. GIT is not only useful for groups, but also individuals, including Indy 
licensees. GIT is utilized for version control, with users benefiting from the 
automatic documentation of code changes, which is valuable for a wide variety 
of projects.

3. The presence of public GitHub repositories allows LiveCode to project a more 
professional image to the coding community and decision makers at all levels, 
including single-member decision makers, attracting those who would not 
otherwise have considered LiveCode as a candidate for their projects. So again, 
more $$$ for LiveCode Ltd.

4. Developers who are familiar with other languages and GIT would find built-in 
GIT compatibility to be a plus, and the lack of one (and having to use a 
third-party tool for such) to be a minus. More developers = more $$$ for 
LiveCode Ltd.

5. GitHub pages are known to be an excellent way for developers to attract 
prospective employers. More employment opportunities = happier developers = 
happier employers = even more $$$ for LiveCode Ltd.


With regard to object-orientation and MVC:

1. Whilst such concepts might sound imposing to some, it helps draw programmers 
who are already familiar with these concepts, and who expect to find them in 
any professional language offering. Here's an example:

https://www.linkedin.com/grp/post/50811-5908638845246656513

2. As with built-in GIT compatibility, just having these features would help 
bolster LiveCode's image to just about everyone — developers, the general 
public, and decision makers alike.

3. For users who think these features are unnecessary or too complicated, they 
could always choose not to use them, just as they don't use any other feature 
that they don't want, while users who need them can jump right in — everyone's 
happy.


With regard to bringing more value to the Business license:

1. There might not be a need to do that using features specifically. Since 
there are the the $500K + single-member restrictions for Indy licensees, those 
who get a Business license get it not because they want more features. They're 
making more money, are legally obliged to pay more, can afford to do so, and 
therefore do so.

2. I agree with Brahmanathaswami that a good way to differentiate the Business 
license is the inclusion of a higher level of support (which was indeed already 
mentioned in the announcement). Since Business licensees pay more, they're 
entitled to enhanced and priority service. Sounds reasonable.


With the above in mind, in the following comparison chart:

https://livecode.com/products/livecode-platform/pricing/

Feature parity would mean making the following items available to all licenses 
(green ticks across all columns):

- Business App Framework (which could be renamed as appropriate)
- Cloud  Data Sync
- PDF Viewer
- Mobile camera support

All other Business-only items (enhanced support and services) would remain 
untouched.


I believe the increase in the number of coders using LiveCode as a result of 
implementing feature parity would result in benefits to LiveCode's bottomline 
that far outweigh anything (if any) that would be gained by offering certain 
features only to Business licensees.

This is because doing the latter would possibly serve mainly to alienate the 
open source community (no expected features like GIT, OOP and MVC) as well as 
Indy licensees (ditto, plus the recent increase in price).

At the same time, the coding landscape is rapidly changing, with Apple 
open-sourcing Swift, and Microsoft aggressively laying cross-platform bridges, 
and with all native features included.

Everything that I have suggested here is intended to be viewed as an attempt to 
ensure the continued prosperity of LiveCode Ltd.

I hope LiveCode Ltd can take 

Re: mergJSON, externals and Livecode Server

[Lyn Teyla]

David Bovill wrote:

 Monte's external is available for all platforms - so it should work on the
 server I think the the mergJSON.so is the version I believe that is used
 on Linux. Puttin it in the cgi bin along side the built in externals does
 not seem to be sufficient. How does basic extension configuration work on a
 server?

If you're running the 64-bit version of Ubuntu 14.04, mergJSON doesn't work off 
the shelf, since there's currently only a 32-bit version available officially.

There's a forum thread concerning the issue, including a tip from Monte on how 
you can temporarily recompile your own:

http://forums.livecode.com/viewtopic.php?t=24328p=125968

Alternatively (and as a possibly less desirable option, depending on your 
needs), you could install the 32-bit libs for Ubuntu, then run the 32-bit 
version of LiveCode Server 7.

Note that the 64-bit version of LiveCode Server 7 does run into at least one 
other known issue, which is that the included dbsqlite.so driver isn't 
functioning (if you need that):

http://quality.runrev.com/show_bug.cgi?id=15573

There may be other issues that I'm unaware of. Otherwise, it runs well for the 
most part.

Lyn



___
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: arrays with merge

[Lyn Teyla]

 function myArray pString
   return myArrayTest[pString]
 end myArray

Small typo:

myArrayTest[pString]

should of course be:

myArray[pString]



___
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: arrays with merge

[Lyn Teyla]

 Terence Heaford t.heaf...@icloud.com wrote:
 
 This line gives a syntax error, obviously because an array does not work in 
 merge?
 
 put merge(SELECT [[tColumns]] FROM '[[tTable]]' [[myArray[test]]] 
 [[tSortOrder]]) into tSQL
 
 Is there a way around this or do I have to resort to using ?



Method 1: Turn it into a 2-liner:


put myArray[test] into tTest
put merge(SELECT [[tColumns]] FROM '[[tTable]]' [[tTest]] [[tSortOrder]]) 
into tSQL




Method 2: Have the entire string to be merged already stored elsewhere:


put merge(the uSQL of me) into tSQL

or

put merge(url file:sql.txt) into tSQL


where the custom property uSQL or the file sql.txt already contains the 
string:

SELECT [[tColumns]] FROM '[[tTable]]' [[myArray[test]]] [[tSortOrder]]



Method 3: Use a function to represent an array:


local myArray -- make sure this is outside both handlers

function myArray pString
   return myArrayTest[pString]
end myArray

on doStuff
   -- some stuff here
   put merge(SELECT [[tColumns]] FROM '[[tTable]]' [[myArray(test)]] 
[[tSortOrder]]) into tSQL
   -- more stuff here
end doStuff


This last method works as long as the name of the key (test in your example) 
isn't a LiveCode reserved word.


Hope this helps! :)

Lyn




___
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: Obtaining names of current and calling handlers?

[Lyn Teyla]

Thanks Richard — these work perfectly!

Lyn


 On Feb 12, 2015, at 7:28 AM, Richard Gaskin ambassa...@fourthworld.com 
 wrote:
 
 Lyn Teyla wrote:
  1. How does one obtain the name (and its location/object) of
  the handler/function that called the current handler/function?
 
 the executionContexts
 
 
  2. How does one obtain the name of the current handler/function
  that's running?
 
 Word 1 of the params
 
 -- 
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for Desktop, Mobile, and Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription 
 preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode


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

Obtaining names of current and calling handlers?

[Lyn Teyla]

Hi all,


1. How does one obtain the name (and its location/object) of the 
handler/function that called the current handler/function?


on cheers
   hello
end cheers

on hello
   put the name of the calling handler -- hypothetical; would have returned 
cheers
end hello



2. How does one obtain the name of the current handler/function that's running?


on hello
   put the name of this handler -- hypothetical; would have returned hello
end hello



Thanks in advance for any insight.

Lyn




___
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

Run a handler each time a handler/function within current script is run?

[Lyn Teyla]

Hi all,


How does one automatically run a handler each time a handler/function within 
the current script is run?

I'm looking for a proper/non-clumsy way of implementing the following:


private command doSomeStuff
   -- stuff that must be done each time _any_
   -- handler/function within this script is called
end doSomeStuff

on hello
   doSomeStuff
   put hello world
end hello

on another_handler
   doSomeStuff
   put testing
end another_handler

function some_function
   doSomeStuff
   return something
end some_function



Thanks in advance for any insight.

Lyn




___
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

Will the new Widgets system allow LiveCoders to implement these?

[Lyn Teyla]

Hi all,

A preview of the Widgets  Themes project was shown last month by Kevin:

http://livecode.com/blog/2014/07/08/the-next-generation-widgets-themes/



Will the following missing GUI items be possible to implement via Widgets (i.e. 
solely via the new lower-level LiveCode)?

1. _Native_ transluscent blur effects (without faking it) on specified portions 
of the stack/card background (independently, i.e. without affecting its 
objects' opacities) as well as for individual objects and/or entire groups:

http://forums.livecode.com/viewtopic.php?f=49t=17609

2. Create a system menu bar icon:

http://forums.livecode.com/viewtopic.php?f=7t=14125

3. Create _native_ toolbars (and toolbar elements including buttons, search 
boxes, full-screen icon, etc.) without faking it:

http://forums.livecode.com/viewtopic.php?f=19t=14272

4. Embed CEF browser (third party library) with JavaScript integration on all 
platforms rather than just OS X and Windows:

http://quality.runrev.com/show_bug.cgi?id=12698

5. Display _native_ alert boxes (again, without faking it which is what the 
current 'answer' command does) containing built-in elements such as Message 
Text, Informative Text, Accessory View, Icon, Title, Buttons, etc.:

https://developer.apple.com/library/mac/documentation/userexperience/conceptual/applehiguidelines/Windows/Windows.html#//apple_ref/doc/uid/2961-TP10



In the Widgets  Themes presentation, it was also mentioned that new networking 
and database layers will be developed using Widgets, with the final goal being 
to have nearly all of LiveCode written in LiveCode itself.

This implies that Widgets are not limited to GUI elements, since it can 
interface with non-GUI routines (e.g. networking) and those from third-party 
libraries (e.g. databases).

Does this mean that it will be possible to use Widgets to (again, solely via 
the new lower-level LiveCode):

6. Extend dragDestination (or implement an alternative to dragDestination) to 
return file paths:

http://quality.runrev.com/show_bug.cgi?id=8634

7. Hook into the notification manager of each platform, e.g. enabling the 
ability to bounce the dock icon on OS X, etc.:

http://lists.runrev.com/pipermail/use-livecode/2011-August/159957.html



Once again, for all of the above, I am referring _strictly_ to the use of the 
new lower-level LiveCode that is used to implement Widgets. That means:

(a) No faking it (drawing your own non-native stuff); and

(b) Non-involvement of any other programming language (e.g. C, etc).



Many thanks for any information that you can provide.

Best,
Lyn



___
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: Post-KickStarter LiveCode - security issue fix?

[Lyn Teyla]

Thanks Kevin, looking forward to the security improvements.

Lyn



On Feb 27, 2013, at 8:35 PM, Kevin Miller wrote:

 This is a common problem with high level languages and has always been
 present not only in our platform, but in many others throughout history.
 We do have various ideas about how to further improve code security in the
 commercial edition and look forward to implementing those during the
 restructure.
 
 Kind regards,
 
 Kevin
 
 Kevin Miller ~ ke...@runrev.com ~ http://www.runrev.com/
 LiveCode: Everyone can code
 
 
 
 
 On 27/02/2013 18:08, Lyn Teyla lyn.te...@gmail.com wrote:
 
 Hi all,
 
 It has been 3 years since my post to this list urging RunRev to fix the
 serious security issue where the scripts of password protected stacks and
 standalone apps can be fully viewed via memory dumps.
 
 This is because password protected scripts remain unencrypted in memory
 after compilation. That's right, no password is needed, the code is right
 there in memory.
 
 The issue was also lodged via the LiveCode Quality Control Center (LQCC)
 as report #8672:
 
 http://quality.runrev.com/show_bug.cgi?id=8672
 
 In September 2010, Mark Waddingham finally responded to the LQCC report,
 saying that the issue would be eliminated in 5.0 with the move to Unicode.
 
 He then marked the LQCC report as private.
 
 Alas, even after the move to Unicode, the issue remains unresolved.
 
 In September 2011, I requested for a RunRev response via the LQCC report,
 and received none.
 
 In August 2012, I once again requested for a response, and finally
 received a reply from Your Quality Team, who said they did not have an
 expected target release for this fix yet.
 
 They then set the report to Hibernating mode, which sure doesn't sound
 good.
 
 It is now 2013. Post-KickStarter, RunRev will be implementing a revamp to
 LiveCode, while offering dual-licensing.
 
 Given that the main difference between the commercial version and the
 open source version is script security, this has become an issue of even
 greater importance.
 
 And yet, there has been no word about when this security issue will be
 fixed.
 
 The LQCC report remains hibernated.
 
 So the question is, when exactly will this issue finally and actually be
 fixed?
 
 Also, if it still isn't fixed once dual-licensing is up and running, then
 what would be the point of releasing closed-source applications when the
 code is going to be right there in memory unencrypted, for thieves to
 steal?
 
 Does no one else think this is an important issue that needs to be
 addressed immediately?
 
 - Lyn
 
 
 
 
 ___
 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

Post-KickStarter LiveCode - security issue fix?

[Lyn Teyla]

Hi all,

It has been 3 years since my post to this list urging RunRev to fix the serious 
security issue where the scripts of password protected stacks and standalone 
apps can be fully viewed via memory dumps.

This is because password protected scripts remain unencrypted in memory after 
compilation. That's right, no password is needed, the code is right there in 
memory.

The issue was also lodged via the LiveCode Quality Control Center (LQCC) as 
report #8672:

http://quality.runrev.com/show_bug.cgi?id=8672

In September 2010, Mark Waddingham finally responded to the LQCC report, saying 
that the issue would be eliminated in 5.0 with the move to Unicode.

He then marked the LQCC report as private.

Alas, even after the move to Unicode, the issue remains unresolved.

In September 2011, I requested for a RunRev response via the LQCC report, and 
received none.

In August 2012, I once again requested for a response, and finally received a 
reply from Your Quality Team, who said they did not have an expected target 
release for this fix yet.

They then set the report to Hibernating mode, which sure doesn't sound good.

It is now 2013. Post-KickStarter, RunRev will be implementing a revamp to 
LiveCode, while offering dual-licensing.

Given that the main difference between the commercial version and the open 
source version is script security, this has become an issue of even greater 
importance.

And yet, there has been no word about when this security issue will be fixed.

The LQCC report remains hibernated.

So the question is, when exactly will this issue finally and actually be fixed?

Also, if it still isn't fixed once dual-licensing is up and running, then what 
would be the point of releasing closed-source applications when the code is 
going to be right there in memory unencrypted, for thieves to steal?

Does no one else think this is an important issue that needs to be addressed 
immediately?

- Lyn




___
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