Re: mouseenter/mouseleave and pointer tool

[Richard Gaskin via use-livecode]

Jim Lambert wrote:

> Every time I click on a button in the IDE with the pointer tool
> in order to select and, say, move it, I'd prefer if the mousedown/up
> scripts didn't fire off because I'm editing the UI not running it.
> If I recall correctly this was not how LC/Revolution originally
> behaved.

It still does. I don't believed anything with mouse message handling has 
changed in many years, if at all.


I haven't seen how Klaus came across the mouseEnter message, so I can't 
begin to guess how this is only coming to his attention now.


Either way, with the engine having worked as it does with tool messages 
since 1992 I'm not expecting change.



> Richard, remember SuperEdit? Very much about authoring.

I remember it well, as does John Balgenorth and perhaps some others here.

It was surprisingly polarizing: some loved it, some hated, but I never 
met anyone who'd used it who was indifferent about it.


I loved it. But I loved everything about the package at that time. 
Maybe I mostly loved the time. :)


--
 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: New(?) Idea for Standalones

[Roger Guay via use-livecode]

Hi James,

I downloaded MKVtoolsNix and it opens on the second right-click.

As for my wife’s admin privileges, I will have to check later

Thanks very much

Roger


> On Mar 29, 2021, at 4:43 PM, james--- via use-livecode 
>  wrote:
> 
> Hi Roger,
> 
> Below is a link to the download page for MkvToolnix, an app for 
> packaging/modifying mkv files. It is not notarised and requires the steps we 
> have been suggesting to open (after copying it to your local machine from the 
> distribution disk image.)
> 
> https://www.fosshub.com/MKVToolNix.html
> 
> Also, the message you say you get on your wife’s machine is unfamiliar to me 
> and so I was wondering if her account is an admin privileged account. I 
> assume most of us on the list run admin accounts (if on a Mac) as we assume 
> we are savvy enough not to get caught out by malicious apps. If that is the 
> case, does trying to open your stack when logged in via an admin privileged 
> account bring up a different error dlog?
> 
> James
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-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: New(?) Idea for Standalones

[Roger Guay via use-livecode]

Well, the thought plickins. I just also tried to open another standalone from 
Bob Earp and it failed to open. I am back to my usual state of befuddlement!

Roger


> On Mar 29, 2021, at 6:02 PM, Dev via use-livecode 
>  wrote:
> 
> No Roger, the folder has nothing to do with it. The two right click process 
> will work wherever you unzip the new arrival. 
> 
> Sent from my iPhone
> 
>> On Mar 29, 2021, at 5:54 PM, Roger Guay via use-livecode 
>>  wrote:
>> 
>> Thanks for your kind offer, Alex, but I think the process of opening an 
>> unblessed standalone for OS 11 has been solved. See my previous post in 
>> response to Scott. Turns out to be fairly simple . . . at least for this 
>> iteration of OS. In short, just right-click 2 times. It may also be 
>> important to do this from the Downloads folder. Not sure about that tho
>> 
>> Roger
>> 
>>> On Mar 29, 2021, at 3:29 PM, Alex Tweedly via use-livecode 
>>>  wrote:
>>> 
>>> 
 On 29/03/2021 22:11, Roger Guay via use-livecode wrote:
 Thanks, Alex. Unfortunately it comes up with the “No Entry” sign on this 
 machine.
 
 Roger
>>> 
>>> I'm not exactly sure what message this is, or when it happens. But this 
>>> sounds like "Fortunately, ..." because I think it means you have an app 
>>> that hits a brickwall of permission on your own machine - so we can look at 
>>> it in more detail without bothering your wife's many multiple windows.
>>> 
>>> It's hard to describe these things in words - hence my suggestion of a Zoom 
>>> call where you can screen-share and let others watch (and suggest) while 
>>> you try it. If you want to try that with just me, please do (I'm 
>>> unavailable for the next hour, but free from approx 00:30 - 01:30 UK time), 
>>> or tomorrow almost any time, given some notice).
>>> Or contact me off-list and we'll find a time.
>>> Or suggest a time and someone else might be able to join in and help.
>>> 
>>> There are lots of motivated people wanting to help - or to find out what 
>>> they're going to need to tell their own users when those users upgrade to a 
>>> later MacOS. :-)
>>> 
>>> Alex.
>>> 
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-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: Resources folder on mac, and the good old days

[Brian Milby via use-livecode]

Once I took a version of the LC IDE and edited one of the files in the package 
before opening it the first time.  It would not open and complained about being 
corrupt/modified/something (can’t recall exact message).

I trashed it and extracted a fresh copy.  I launched it once and then quit.  
Then I modified the file (actually a widget I believe).  LC opened fine this 
time.  So, at least a version or two ago (pre Catalina), the package contents 
were only verified as unchanged on first launch.

Sent from my iPad

> On Mar 29, 2021, at 6:22 PM, Neville Smythe via use-livecode 
>  wrote:
> 
> 
> 
>> On 30 Mar 2021, at 12:44 am, use-livecode-requ...@lists.runrev.com wrote:
>> 
>> Unfortunately this has never been true on macOS X.
>> 
>> The Resources folder (which is in the macOS app bundle) should be 
>> treated as read-only…
> 
> Mark Waddingham chides me for saying it is OK to write to the Resources 
> folder in the app bundle on a Mac. Mark is, as ever absolutely correct. The 
> correct place for application support files is the Library/Applications 
> Support folder, and this has been the AppleGuideline for a very long time 
> (although I am not quite so sure about that *always* being the case..) I was 
> wrong, naughty, and I promise… Mea culpa, mea maxima culpa. I strongly advise 
> against this awful filthy and degrading practice.
> 
> Except m’lud (he said in a very small voice), may I offer some admittedly 
> post-hoc and flimsy excuses.
> 
> 1. The app in which I do this originates from the days before the Application 
> Support folder existed (I am pretty sure) and has grown like Topsy ever 
> since. It worked then, it still works now. With one big caveat: this is ad 
> hoc software, distributed to a small group of users (Colin: by all the usual 
> methods - server, email, DropBox… they all work to deliver a working app 
> without my having to renew my lapsed Apple Developer registration.) If I were 
> to commercialise the app and so notarise it, I would expect writing to the 
> Resources folder *not* to work, probably notarising keeps a checksum of the 
> whole app bundle not just the executable. Maybe this distinction between ad 
> hoc and notarised software is part of the confusion of this very confused 
> thread, to which I have regrettably added more confusion.
> 
> 2. It is a great convenience to my Mac users to be able to move their copy of 
> the app to another machine, or give it to a friend, without having to worry 
> about finding and transferring auxiliary files (unlike my linux users, who I 
> must advise to keep everything together in one directory).
> 
> 3. There is no need for Installer code, or more problematic, and with a whiff 
> of sulphur to sensitive old-hand Mac user noses, an Uninstaller. Again if I 
> were to commercialise the app, these would come with the territory of license 
> files etc.
> 
> 4. If my user wants to get at the auxiliary files, it is easy enough to 
> explain the arcane process of opening up the Contents of the bundle. 
> Explaining how to access the Library is only slightly more arcane, but I 
> really don’t want the uninitiated venturing into that dark scary and very 
> dangerous place .
> 
> So, readers, don’t do it. But keep it to yourself if you do. And it probably 
> won’t work in MacOS 17.6.
> 
> Finally on the problem of opening unsafe/unnotarised apps in recent MacOS, I 
> am afraid the discussion here has clearly only increased the confusion of the 
> original forum user. Surely best to refer to the definitive source, the Apple 
> Support documents which you can get by googling “How to open an unsafe app in 
> Big Sur” (or Catalina, or Mojave). The instructions from Apple are clear and 
> straightforward, unlike some tech forums which start off by talking about 
> using the terminal to turn off Gatekeeper. 
> 
> Neville
> 
> 
> 
> ___
> use-livecode mailing list
> use-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: New(?) Idea for Standalones

[Dev via use-livecode]

No Roger, the folder has nothing to do with it. The two right click process 
will work wherever you unzip the new arrival. 

Sent from my iPhone

> On Mar 29, 2021, at 5:54 PM, Roger Guay via use-livecode 
>  wrote:
> 
> Thanks for your kind offer, Alex, but I think the process of opening an 
> unblessed standalone for OS 11 has been solved. See my previous post in 
> response to Scott. Turns out to be fairly simple . . . at least for this 
> iteration of OS. In short, just right-click 2 times. It may also be important 
> to do this from the Downloads folder. Not sure about that tho
> 
> Roger
> 
>> On Mar 29, 2021, at 3:29 PM, Alex Tweedly via use-livecode 
>>  wrote:
>> 
>> 
>>> On 29/03/2021 22:11, Roger Guay via use-livecode wrote:
>>> Thanks, Alex. Unfortunately it comes up with the “No Entry” sign on this 
>>> machine.
>>> 
>>> Roger
>> 
>> I'm not exactly sure what message this is, or when it happens. But this 
>> sounds like "Fortunately, ..." because I think it means you have an app that 
>> hits a brickwall of permission on your own machine - so we can look at it in 
>> more detail without bothering your wife's many multiple windows.
>> 
>> It's hard to describe these things in words - hence my suggestion of a Zoom 
>> call where you can screen-share and let others watch (and suggest) while you 
>> try it. If you want to try that with just me, please do (I'm unavailable for 
>> the next hour, but free from approx 00:30 - 01:30 UK time), or tomorrow 
>> almost any time, given some notice).
>> Or contact me off-list and we'll find a time.
>> Or suggest a time and someone else might be able to join in and help.
>> 
>> There are lots of motivated people wanting to help - or to find out what 
>> they're going to need to tell their own users when those users upgrade to a 
>> later MacOS. :-)
>> 
>> Alex.
>> 
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: New(?) Idea for Standalones

[Roger Guay via use-livecode]

Thanks for your kind offer, Alex, but I think the process of opening an 
unblessed standalone for OS 11 has been solved. See my previous post in 
response to Scott. Turns out to be fairly simple . . . at least for this 
iteration of OS. In short, just right-click 2 times. It may also be important 
to do this from the Downloads folder. Not sure about that tho

Roger

> On Mar 29, 2021, at 3:29 PM, Alex Tweedly via use-livecode 
>  wrote:
> 
> 
> On 29/03/2021 22:11, Roger Guay via use-livecode wrote:
>> Thanks, Alex. Unfortunately it comes up with the “No Entry” sign on this 
>> machine.
>> 
>> Roger
> 
> I'm not exactly sure what message this is, or when it happens. But this 
> sounds like "Fortunately, ..." because I think it means you have an app that 
> hits a brickwall of permission on your own machine - so we can look at it in 
> more detail without bothering your wife's many multiple windows.
> 
> It's hard to describe these things in words - hence my suggestion of a Zoom 
> call where you can screen-share and let others watch (and suggest) while you 
> try it. If you want to try that with just me, please do (I'm unavailable for 
> the next hour, but free from approx 00:30 - 01:30 UK time), or tomorrow 
> almost any time, given some notice).
> Or contact me off-list and we'll find a time.
> Or suggest a time and someone else might be able to join in and help.
> 
> There are lots of motivated people wanting to help - or to find out what 
> they're going to need to tell their own users when those users upgrade to a 
> later MacOS. :-)
> 
> Alex.
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

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

Re: mouseenter/mouseleave and pointer tool

[scott--- via use-livecode]

I DO remember SuperEdit.  So fast!  But it was a completely “dead” development 
environment. You had to leave it in order to get any messages, IIRC.
—
Scott


> On Mar 29, 2021, at 4:26 PM, Jim Lambert via use-livecode 
>  wrote:
> 
>> Paul wrote:
>> 
>> This is not a bug, but a feature. Our app contains a specialized network 
>> drawing tool and we switch to the pointer tool to allow the user to 
>> interact with drawn objects
> 
> I'd respectfully suggest that is a fringe use case when compared to authoring 
> in the LC IDE.
> Every time I click on a button in the IDE with the pointer tool in order to 
> select and, say, move it, I'd prefer if the mousedown/up scripts didn't fire 
> off because I'm editing the UI not running it. If I recall correctly this was 
> not how LC/Revolution originally behaved.
> 
> Richard, remember SuperEdit? Very much about authoring.
> 
> Jim Lambert
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-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: mouseenter/mouseleave and pointer tool

[Jim Lambert via use-livecode]

I wrote:
> Every time I click on a button in the IDE with the pointer tool in order to 
> select and, say, move it, I'd prefer if the mousedown/up scripts didn't fire 
> off because I'm editing the UI not running it. 
Nevermind. Those scripts are not firing when using the pointer tool.
I'm crazy!!!

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

Re: New(?) Idea for Standalones

[james--- via use-livecode]

Hi Roger,

Below is a link to the download page for MkvToolnix, an app for 
packaging/modifying mkv files. It is not notarised and requires the steps we 
have been suggesting to open (after copying it to your local machine from the 
distribution disk image.)

https://www.fosshub.com/MKVToolNix.html

Also, the message you say you get on your wife’s machine is unfamiliar to me 
and so I was wondering if her account is an admin privileged account. I assume 
most of us on the list run admin accounts (if on a Mac) as we assume we are 
savvy enough not to get caught out by malicious apps. If that is the case, does 
trying to open your stack when logged in via an admin privileged account bring 
up a different error dlog?

James

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

Re: How to get the path to the 'My Livecode' or the plugins folder?

[Mark Wieder via use-livecode]

On 3/29/21 4:06 PM, matthias rebbe via use-livecode wrote:

Dear all,

is there a way to get the path to the 'My Livecode' or the 'Plugins' folder?

Searched now for more than 40 minutes and did not find anything about it?

Is there maybe a hidden variable / property available for this?


Not well documented, but...

put revEnvironmentUserPluginsPath()

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

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

Re: How to get the path to the 'My Livecode' or the plugins folder?

[matthias rebbe via use-livecode]

Thanks Alex,

i will try that.
I still hope there is a property for this available. But for the meantime your 
suggestion will do i think.

Matthias
-
Matthias Rebbe
Life Is Too Short For Boring Code

> Am 30.03.2021 um 01:26 schrieb Alex Tweedly via use-livecode 
> :
> 
> Not pretty, but if you know you have a particular plugin installed, then you 
> can do
> 
> put the filename of stack "4wDevo" into tmp
> 
> and work from there; e.g. I get
> 
> /Users/alextweedly/Dropbox (Personal)/My Livecode/Plugins/4wDevo.livecode
> 
> Alex.
> 
> On 30/03/2021 00:06, matthias rebbe via use-livecode wrote:
>> Dear all,
>> 
>> is there a way to get the path to the 'My Livecode' or the 'Plugins' folder?
>> 
>> Searched now for more than 40 minutes and did not find anything about it?
>> 
>> Is there maybe a hidden variable / property available for this?
>> 
>> 
>> Regards
>> Matthias
>> 
>> 
>> 
>> -
>> Matthias Rebbe
>> Life Is Too Short For Boring Code
>> 
>> 
>> ___
>> use-livecode mailing list
>> use-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: mouseenter/mouseleave and pointer tool

[Jim Lambert via use-livecode]

> Paul wrote:
> 
> This is not a bug, but a feature. Our app contains a specialized network 
> drawing tool and we switch to the pointer tool to allow the user to 
> interact with drawn objects

I'd respectfully suggest that is a fringe use case when compared to authoring 
in the LC IDE.
Every time I click on a button in the IDE with the pointer tool in order to 
select and, say, move it, I'd prefer if the mousedown/up scripts didn't fire 
off because I'm editing the UI not running it. If I recall correctly this was 
not how LC/Revolution originally behaved.

Richard, remember SuperEdit? Very much about authoring.

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

Re: How to get the path to the 'My Livecode' or the plugins folder?

[Alex Tweedly via use-livecode]

Not pretty, but if you know you have a particular plugin installed, then 
you can do


put the filename of stack "4wDevo" into tmp

and work from there; e.g. I get

/Users/alextweedly/Dropbox (Personal)/My Livecode/Plugins/4wDevo.livecode

Alex.

On 30/03/2021 00:06, matthias rebbe via use-livecode wrote:

Dear all,

is there a way to get the path to the 'My Livecode' or the 'Plugins' folder?

Searched now for more than 40 minutes and did not find anything about it?

Is there maybe a hidden variable / property available for this?


Regards
Matthias



-
Matthias Rebbe
Life Is Too Short For Boring Code


___
use-livecode mailing list
use-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: New(?) Idea for Standalones

[Roger Guay via use-livecode]

Great Scott! (How often do you hear that?)

This works on second attempt but not the first. I verified this by trashing the 
first unzipped app and unzipping a second as you suggest. Here are the details:

On first right-click - Open, I got “"Testeroni” can’t be opened because Apple 
cannot check it for malicious software”. “This software needs to be updated. 
Contact the developer for more information.” Safari downloaded this file today 
at 3:54 PM from”& (you.com ) with 2 buttons: "Show in Finder" 
and “OK"

On second attempt, I got the same message with 3 buttons: “Open", "Show in 
Finder" and “Cancel” And “Open” works

Alleluia and Go figure!!

Thanks, Scott!

Roger

> On Mar 29, 2021, at 3:33 PM, scott--- via use-livecode 
>  wrote:
> 
> Hello Roger,
> 
> I made a standalone from an empty stack (and one button that does nothing.)  
> It is 64 bit Mac. It is zipped. It isn’t in a DMG or any sort of installer. 
> It is NOT code signed. I have been using this app to test how opening 
> non-signed Mac Apps work. After (finally) opening the app I can throw it away 
> and double click the zipped original to get another app that hasn’t been 
> approved  if I want to try the process again.
> 
> You can find this app here:
> 
> http://traditionaltaekwondo.org/test/Testeroni.app.zip
> 
> 
> --
> Scott Morrow
> 
> Elementary Software
> (Now with 20% less chalk dust!)
> web   https://elementarysoftware.com/
> email sc...@elementarysoftware.com
> booth1-360-734-4701
> mobile   360-920-0715
> --
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> use-livecode mailing list
> use-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

How to get the path to the 'My Livecode' or the plugins folder?

[matthias rebbe via use-livecode]

Dear all,

is there a way to get the path to the 'My Livecode' or the 'Plugins' folder?

Searched now for more than 40 minutes and did not find anything about it?

Is there maybe a hidden variable / property available for this?


Regards
Matthias



-
Matthias Rebbe
Life Is Too Short For Boring Code


___
use-livecode mailing list
use-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: New(?) Idea for Standalones

[scott--- via use-livecode]

That symbol probably means it was compiled to run on an older (Motorola ?) 
processor… similar to what happens if you have a 32 bit app on Big Sur.
—
Scott

> On Mar 29, 2021, at 3:29 PM, Alex Tweedly via use-livecode 
>  wrote:
> 
> 
> On 29/03/2021 22:11, Roger Guay via use-livecode wrote:
>> Thanks, Alex. Unfortunately it comes up with the “No Entry” sign on this 
>> machine.
>> 
>> Roger
> 
> I'm not exactly sure what message this is, or when it happens. But this 
> sounds like "Fortunately, ..." because I think it means you have an app that 
> hits a brickwall of permission on your own machine - so we can look at it in 
> more detail without bothering your wife's many multiple windows.
> 
> It's hard to describe these things in words - hence my suggestion of a Zoom 
> call where you can screen-share and let others watch (and suggest) while you 
> try it. If you want to try that with just me, please do (I'm unavailable for 
> the next hour, but free from approx 00:30 - 01:30 UK time), or tomorrow 
> almost any time, given some notice).
> Or contact me off-list and we'll find a time.
> Or suggest a time and someone else might be able to join in and help.
> 
> There are lots of motivated people wanting to help - or to find out what 
> they're going to need to tell their own users when those users upgrade to a 
> later MacOS. :-)
> 
> Alex.
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: New(?) Idea for Standalones

[scott--- via use-livecode]

Oops, meant to send that off-list.
—
Scott


> On Mar 29, 2021, at 3:33 PM, scott--- via use-livecode 
>  wrote:
> 
> Hello Roger,
> 
> I made a standalone from an empty stack (and one button that does nothing.)  
> It is 64 bit Mac. It is zipped. It isn’t in a DMG or any sort of installer. 
> It is NOT code signed. I have been using this app to test how opening 
> non-signed Mac Apps work. After (finally) opening the app I can throw it away 
> and double click the zipped original to get another app that hasn’t been 
> approved  if I want to try the process again.
> 
> You can find this app here:
> 
> http://traditionaltaekwondo.org/test/Testeroni.app.zip
> 
> 
> --
> Scott Morrow
> 
> Elementary Software
> (Now with 20% less chalk dust!)
> web   https://elementarysoftware.com/
> email sc...@elementarysoftware.com
> booth1-360-734-4701
> mobile   360-920-0715
> --
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> use-livecode mailing list
> use-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: New(?) Idea for Standalones

[scott--- via use-livecode]

Hello Roger,

I made a standalone from an empty stack (and one button that does nothing.)  It 
is 64 bit Mac. It is zipped. It isn’t in a DMG or any sort of installer. It is 
NOT code signed. I have been using this app to test how opening non-signed Mac 
Apps work. After (finally) opening the app I can throw it away and double click 
the zipped original to get another app that hasn’t been approved  if I want to 
try the process again.

You can find this app here:

http://traditionaltaekwondo.org/test/Testeroni.app.zip


--
Scott Morrow

Elementary Software
(Now with 20% less chalk dust!)
web   https://elementarysoftware.com/
email sc...@elementarysoftware.com
booth1-360-734-4701
mobile   360-920-0715
--








___
use-livecode mailing list
use-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: New(?) Idea for Standalones

[Alex Tweedly via use-livecode]

On 29/03/2021 22:11, Roger Guay via use-livecode wrote:

Thanks, Alex. Unfortunately it comes up with the “No Entry” sign on this 
machine.

Roger


I'm not exactly sure what message this is, or when it happens. But this 
sounds like "Fortunately, ..." because I think it means you have an app 
that hits a brickwall of permission on your own machine - so we can look 
at it in more detail without bothering your wife's many multiple windows.


It's hard to describe these things in words - hence my suggestion of a 
Zoom call where you can screen-share and let others watch (and suggest) 
while you try it. If you want to try that with just me, please do (I'm 
unavailable for the next hour, but free from approx 00:30 - 01:30 UK 
time), or tomorrow almost any time, given some notice).

Or contact me off-list and we'll find a time.
Or suggest a time and someone else might be able to join in and help.

There are lots of motivated people wanting to help - or to find out what 
they're going to need to tell their own users when those users upgrade 
to a later MacOS. :-)


Alex.


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

Re: Resources folder on mac, and the good old days

[Neville Smythe via use-livecode]

> On 30 Mar 2021, at 12:44 am, use-livecode-requ...@lists.runrev.com wrote:
> 
> Unfortunately this has never been true on macOS X.
> 
> The Resources folder (which is in the macOS app bundle) should be 
> treated as read-only…

Mark Waddingham chides me for saying it is OK to write to the Resources folder 
in the app bundle on a Mac. Mark is, as ever absolutely correct. The correct 
place for application support files is the Library/Applications Support folder, 
and this has been the AppleGuideline for a very long time (although I am not 
quite so sure about that *always* being the case..) I was wrong, naughty, and I 
promise… Mea culpa, mea maxima culpa. I strongly advise against this awful 
filthy and degrading practice.

Except m’lud (he said in a very small voice), may I offer some admittedly 
post-hoc and flimsy excuses.

1. The app in which I do this originates from the days before the Application 
Support folder existed (I am pretty sure) and has grown like Topsy ever since. 
It worked then, it still works now. With one big caveat: this is ad hoc 
software, distributed to a small group of users (Colin: by all the usual 
methods - server, email, DropBox… they all work to deliver a working app 
without my having to renew my lapsed Apple Developer registration.) If I were 
to commercialise the app and so notarise it, I would expect writing to the 
Resources folder *not* to work, probably notarising keeps a checksum of the 
whole app bundle not just the executable. Maybe this distinction between ad hoc 
and notarised software is part of the confusion of this very confused thread, 
to which I have regrettably added more confusion.

2. It is a great convenience to my Mac users to be able to move their copy of 
the app to another machine, or give it to a friend, without having to worry 
about finding and transferring auxiliary files (unlike my linux users, who I 
must advise to keep everything together in one directory).

3. There is no need for Installer code, or more problematic, and with a whiff 
of sulphur to sensitive old-hand Mac user noses, an Uninstaller. Again if I 
were to commercialise the app, these would come with the territory of license 
files etc.

4. If my user wants to get at the auxiliary files, it is easy enough to explain 
the arcane process of opening up the Contents of the bundle. Explaining how to 
access the Library is only slightly more arcane, but I really don’t want the 
uninitiated venturing into that dark scary and very dangerous place .

So, readers, don’t do it. But keep it to yourself if you do. And it probably 
won’t work in MacOS 17.6.

Finally on the problem of opening unsafe/unnotarised apps in recent MacOS, I am 
afraid the discussion here has clearly only increased the confusion of the 
original forum user. Surely best to refer to the definitive source, the Apple 
Support documents which you can get by googling “How to open an unsafe app in 
Big Sur” (or Catalina, or Mojave). The instructions from Apple are clear and 
straightforward, unlike some tech forums which start off by talking about using 
the terminal to turn off Gatekeeper. 

Neville



___
use-livecode mailing list
use-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: We don't need a Player (was Re: New(?) Idea for Standalones)

[Trevor DeVore via use-livecode]

On Mon, Mar 29, 2021 at 4:35 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:


> I think we're all on the same page here.
>

:thumbs_up

-- 
Trevor DeVore
ScreenSteps
www.screensteps.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: New(?) Idea for Standalones

[J. Landman Gay via use-livecode]

On 3/29/21 1:20 PM, Craig Newman via use-livecode wrote:

For about eight users in my business I distribute standalones for desktop only, 
both Mac and Windows versions. These are developed on a Mac. Simple to update 
and make, simple to give away, simple to use.

That is the aspect of this thread that I do not understand, perhaps misreading 
that it is somehow problematic to do what I do without issue. I am certain I 
simply have this wrong.


If your Mac users are on Big Sur they'll have the problem. If they're on Catalina they might 
have the problem. If they're on Mojave, not so much.


--
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: We don't need a Player (was Re: New(?) Idea for Standalones)

[Richard Gaskin via use-livecode]

Trevor DeVore wrote:

> We agree that LiveCode should include a sensible baseline for building
> a standalone. We also agree that they shouldn't try to write solutions
> for all possible ways that someone may need to distribute a
> standalone. My 2 cents is that LiveCode should provide a way for 3rd
> parties to expand on what happens when a standalone is being built.
> This is more than just turning off an option. Turning off an option
> would introduce an absence of behavior. I'm suggesting the addition of
> behavior that can occur during key points of the standalone building
> process.

Yeah, in my effort to try to minimize my TL/DRs I didn't include a 
detailed specification, using colloquialism where more precision may 
have been useful.


I'm assuming they'd do something similar to what we have now with the 
pre- and post-build messages.  When we consider those, the Plugins 
subsystem, pubsub, and the vast range of other IDE hooks, I feel pretty 
confident that they wouldn't suddenly change direction and make a 
locked-down hookless solution on this one.



> Perhaps all use cases can adequately be handled with the messages that
> are already sent once when a standalone builder finishes (e.g.
> savingStandalone and standaloneSaved).
>
> But, perhaps the standalone building process would be better served
> with additional, more granular callbacks, and maybe those callbacks
> are sent to a target other than the stack being saved. That is what
> I would like to be considered when modernizing the Standalone Builder.

Like that.


I think we're all on the same page here.

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Re: Help with androidStartAudioPlayingInBackground()

[Derek Bump via use-livecode]

That did the trick, thank you.

On 3/28/21 2:08 PM, J. Landman Gay via use-livecode wrote:
I've seen similar issues when trying to read other file types from the 
resources folder in an Android standalone. Try copying the file to 
specialFolderPath("documents") and play it from there. It's likely a 
permissions problem that I wish didn't exist.


On 3/28/21 1:24 PM, Derek Bump via use-livecode wrote:

Hello Everyone,

I was wondering if anyone has insight into the usage of 
"androidStartAudioPlayingInBackground()", or can confirm that it works?


I setup a test stack that attempts to play a public domain MP3 using 
the following script but nothing plays. I receive nothing from the 
function, and I'm getting the following in logcat: LiveCode: JNI 
exception thrown when calling native method


on mouseUp
    local tFile
    put specialFolderPath("engine") & "/" & "spring_song.mp3" into tFile
    if there is not a file tFile then
   answer "File not found:" && tFile
    end if
    put androidStartAudioPlayingInBackground(tFile) into card field 
"result"

    -- logcat: LiveCode: JNI exception thrown when calling native method
end mouseUp

I've tested this build using Community 9.6.2 (rc3) and 9.0.5, on an 
Android 9.0 Virtual Device and a Android 9.0 phone. Same result 
across the board, nothing plays.


I did test and confirm the ability to play the audio file with 
"mobilePlaySoundOnChannel", but I need background playback for my 
project to work. Also, I searched the LiveCode Quality Control site 
for existing bugs (no results) and searched the forum a bit.


Does anyone have any ideas? Here is my test stack if you're willing 
to give it a shot on your end: 
https://www.speedbump.io/shared/backgroundPlayTest.minimal.zip


Thank you in advance,

Derek Bump

___
use-livecode mailing list
use-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: We don't need a Player (was Re: New(?) Idea for Standalones)

[Trevor DeVore via use-livecode]

On Mon, Mar 29, 2021 at 3:56 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> Here's the bottom of the post you were replying to:
>
>   One suitable solution in the box is all that's needed,
>   with the option for folks to turn it off if they prefer
>   using any other of the infinite variety of all possible
>   solutions.
>
>
> So yeah, I don't much mind whether we call them "hooks" or "options" or
> even "doilies" as long as it supports the core need right out of the
> box, without penalizing deeply-experienced professionals with specific
> tool preferences.
>

We agree that LiveCode should include a sensible baseline for building a
standalone. We also agree that they shouldn't try to write solutions for
all possible ways that someone may need to distribute a standalone. My 2
cents is that LiveCode should provide a way for 3rd parties to expand on
what happens when a standalone is being built. This is more than just
turning off an option. Turning off an option would introduce an absence of
behavior. I'm suggesting the addition of behavior that can occur during key
points of the standalone building process.

Perhaps all use cases can adequately be handled with the messages that are
already sent once when a standalone builder finishes (e.g. savingStandalone
and standaloneSaved).

But, perhaps the standalone building process would be better served with
additional, more granular callbacks, and maybe those callbacks are sent to
a target other than the stack being saved. That is what I would like to be
considered when modernizing the Standalone Builder.

-- 
Trevor DeVore
ScreenSteps
www.screensteps.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: New(?) Idea for Standalones

[Roger Guay via use-livecode]

Thanks, Alex. Unfortunately it comes up with the “No Entry” sign on this 
machine.

Roger

> On Mar 29, 2021, at 1:36 PM, Alex Tweedly via use-livecode 
>  wrote:
> 
> 
> On 29/03/2021 21:23, Roger Guay via use-livecode wrote:
>> I have to admit I haven’t had a lot of time to experiment yet on my wife’s 
>> computer as I've been busy here trying to communicate my problem. Also, my 
>> wife’s computer is busy helping her work from home, not to mention, her 
>> style is to have numerous windows open all the time. Drives me nuts!
>> 
>> I wish I could think of an unapproved Mac app I could download to my own 
>> machine to play with.
> 
> https://www.sonsothunder.com/devres/livecode/downloads/StackRunner.htm 
>  and 
> download something suitable.
> 
> This  is the old (and I think no longer functioning) stackRunner - but 
> although it doesn't appear to work properly (it is *very* old) it did come up 
> and ask me to approve it.

___
use-livecode mailing list
use-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: We don't need a Player (was Re: New(?) Idea for Standalones)

[Richard Gaskin via use-livecode]

Trevor DeVore wrote:

> On Mon, Mar 29, 2021 at 1:24 PM Richard Gaskin wrote:
>
>> Trevor DeVore wrote:
>>
>>  > On Mon, Mar 29, 2021 at 12:31 PM Richard Gaskin wrote:
>>  >> Add-ons to the product experience can be a useful temporary
>>  >> workaround for long-time users, but if we step back and look
>>  >> at the gestalt of the user experience they're not a true
>>  >> solution.
>>  >>
>>  >
>>  > Do you think that LiveCode should have built in support for all of
>>  > the various installers such as DropDMG, InnoSetup, WIX, etc.?
>>
>> "All" is the biggest possible number, potentially infinite.  So
>> logically, of course the only answer is "no".
>
> And that is why I like hooks into the standalone building process :-)
>
> Provide the baseline solution but make it extensible so that
> developers who need more can integrate whatever they need into
> building a standalone. The less manual steps the better.

#GMTA

Here's the bottom of the post you were replying to:

 One suitable solution in the box is all that's needed,
 with the option for folks to turn it off if they prefer
 using any other of the infinite variety of all possible
 solutions.


So yeah, I don't much mind whether we call them "hooks" or "options" or 
even "doilies" as long as it supports the core need right out of the 
box, without penalizing deeply-experienced professionals with specific 
tool preferences.


--
 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: New(?) Idea for Standalones

[Alex Tweedly via use-livecode]

On 29/03/2021 20:54, Paul Dupuis via use-livecode wrote:

On 3/29/2021 3:36 PM, Alex Tweedly via use-livecode wrote:
there is some way to allow unsigned apps to run on all current and 
foreseeable versions of the desktop OSes


I think your assumption that you will be able - even via some horribly 
convoluted series of steps - to run unsigned and unnotarized apps on 
FUTURE versions of macOS is probably in error. From Apple's actions 
and statements, they very much are moving to a similar sandboxed, 
highly vetted, approved by Apple model for macOS as exists for iOS apps.


It's only an assumption for "the foreseeable versions". I do agree with 
you that in the long term this will, or might, become either impossible 
or so burdensome it's not worth it.


But at that point, we don't know what will be possible.  MacOS may by 
then be so tied up that it has become equivalent to iOS. The 
disappointing part of this thread, for me, was how quickly those in the 
know convinced me there was no chance of a 'runner' app for mobile (in 
particular, iOS). I think by the time it becomes infeasible to 
circumvent the protections on MacOS, it will also be infeasible to 
produce a signed 'general runner' app for it.


Alex.


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

Re: New(?) Idea for Standalones

[Alex Tweedly via use-livecode]

On 29/03/2021 21:23, Roger Guay via use-livecode wrote:

I have to admit I haven’t had a lot of time to experiment yet on my wife’s 
computer as I've been busy here trying to communicate my problem. Also, my 
wife’s computer is busy helping her work from home, not to mention, her style 
is to have numerous windows open all the time. Drives me nuts!

I wish I could think of an unapproved Mac app I could download to my own 
machine to play with.


https://www.sonsothunder.com/devres/livecode/downloads/StackRunner.htm 
and download something suitable.


This  is the old (and I think no longer functioning) stackRunner - but 
although it doesn't appear to work properly (it is *very* old) it did 
come up and ask me to approve it.


Alex.


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

Re: New(?) Idea for Standalones

[Roger Guay via use-livecode]

I have to admit I haven’t had a lot of time to experiment yet on my wife’s 
computer as I've been busy here trying to communicate my problem. Also, my 
wife’s computer is busy helping her work from home, not to mention, her style 
is to have numerous windows open all the time. Drives me nuts!

I wish I could think of an unapproved Mac app I could download to my own 
machine to play with.

:-)

Roger



> On Mar 29, 2021, at 1:00 PM, Alex Tweedly via use-livecode 
>  wrote:
> 
> Roger,
> 
> this is frustrating, isn't it !!
> 
> If I were you, I'd send an email to the list saying (something along the 
> lines of )
> 
>> I want to get to the bottom of this. I'm going to host a Zoom call on my 
>> wife's Mac at  where I will share my screen so 
>> you can all see what I'm doing, and I'll then accept suggestions of what to 
>> do/try.  Here's the key/invite ...
>> All welcome !!
>> 
> I'll do my best to attend - but since I don't own a Mac that can run anything 
> later than 10.13 I suspect I'll be a spectator, not a contributor.
> 
> Alex.

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

Re: New(?) Idea for Standalones

[Roger Guay via use-livecode]

I’m sure you’re right about this. And, If this be the case, I would ask for the 
work-around approach . . . a LiveCodeLight App downloadable from RunRev (or 
other approved source) that runs stacks but hides or strips the IDE.


Roger

> On Mar 29, 2021, at 12:54 PM, Paul Dupuis via use-livecode 
>  wrote:
> 
> I think your assumption that you will be able - even via some horribly 
> convoluted series of steps - to run unsigned and unnotarized apps on FUTURE 
> versions of macOS is probably in error. From Apple's actions and statements, 
> they very much are moving to a similar sandboxed, highly vetted, approved by 
> Apple model for macOS as exists for iOS apps.

___
use-livecode mailing list
use-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: New(?) Idea for Standalones

[Alex Tweedly via use-livecode]

Roger,

this is frustrating, isn't it !!

If I were you, I'd send an email to the list saying (something along the 
lines of )


I want to get to the bottom of this. I'm going to host a Zoom call on 
my wife's Mac at  where I will share my 
screen so you can all see what I'm doing, and I'll then accept 
suggestions of what to do/try.  Here's the key/invite ...

All welcome !!

I'll do my best to attend - but since I don't own a Mac that can run 
anything later than 10.13 I suspect I'll be a spectator, not a contributor.


Alex.

On 29/03/2021 20:43, Roger Guay via use-livecode wrote:

Craig.

You and I are very much in the same boat as far as how we use LiveCode.

The problem is not constructing the standalones. LiveCode is superb in this regard. 
The problem is distributing Apple unapproved standalones. It seems I can no longer 
do that anymore as I used to. The problem is that opening an unapproved standalone 
on an other computer other than one’s own is difficult if not impossible for OS 
11.2. Other’s in this thread have offered that it still can be done albeit with a 
more convoluted process, and I am still trying to figure this out. e.g if I send a 
standalone to my wife (called StackOmatic) to share, we inevitably end up with the  
"You do not have permission to open the application “StackOmatic”. “Contact 
your computer or network administrator for assistance” with a simple “OK” button. I 
can’t seem to replicate the process that others have suggested to get to the “Open 
Anyway” button.

Roger


On Mar 29, 2021, at 11:20 AM, Craig Newman via use-livecode 
 wrote:

For about eight users in my business I distribute standalones for desktop only, 
both Mac and Windows versions. These are developed on a Mac. Simple to update 
and make, simple to give away, simple to use.

That is the aspect of this thread that I do not understand, perhaps misreading 
that it is somehow problematic to do what I do without issue. I am certain I 
simply have this wrong.

I do all this in the Community version. I do not sell apps at all, though I own 
an Indy license just as a way to help LC a little. So I wonder if I am a 
scofflaw. If everyone was on a Mac, I might have simply distributed updated 
stacks, and have LC resident on all the other machines. But of course, the fact 
that most use Windows makes that impossible, and I will not use a Windows 
machine unless I have to. Anyway, leaving the IDE open is risky.

___
use-livecode mailing list
use-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: New(?) Idea for Standalones

[Paul Dupuis via use-livecode]

On 3/29/2021 3:36 PM, Alex Tweedly via use-livecode wrote:
there is some way to allow unsigned apps to run on all current and 
foreseeable versions of the desktop OSes


I think your assumption that you will be able - even via some horribly 
convoluted series of steps - to run unsigned and unnotarized apps on 
FUTURE versions of macOS is probably in error. From Apple's actions and 
statements, they very much are moving to a similar sandboxed, highly 
vetted, approved by Apple model for macOS as exists for iOS apps.


___
use-livecode mailing list
use-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: New(?) Idea for Standalones

[Roger Guay via use-livecode]

Craig.

You and I are very much in the same boat as far as how we use LiveCode.

The problem is not constructing the standalones. LiveCode is superb in this 
regard. The problem is distributing Apple unapproved standalones. It seems I 
can no longer do that anymore as I used to. The problem is that opening an 
unapproved standalone on an other computer other than one’s own is difficult if 
not impossible for OS 11.2. Other’s in this thread have offered that it still 
can be done albeit with a more convoluted process, and I am still trying to 
figure this out. e.g if I send a standalone to my wife (called StackOmatic) to 
share, we inevitably end up with the  "You do not have permission to open the 
application “StackOmatic”. “Contact your computer or network administrator for 
assistance” with a simple “OK” button. I can’t seem to replicate the process 
that others have suggested to get to the “Open Anyway” button.

Roger

> On Mar 29, 2021, at 11:20 AM, Craig Newman via use-livecode 
>  wrote:
> 
> For about eight users in my business I distribute standalones for desktop 
> only, both Mac and Windows versions. These are developed on a Mac. Simple to 
> update and make, simple to give away, simple to use.
> 
> That is the aspect of this thread that I do not understand, perhaps 
> misreading that it is somehow problematic to do what I do without issue. I am 
> certain I simply have this wrong.
> 
> I do all this in the Community version. I do not sell apps at all, though I 
> own an Indy license just as a way to help LC a little. So I wonder if I am a 
> scofflaw. If everyone was on a Mac, I might have simply distributed updated 
> stacks, and have LC resident on all the other machines. But of course, the 
> fact that most use Windows makes that impossible, and I will not use a 
> Windows machine unless I have to. Anyway, leaving the IDE open is risky.

___
use-livecode mailing list
use-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: New(?) Idea for Standalones

[Alex Tweedly via use-livecode]

On 29/03/2021 19:20, Craig Newman via use-livecode wrote:

Roger.

For about eight users in my business I distribute standalones for desktop only, 
both Mac and Windows versions. These are developed on a Mac. Simple to update 
and make, simple to give away, simple to use.

That is the aspect of this thread that I do not understand, perhaps misreading 
that it is somehow problematic to do what I do without issue. I am certain I 
simply have this wrong.


Craig,

I think this all depends on your users, and which version(s) of 
MacOS/Windows they are using.


Both OSes require *either* signed apps, or that the user give permission 
to run unsigned apps (either doing that for each app, or once in the 
system settings). In the more recent versions (certainly of MacOS), the 
steps needed to do this have become increasingly well hidden, and the 
warning messages have become increasingly scary.


If you (i.e. your users) have been used to seeing these, and taking the 
steps around the hurdles, they probably do so naturally and without 
worrying (or, they've already down-tuned the protection in the settings 
and so no longer see any warnings for new apps).


In my case, the Macs I own are, like me, elderly, and hence restricted 
to MacOS 10.13 or older - and I barely notice; occasionally I have to 
right-click on an app and agree to it running. From Roger's description, 
this is much more intrusive in newer MacOS, and finding your way to the 
correct place to give that permission is non-trivial.


However, there is no doubt that there is some way to allow unsigned apps 
to run on all current and foreseeable versions of the desktop OSes, so 
if you have a fairly restricted audience, you can simply ignore the 
problems addressed in this thread and focus on getting the permissions 
properly changed for them.


Alex.



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

Re: mouseenter/mouseleave and pointer tool

[Paul Dupuis via use-livecode]

This is not a bug, but a feature. Our app contains a specialized network 
drawing tool and we switch to the pointer tool to allow the user to 
interact with drawn objects (buttons and line graphics connecting the 
buttons). We use mouseEnter and mouseLeave to update information about 
the object the person is hovering over as they are in drawing mode. The 
POINTER tool is used to mouse over and select objects in the drawing 
window.


On 3/29/2021 2:07 PM, Klaus major-k via use-livecode wrote:

Hi all,


Klaus wrote:
when the pointer tool is active, "mouseenter" and "mouseleave"
handlers are executed nevertheless!?

I don't this this is correct behaviour!

reported: 


Best

Klaus

--
Klaus Major
https://www.major-k.de
https://www.major-k.de/bass
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

Re: We don't need a Player (was Re: New(?) Idea for Standalones)

[Trevor DeVore via use-livecode]

On Mon, Mar 29, 2021 at 1:24 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Trevor DeVore wrote:
>
>  > On Mon, Mar 29, 2021 at 12:31 PM Richard Gaskin wrote:
>  >> Add-ons to the product experience can be a useful temporary
>  >> workaround for long-time users, but if we step back and look
>  >> at the gestalt of the user experience they're not a true solution.
>  >>
>  >
>  > Do you think that LiveCode should have built in support for all of
>  > the various installers such as DropDMG, InnoSetup, WIX, etc.?
>
> "All" is the biggest possible number, potentially infinite.  So
> logically, of course the only answer is "no".
>

And that is why I like hooks into the standalone building process :-)

Provide the baseline solution but make it extensible so that developers who
need more can integrate whatever they need into building a standalone. The
less manual steps the better.

-- 
Trevor DeVore
ScreenSteps
www.screensteps.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: mouseenter/mouseleave and pointer tool

[Richard Gaskin via use-livecode]

Jim Lambert wrote:

>> Klaus wrote:
>> when the pointer tool is active, "mouseenter" and "mouseleave"
>> handlers are executed nevertheless!?
>>
>> I don't this this is correct behaviour!
>
> I agree.
> When the pointer tool is selected in the IDE one is supposedly in
> Editing Mode.

This is a philosophical point in LC, created by a change in how tool 
modes are presented.


Throughout all of xTalk history, and the history of the LC engine prior 
to its acquisition in 2003, tool modes have always been presented as 
options available to scripters like any other part of the language, 
changeable with the "choose" command.


Most xTalk IDEs have lacked the confidence in their language to also 
build their IDE in their own language, so this was less of an issue for 
HC, OMO, Plus, and others.


But MetaCard, SuperCard, Gain Momentum provided runtime editing of the 
sort we have with LiveCode.  While each had subtly different ways of 
guiding the user to appreciate the differences in tool modes, their 
audiences had less confusion, because they presented tool modes as tool 
modes (language elements like any other available for us all to use), 
rather than attempting to present a more consumer-app experience in 
which the pointer tool is somehow not something a scripter could be 
expected to ever want to use.


LC documents the "choose" command, but is designed in a way that 
attempts to be both an xTalk dev environment and a consumer app, 
resulting in an experience that lends many users to think of the pointer 
tool as somehow not available among the "choose" options.




One of the most powerful moments of my scripting life was when I 
launched SuperCard and was invited to explore one of the sample apps 
that came with it, SampleDraw.  It was basically MacDraw, a decent 
drawing app with vector graphics, document handling, and all that, but 
SampleDraw even more capable, with features like polygon morphing, and 
the whole thing written in xTalk.


That moment of seeing an app I'd known well reimplemented more 
powerfully in a scripting language I enjoyed is what compelled me to 
spend so many years enjoying xTalks.


--
 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: We don't need a Player (was Re: New(?) Idea for Standalones)

[Richard Gaskin via use-livecode]

Trevor DeVore wrote:

> On Mon, Mar 29, 2021 at 12:31 PM Richard Gaskin wrote:
>> Add-ons to the product experience can be a useful temporary
>> workaround for long-time users, but if we step back and look
>> at the gestalt of the user experience they're not a true solution.
>>
>
> Do you think that LiveCode should have built in support for all of
> the various installers such as DropDMG, InnoSetup, WIX, etc.?

"All" is the biggest possible number, potentially infinite.  So 
logically, of course the only answer is "no".


DMGs are native to the OS, as is the AppleScript used to automate making 
them look attractive.


LC has a reasonably nice Windows installer framework, which we all use 
every time we install LC.


I don't think anyone here is expecting LC or any other tool vendor to 
provide all possible solutions to a given problem.


One suitable solution in the box is all that's needed, with the option 
for folks to turn it off if they prefer using any other of the infinite 
variety of all possible solutions.


--
 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: New(?) Idea for Standalones

[Craig Newman via use-livecode]

Roger.

For about eight users in my business I distribute standalones for desktop only, 
both Mac and Windows versions. These are developed on a Mac. Simple to update 
and make, simple to give away, simple to use.

That is the aspect of this thread that I do not understand, perhaps misreading 
that it is somehow problematic to do what I do without issue. I am certain I 
simply have this wrong.

I do all this in the Community version. I do not sell apps at all, though I own 
an Indy license just as a way to help LC a little. So I wonder if I am a 
scofflaw. If everyone was on a Mac, I might have simply distributed updated 
stacks, and have LC resident on all the other machines. But of course, the fact 
that most use Windows makes that impossible, and I will not use a Windows 
machine unless I have to. Anyway, leaving the IDE open is risky.

Someone not too long ago wondered why we could not give standalones to friends 
for use on their phones, that is, what difference does the platform make, if it 
is only for acquaintances. In mobile, I certainly see how this might be abused.

Craig

> On Mar 29, 2021, at 9:45 AM, Craig Newman  wrote:
> 
> I have been following this thread with interest, and have no idea what anyone 
> is talking about.
> 
> I make and update standalones regularly on my Mac, and distribute them to 
> many Windows and Mac desktop users in my company. All for “personal’ use.
> 
> Somewhere in the middle of all this, I thought that the issue was 
> distributing to mobile, and saw the problem, but then noticed that the issue 
> was distributing to desktop, and became confused
> 
> So though I may be breaking the law, what prevents anyone from doing what i 
> do?
> 
> What am i missing?
> 
> Craig
> 
>> On Mar 29, 2021, at 1:17 AM, John Balgenorth via use-livecode 
>>  wrote:
>> 
>> Thanks for clarifying that for me!
>> 
>> As far as the license stuff goes on the community version I personally
>> think the community is allowed to supersede LiveCode if they feel like
>> investing the time.  It should not be able to be held back just to make
>> sure all of the new features are done by the LiveCode Team. As long
>> as it is kept public like the community version was designed to do.
>> 
>> JB
>> 
>>> On Mar 28, 2021, at 10:04 PM, Roger Guay via use-livecode 
>>>  wrote:
>>> 
>>> John et al,
>>> 
>>> To recap: 
>>> 
>>> My ultimate goal is to get support for RunRev to provide a LiveCodeLight 
>>> download that opens stacks but hides or strips the IDE. I can’t believe 
>>> this would be difficult in any way.
>>> 
>>> In the meantime, I am trying to recreate the old Standalone app method (See 
>>> Jacquelines’ post in this thread) that opens stacks. 2 or more OSs ago this 
>>> was extremely easy to do, but because of the increasing complexity of Apple 
>>> requirements (and Windows?) it is now quite difficult and I have yet to 
>>> succeed at it. Even if it is still possible, I shudder to think what they 
>>> will do next to further complicate our efforts to simple collaborate and 
>>> share with family and friends.
>>> 
>>> Thanks to all who are taking an interest.
>>> 
>>> Roger
>>> 
>>> 
>>> 
 On Mar 28, 2021, at 9:14 PM, John Balgenorth via use-livecode 
  wrote:
 
 I was thinking one of the reasons people were saying not to provide a
 scaled down version of the development system to do it was because
 they were afraid it would interfere with the license. But since you can
 do it according to some of you is proof you are allowed to automate
 the process and that should not interfere with the user license.
 
 JB
 
>> On Mar 28, 2021, at 9:04 PM, Dev via use-livecode 
>>  wrote:
> 
> If it works, the upside is that anyone can do it themselves and coach 
> their family into doing the two step process once on the first time 
> install.
> 
> If it doesn’t work, we need to get a real developer to make a real app 
> that jumps through Apple’s hoops. And then the developer has to keep it 
> updated every time Apple makes a change. 
> 
> I agree this whole thing is a bother, but as other posts have pointed 
> out, “This is not the good old days and security is not going away” so 
> this whole discussion is trying to find the narrowest point to cross. If 
> the amateurs can do it themselves with a two step magic incantation, then 
> this puts the ball back in their court and allows them into the game with 
> out going through the Apple doorway.
> 
> Kelly
> 
>> On 28 Mar, 2021, at 9:54 PM, John Balgenorth via use-livecode 
>>  wrote:
>> 
>> I may have got lost on this subject but if his goal was to make it
>> easy for people to open his app by doing something like using a
>> scaled down version of the development system then this one
>> step of doing it twice is a valid reason for using what he wanted
>> because people do not want to be bothered with 

Re: mouseenter/mouseleave and pointer tool

[Klaus major-k via use-livecode]

Hi all,

> Klaus wrote:
> when the pointer tool is active, "mouseenter" and "mouseleave"
> handlers are executed nevertheless!? 
> 
> I don't this this is correct behaviour!

reported: 


Best

Klaus

--
Klaus Major
https://www.major-k.de
https://www.major-k.de/bass
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

Re: mouseenter/mouseleave and pointer tool

[Jim Lambert via use-livecode]

> Klaus wrote:
> when the pointer tool is active, "mouseenter" and "mouseleave"
> handlers are executed nevertheless!? 
> 
> I don't this this is correct behaviour!

I agree.
When the pointer tool is selected in the IDE one is supposedly in Editing Mode.
To have code execute when you simply enter or select an object you wish to edit 
is counter to the nature of editing, not helpful and, well, plain wrong.

Of course, it's been this way for a long and annoying while. Special case 
drawing apps not withstanding.

Jim Lambert



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

Re: New(?) Idea for Standalones

[Richard Gaskin via use-livecode]

matthias_livecode_150811 wrote:

> Don't blame Microsoft and Apple

I'm not sure anyone here is. Jumping through hoops is painful, of 
course, but I think the folks here recognize that having their data and 
devices compromised is even more painful.




> And purchasing a code signing certificate for Windows here in Germany
> was  also not very easy years ago, especially for independent
> developers.
> It was not just purchasing it in an online store. After purchase i had
> to proof my identity through a notary agency. Comodo contacted my
> lawyer/notary and asked for a confirmation that i am a real person.
> Therefor i had to visit the notary office, show my papers to get
> authenticated.  So i had not only pay for the certificate, but also
> for the authentication through the lawyer/notary.
> Thanks god, now Comodo is using public business registers for
> confirmation and luckily i am listed in one of them now. So the
> authenticaton process is much faster and without any additonal costs.

That's a valuable story.  It's good to see security taken seriously, and 
even better to see where the process is tailored over time as the 
balance between threats and remedies becomes ever more finely tuned to 
shift the burden to larger stakeholders with the resources to handle it 
well.



Once upon a time SSL certs were expensive and cumbersome to obtain.  Now 
we have projects like Let's Encrypt, which provide strong SSL certs 
automatically updated not just annually but every 90 days, for free.


The change was moving the burden from individual web site owners to 
bigger players who are also stakeholders, ISPs and ad-supported industry 
giants who need a safe web to thrive.  They have vast resources beyond 
what indies have to put on the problem, and centralized solutions can be 
handled by experts with good implementations and fewer errors.


I expect over time we'll see initiatives in the app space evolve this 
way as well, with OS vendors and other bigger stakeholders actively 
investing in ways to make it ever easier for indy devs to deploy safe 
software.


In a smaller but no less helpful way, Mark Waddingham's comment 
demonstrates the value of centralizing security process where practical:


   ...this is probably best done by improving the standalone
   building process (i.e. making it as easy as possible)
   rather than anything else.



> As a customer btw i really prefer secure software. I know that even
> with those security achievements software is not 100% secure, but more
> secure than without any notarization/code signing.

The listing of Common Vulnerabilities and Exposures (CVEs) at 
CVEDetails.com is a good reminder of growth in both scope and 
sophistication of attacks:


https://www.cvedetails.com/product/156/Apple-Mac-Os-X.html?vendor_id=49

At first glance, one might see futility in the steady increase of CVEs 
against macOS growing nearly every year while Apple has made deployment 
ever more cumbersome.


But a brief pause to think about it reveals the deeper truth: imagine 
how many vulnerabilities would be exploited if OS vendors weren't adding 
hoops for deployment to jump through.


--
 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: We don't need a Player (was Re: New(?) Idea for Standalones)

[Trevor DeVore via use-livecode]

On Mon, Mar 29, 2021 at 12:31 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Trevor DeVore wrote:
>
>  > On Mon, Mar 29, 2021 at 10:57 AM Richard Gaskin wrote:
>  >
>  >> TL/DR:
>  >>
>  >> We don't need a generic player.
>  >>
>  >> What we need is an updated Standalone Builder, to provide
>  >> more complete tooling and better guidance for building a
>  >> modern standalone.
>  >
>  >
>  > An easy way to extend the standalone building process with plugins is
>  > a necessity IMO as well.
>
> Add-ons to the product experience can be a useful temporary workaround
> for long-time users, but if we step back and look at the gestalt of the
> user experience they're not a true solution.
>

Do you think that LiveCode should have built in support for all of the
various installers such as DropDMG, InnoSetup, WIX, etc.? You either have
to support all of them or provide a hook so the developer can extend the
process. Either that or require the developer to create their own
additional workflow for processing the standalone after the fact.

-- 
Trevor DeVore
ScreenSteps
www.screensteps.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: New(?) Idea for Standalones

[John Balgenorth via use-livecode]

They will probably never take the time to be bothered with complaining
by not buying from Apple or Microsoft.  It would be easier for them to
not buy electricity from the power companies and that won’t happen
either.

JB

> On Mar 29, 2021, at 10:51 AM, Paul Dupuis via use-livecode 
>  wrote:
> 
> On 3/29/2021 12:28 PM, Roger Guay via use-livecode wrote:
>> In any case it is not as easy as it use to be and IMO, this door may be 
>> closing.
> You are 100% right. The door is closing and will eventually be closed unless 
> enough consumers of Apple (and Windows) products complain with their buying 
> power to Apple and Microsoft.
> 
> 
> ___
> use-livecode mailing list
> use-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: We don't need a Player (was Re: New(?) Idea for Standalones)

[Richard Gaskin via use-livecode]

Trevor DeVore wrote:

> On Mon, Mar 29, 2021 at 10:57 AM Richard Gaskin wrote:
>
>> TL/DR:
>>
>> We don't need a generic player.
>>
>> What we need is an updated Standalone Builder, to provide
>> more complete tooling and better guidance for building a
>> modern standalone.
>
>
> An easy way to extend the standalone building process with plugins is
> a necessity IMO as well.

Add-ons to the product experience can be a useful temporary workaround 
for long-time users, but if we step back and look at the gestalt of the 
user experience they're not a true solution:



The problem is tooling and knowledge necessary but not found in the product.

Whether the third-parties delivering essential tools are OS vendors or 
community members, both require knowing where to hunt down the solution, 
set it up, and use it.


Either way it's not in the box, so many won't know where to find it, and 
most newcomers won't know it even exists.



Third-party plugins are ABSOLUTELY FANTASTIC for adding *supplemental 
capabilities and conveniences* to a product.


But they cannot be profitably relied on to provide a core requirement of 
a product's critical path of use.


When the product is a tool for building applications, nothing could be 
more integral to its mission than building standalones.


--
 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: mobileStoreMakePurchase not working for iOS

[Andrew at MidWest Coast Media via use-livecode]

I see now that it was stated on 7/16/2014 that this might not work in the 
Simulator, that was my misunderstanding.

My app is able to make the request as I can get “sendingRequest” as the pState, 
but then errors out with the “An unknown error occurred” for the “error” 
pState. This happens on test device with development credentials as well as 
distribution credentials; it’s live now. Everything I’ve read about using 
sandbox users to test IAP has been an absolute nightmare, so after no luck in 
the simulator or on my tethered iPhone I just bit the bullet and tried the 
transaction myself (it was only 99¢). The iOS side just throws a generic error 
back at me but on Google Play the transaction goes through and the purchase is 
successful. 

This seems to happen when the StoreKit returns SKErrorCode=0 and seems to be 
more problematic with Xcode 12+ & iOS 12+.
Is there any way to see the full error message returned from Apple to find out 
where this is failing? 
Doesn’t seem like there is a mobileStorePurchaseError(pPurchaseID,”verbose”) 
mode but the LC dictionary isn’t very resource heavy for mobile purchases.

—Andrew Bell


> Date: Mon, 29 Mar 2021 17:59:42 +0300
> From: panagiotis merakos 
> Subject: Re: mobileStoreMakePurchase not working for iOS
> Message-ID:
>   
> Content-Type: text/plain; charset="UTF-8"
> 
> Hello Andrew,
> 
> Just to mention that in-app purchases are not supported in the Simulator.
> 
> Kind regards,
> Panos
> --
> 
> On Fri, 26 Mar 2021 at 05:29, Andrew at MidWest Coast Media via
> use-livecode  wrote:
> 
>> I have released my first project with in-app purchases but only to 50%
>> platform success: Android works but iOS does not. I?m using the directions
>> at
>> https://lessons.livecode.com/m/4069/l/186807-how-do-i-implement-in-app-purchases-in-livecode-apple-appstore
>> but am getting generic errors.
>> 
>> I had been receiving the dreaded ?Cannot connect to iTunes Store? error,
>> but did the test user creation dance a couple times to step past that.
>> When trying in the simulator with a real user account or registered
>> sandbox user I?m getting a mobileStorePurchaseError of ?UNKNOWN_ERROR"
>> When trying on the device (production build from App Store) I?m getting a
>> mobileStorePurchaseError of ?An unknown error occurred?
>> 
>> These are all submitted and approved consumables registered in App Store
>> Connect. Is there anyway to track down a more descriptive error message?
>> Same code is working for Google Play.
>> 
>> Compiled with LiveCode 9.6.2rc3 on macOS 11.0.1 using Xcode 12.1
>> 
>> ?Andrew Bell
>> ___
>> use-livecode mailing list
>> use-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: New(?) Idea for Standalones

[matthias rebbe via use-livecode]

Don't blame Microsoft and Apple
There is a reason why MS and Apple require such things. It is security.

If there weren't any "bad" people who try to hack, hijack or infect our 
computers using viruses, trojan or other ways, then it wouldn't be necessary 
either.

As a developer I am also not very happy with those security requirements, 
because building standalones for deployment take more time than it took several 
years ago.
And purchasing a code signing certificate for Windows here in Germany was  also 
not very easy years ago, especially for independent developers. 
It was not just purchasing it in an online store. After purchase i had to proof 
my identity through a notary agency. Comodo contacted my lawyer/notary and 
asked for a confirmation that i am a real person.
Therefor i had to visit the notary office, show my papers to get authenticated. 
 So i had not only pay for the certificate, but also for the authentication 
through the lawyer/notary. 
Thanks god, now Comodo is using public business registers for confirmation and 
luckily i am listed in one of them now. So the authenticaton process is much 
faster and without any additonal costs. 

As a customer btw i really prefer secure software. I know that even with those 
security achievements software is not 100% secure, but more secure than without 
any notarization/code signing.


-
Matthias Rebbe
Life Is Too Short For Boring Code

> Am 29.03.2021 um 19:01 schrieb Roger Guay via use-livecode 
> :
> 
> Beautifully said, Rick! Especially your point about it being a PITA.
> 
> Thanks!
> 
> 
>> On Mar 29, 2021, at 9:36 AM, Rick Harrison via use-livecode 
>>  wrote:
>> 
>> Hi Mark,
>> 
>> Perhaps improving standalone building should be put at
>> the top of the priority of things to improve for LiveCode.
>> 
>> I think people are very frustrated that they are having
>> great difficulties in building a standalone. A process that
>> used to be relatively simple is now way too complex.
>> 
>> Many LC users want to be able to create their application,
>> and deploy it quickly to their own computers, or to give
>> away to their family members.  They are not interested
>> in inserting Apple or other corporations into their personal
>> programming loop, and a lot of us feel the same way.
>> 
>> No one wants to deal with having to create bundle ids
>> or other corporate nonsense.  (Option for a unique random
>> bundle id generator here?)
>> 
>> I believe users want LC to step up it’s game in dealing
>> with these issues so the deployment experience is an
>> enjoyable one, and not a PITA.
>> 
>> Successfully addressing this problem helps everyone!
>> 
>> Just my 2 cents for the day.  ;-)
>> 
>> Rick
>> 
>> 
>>> 
>>> In terms of the general thrust behind this thread - I completely agree that 
>>> standalone building has become tortuous over the last few years as all 
>>> platforms add more and more hoops you have to jump through. However, this 
>>> is probably best done by improving the standalone building process (i.e. 
>>> making it as easy as possible) rather than anything else.
>>> 
>>> Warmest Regards,
>>> 
>>> Mark.
>>> 
>>> -- 
>>> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
>>> LiveCode: Everyone can create apps
>> 
>> 
>> ___
>> use-livecode mailing list
>> use-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: We don't need a Player (was Re: New(?) Idea for Standalones)

[Trevor DeVore via use-livecode]

On Mon, Mar 29, 2021 at 10:57 AM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> TL/DR:
>
> We don't need a generic player.
>
> What we need is an updated Standalone Builder, to provide more complete
> tooling and better guidance for building a modern standalone.
>

An easy way to extend the standalone building process with plugins is a
necessity IMO as well. For example, when packaging an app with Levure you
can add in Helpers to further customize the output generated when packaging
an app for distribution. In addition to handling signing, notarizing, and
stapling, one can generate a DMG using DropDMG, create an InnoSetup
installer script, creat a WIX installer script (creates a Windows installer
file that IT departments love), etc.

LiveCode doesn't need to build support for all of these in the SB, but it
should provide hooks so that plugins can further customize the process.

-- 
Trevor DeVore
ScreenSteps
www.screensteps.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: New(?) Idea for Standalones

[Roger Guay via use-livecode]

Beautifully said, Rick! Especially your point about it being a PITA.

Thanks!


> On Mar 29, 2021, at 9:36 AM, Rick Harrison via use-livecode 
>  wrote:
> 
> Hi Mark,
> 
> Perhaps improving standalone building should be put at
> the top of the priority of things to improve for LiveCode.
> 
> I think people are very frustrated that they are having
> great difficulties in building a standalone. A process that
> used to be relatively simple is now way too complex.
> 
> Many LC users want to be able to create their application,
> and deploy it quickly to their own computers, or to give
> away to their family members.  They are not interested
> in inserting Apple or other corporations into their personal
> programming loop, and a lot of us feel the same way.
> 
> No one wants to deal with having to create bundle ids
> or other corporate nonsense.  (Option for a unique random
> bundle id generator here?)
> 
> I believe users want LC to step up it’s game in dealing
> with these issues so the deployment experience is an
> enjoyable one, and not a PITA.
> 
> Successfully addressing this problem helps everyone!
> 
> Just my 2 cents for the day.  ;-)
> 
> Rick
> 
> 
>> 
>> In terms of the general thrust behind this thread - I completely agree that 
>> standalone building has become tortuous over the last few years as all 
>> platforms add more and more hoops you have to jump through. However, this is 
>> probably best done by improving the standalone building process (i.e. making 
>> it as easy as possible) rather than anything else.
>> 
>> Warmest Regards,
>> 
>> Mark.
>> 
>> -- 
>> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
>> LiveCode: Everyone can create apps
> 
> 
> ___
> use-livecode mailing list
> use-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: New(?) Idea for Standalones

[Paul Dupuis via use-livecode]

On 3/29/2021 12:28 PM, Roger Guay via use-livecode wrote:

In any case it is not as easy as it use to be and IMO, this door may be closing.
You are 100% right. The door is closing and will eventually be closed 
unless enough consumers of Apple (and Windows) products complain with 
their buying power to Apple and Microsoft.



___
use-livecode mailing list
use-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: We don't need a Player (was Re: New(?) Idea for Standalones)

[Brian Milby via use-livecode]

The days of distributing apps without a cost to the developer are unfortunately 
over (Mac/Win).  If you want someone to be able to open an app on their Mac 
without jumping through hoops, then you need to be a paid developer and do the 
sign/notarize dance.  LC could help automate parts of the process, but getting 
the certificates seems to require some manual steps.  First advanced session in 
LCG covered it last week (but since I don’t do it, I did not fully pay 
attention to all of the details).

Sent from my iPhone

> On Mar 29, 2021, at 12:38 PM, Roger Guay via use-livecode 
>  wrote:
> 
> YES . . . What he said!
> 
>> On Mar 29, 2021, at 8:55 AM, Richard Gaskin via use-livecode 
>>  wrote:
>> 
>> TL/DR:
>> 
>> We don't need a generic player.
>> 
>> What we need is an updated Standalone Builder, to provide more complete 
>> tooling and better guidance for building a modern standalone.
>> 
>> 
>> 
>> - more complete version 
>> 
>> 
>> Background
>> --
>> 
>> This thread, and many others like it, didn't start with a desire for a 
>> player.  That was merely a response to the challenges of building 
>> standalones.
>> 
>> Building standalones is the point of LiveCode, the culmination of everything 
>> in LC's user experience.
>> 
>> And it's become a pain point for most, early-prohibitive for some.
>> 
>> OS changes are of course not LC's fault.  But they are LC's opportunity, if 
>> the company wants to maintain its place as the easiest solution for making 
>> apps.
>> 
>> 
>> 
>> The Last Great Deployment Change
>> 
>> 
>> Back in the early days, the IDE's Standalone Builder didn't provide any 
>> support for document associations, creator codes, or other essentials we now 
>> take for granted.  It was expected we'd open some dev tool from Apple 
>> (ResEdit) to set those up.
>> 
>> LC Ltd recognized those steps were cumbersome, and often error-prone where 
>> they were being done at all.
>> 
>> So they took the time to completely redesign the Standalone Builder to 
>> include support for nearly every detail apps need for solid deployment.
>> 
>> 
>> 
>> The Next Great Deployment Change
>> 
>> 
>> Many if not most deployment tooling required by OSes are command-line apps, 
>> lending themselves well to being called from another program, such as LC's 
>> Standalone Builder.
>> 
>> Automate everything possible.
>> 
>> And where a step can't be automated, guidance and be provided, such as a 
>> direct link right in the SB's UI to the necessary steps for completing the 
>> process, laid out with sufficient clarity and detail to allow the user to 
>> complete the build with confidence.
>> 
>> If a standalone building step is essential, it needs to be handled in the 
>> Standalone Builder.
>> 
>> Use direct automation where possible, or a direct link in the UI to 
>> step-by-step instructions needed to complete the task.
>> 
>> 
>> 
>> The Business Case
>> -
>> As we've seen here and many other threads like it from time to time, as long 
>> as building a standalone in LC is characterized by confusion and dread, 
>> people will seek alternatives.
>> 
>> Any alternative either compromises LC's revenue model (based as it is around 
>> standalone licensing), or eliminates it (if LC is just as hard to use as 
>> anything else, why not use anything else?).
>> 
>> No option provides as much return on investment as focusing on updating the 
>> Standalone Builder to be as simple and graceful as it can possibly be.
>> 
>> LC has a strong advantage with its language, made a nearly unbeatable with 
>> its integrated GUI object model.
>> 
>> Bring deployment up to par with the rest of the experience, and LC has a 
>> chance for a good life ahead, slowing attrition rates while accelerating 
>> growth.
>> 
>> -- 
>> 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
> 
> ___
> use-livecode mailing list
> use-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: New(?) Idea for Standalones

[Paul Dupuis via use-livecode]

On 3/29/2021 12:36 PM, Rick Harrison via use-livecode wrote:

Many LC users want to be able to create their application,
and deploy it quickly to their own computers, or to give
away to their family members.  They are not interested
in inserting Apple or other corporations into their personal
programming loop, and a lot of us feel the same way.

The real people to make this very valid complaint to is Apple and Microsoft.

They are the reason why Standalone building is so complex. They are 
actively changing their operating systems to make it harder and harder 
(if not impossible) to build and app to just give to a family member 
without inserting them (Apple and/or Microsoft) into the loop.



___
use-livecode mailing list
use-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: New(?) Idea for Standalones

[Paul Dupuis via use-livecode]

On 3/29/2021 12:15 PM, Mark Waddingham via use-livecode wrote:
In terms of the general thrust behind this thread - I completely agree 
that standalone building has become tortuous over the last few years 
as all platforms add more and more hoops you have to jump through. 
However, this is probably best done by improving the standalone 
building process (i.e. making it as easy as possible) rather than 
anything else. 


I complete agree that enhanced standalone building (vs any sort of 
player other than LiveCode itself as is) is the way to go - as Richard's 
new thread discusses.


Sadly, one thing I don't think we'll ever get back is single platform 
building. I started off in LC building for macOS and Widows (and 
sometime Linux) on Windows. And that was wonderful and super convenient 
to be able to do that. Then along came code signing requirements and I 
could (and can) still built on 1 platform for several, but I must code 
sign on each. And then Apple introduced the notarization requirement, 
yet one more thing that required platform differentiation.


What I would not give to get back to click one button and get code 
signed, notarized, and whatever to heck else standalones for all my 
deployment platforms all on a single platform (preferably Windows for me)!


I just think that the OS vendors will never let us get back to that.

___
use-livecode mailing list
use-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: New(?) Idea for Standalones

[J. Landman Gay via use-livecode]

Unfortunately nothing can replace the requirement for an Apple developer 
account on Mac, which is the reason for the request here. But I'd love to 
see notarization and stapling built in.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On March 29, 2021 11:17:06 AM Mark Waddingham via use-livecode 
 wrote:


In terms of the general thrust behind this thread - I completely agree
that standalone building has become tortuous over the last few years as
all platforms add more and more hoops you have to jump through. However,
this is probably best done by improving the standalone building process
(i.e. making it as easy as possible) rather than anything else.




___
use-livecode mailing list
use-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: We don't need a Player (was Re: New(?) Idea for Standalones)

[Roger Guay via use-livecode]

YES . . . What he said!

> On Mar 29, 2021, at 8:55 AM, Richard Gaskin via use-livecode 
>  wrote:
> 
> TL/DR:
> 
> We don't need a generic player.
> 
> What we need is an updated Standalone Builder, to provide more complete 
> tooling and better guidance for building a modern standalone.
> 
> 
> 
> - more complete version 
> 
> 
> Background
> --
> 
> This thread, and many others like it, didn't start with a desire for a 
> player.  That was merely a response to the challenges of building standalones.
> 
> Building standalones is the point of LiveCode, the culmination of everything 
> in LC's user experience.
> 
> And it's become a pain point for most, early-prohibitive for some.
> 
> OS changes are of course not LC's fault.  But they are LC's opportunity, if 
> the company wants to maintain its place as the easiest solution for making 
> apps.
> 
> 
> 
> The Last Great Deployment Change
> 
> 
> Back in the early days, the IDE's Standalone Builder didn't provide any 
> support for document associations, creator codes, or other essentials we now 
> take for granted.  It was expected we'd open some dev tool from Apple 
> (ResEdit) to set those up.
> 
> LC Ltd recognized those steps were cumbersome, and often error-prone where 
> they were being done at all.
> 
> So they took the time to completely redesign the Standalone Builder to 
> include support for nearly every detail apps need for solid deployment.
> 
> 
> 
> The Next Great Deployment Change
> 
> 
> Many if not most deployment tooling required by OSes are command-line apps, 
> lending themselves well to being called from another program, such as LC's 
> Standalone Builder.
> 
> Automate everything possible.
> 
> And where a step can't be automated, guidance and be provided, such as a 
> direct link right in the SB's UI to the necessary steps for completing the 
> process, laid out with sufficient clarity and detail to allow the user to 
> complete the build with confidence.
> 
> If a standalone building step is essential, it needs to be handled in the 
> Standalone Builder.
> 
> Use direct automation where possible, or a direct link in the UI to 
> step-by-step instructions needed to complete the task.
> 
> 
> 
> The Business Case
> -
> As we've seen here and many other threads like it from time to time, as long 
> as building a standalone in LC is characterized by confusion and dread, 
> people will seek alternatives.
> 
> Any alternative either compromises LC's revenue model (based as it is around 
> standalone licensing), or eliminates it (if LC is just as hard to use as 
> anything else, why not use anything else?).
> 
> No option provides as much return on investment as focusing on updating the 
> Standalone Builder to be as simple and graceful as it can possibly be.
> 
> LC has a strong advantage with its language, made a nearly unbeatable with 
> its integrated GUI object model.
> 
> Bring deployment up to par with the rest of the experience, and LC has a 
> chance for a good life ahead, slowing attrition rates while accelerating 
> growth.
> 
> -- 
> 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

___
use-livecode mailing list
use-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: New(?) Idea for Standalones

[Rick Harrison via use-livecode]

Hi Mark,

Perhaps improving standalone building should be put at
the top of the priority of things to improve for LiveCode.

I think people are very frustrated that they are having
great difficulties in building a standalone. A process that
used to be relatively simple is now way too complex.

Many LC users want to be able to create their application,
and deploy it quickly to their own computers, or to give
away to their family members.  They are not interested
in inserting Apple or other corporations into their personal
programming loop, and a lot of us feel the same way.

No one wants to deal with having to create bundle ids
or other corporate nonsense.  (Option for a unique random
bundle id generator here?)

I believe users want LC to step up it’s game in dealing
with these issues so the deployment experience is an
enjoyable one, and not a PITA.

Successfully addressing this problem helps everyone!

Just my 2 cents for the day.  ;-)

Rick


> 
> In terms of the general thrust behind this thread - I completely agree that 
> standalone building has become tortuous over the last few years as all 
> platforms add more and more hoops you have to jump through. However, this is 
> probably best done by improving the standalone building process (i.e. making 
> it as easy as possible) rather than anything else.
> 
> Warmest Regards,
> 
> Mark.
> 
> -- 
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps


___
use-livecode mailing list
use-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: New(?) Idea for Standalones

[Roger Guay via use-livecode]

Craig,

I apologize for the confusion. I tended to shift focus throughout this thread.

I too have, in the past, made and distributed standalones with great ease. But 
recently Apple and perhaps others have made it very difficult to do this as 
they are now requiring(?) that one be an Apple developer with an increasingly 
complex process for certifying apps for distribution.

In this thread, others have claimed that one can still do this (build 
distributable standalones w/o being an Apple developer etc.) with a slightly 
more convoluted process which I have not yet been able to replicate on Mac OS 
11.2. I’m still working on it. In any case it is not as easy as it use to be 
and IMO, this door may be closing.

All I want is a simple reliable, repeatable easy to use method/process for 
sharing stacks or Standalones with friends, family and colleagues without 
having to become an Apple developer. 

So Craig, I would appreciate knowing more about your process.


HTH,

Roger

> I make and update standalones regularly on my Mac, and distribute them to 
> many Windows and Mac desktop users in my company. All for “personal’ use.
> 

___
use-livecode mailing list
use-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: New(?) Idea for Standalones

[John Balgenorth via use-livecode]

And another good reason not to kick sand in LC’s face is they appear
to be the only ones who have invested the money and time for the
free community version to exist as it is today with the many features
it has now.  Think about if before you become so cheap & selfish that
you try to destroy them.

JB

> On Mar 29, 2021, at 9:16 AM, Mark Waddingham via use-livecode 
>  wrote:
> 
> On 2021-03-27 22:22, J. Landman Gay via use-livecode wrote:
>> Also note: The stacks you distribute cannot violate the LC license
>> agreement. They can't reproduce IDE features or allow users to do
>> things that only a licensed user can do. Please don't violate the
>> license agreement; we all want LC to prosper.
> 
> Indeed.
> 
> I feel I must explicitly point out at this point that, in addition to 
> forbidding creation of LiveCode-IDE-like applications, the commercial license 
> agreement also explicitly prohibit generic player apps (or indeed any player 
> app which allows a non-commercially licensed user to access commercial 
> features).
> 
> I strongly recommend reviewing section 3 of the (commercial) license 
> agreement for full details. The reason these clauses are there is to ensure 
> we don't end up in a situation where we only ever sell one LC license a year: 
> to a person who creates and distributes a player app and an automated build 
> service using a business license to spit out standalones for everyone else 
> who is using Community.
> 
> In terms of the general thrust behind this thread - I completely agree that 
> standalone building has become tortuous over the last few years as all 
> platforms add more and more hoops you have to jump through. However, this is 
> probably best done by improving the standalone building process (i.e. making 
> it as easy as possible) rather than anything else.
> 
> Warmest Regards,
> 
> Mark.
> 
> -- 
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
> 
> ___
> use-livecode mailing list
> use-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: New(?) Idea for Standalones

[Mark Waddingham via use-livecode]

On 2021-03-27 22:22, J. Landman Gay via use-livecode wrote:

Also note: The stacks you distribute cannot violate the LC license
agreement. They can't reproduce IDE features or allow users to do
things that only a licensed user can do. Please don't violate the
license agreement; we all want LC to prosper.


Indeed.

I feel I must explicitly point out at this point that, in addition to 
forbidding creation of LiveCode-IDE-like applications, the commercial 
license agreement also explicitly prohibit generic player apps (or 
indeed any player app which allows a non-commercially licensed user to 
access commercial features).


I strongly recommend reviewing section 3 of the (commercial) license 
agreement for full details. The reason these clauses are there is to 
ensure we don't end up in a situation where we only ever sell one LC 
license a year: to a person who creates and distributes a player app and 
an automated build service using a business license to spit out 
standalones for everyone else who is using Community.


In terms of the general thrust behind this thread - I completely agree 
that standalone building has become tortuous over the last few years as 
all platforms add more and more hoops you have to jump through. However, 
this is probably best done by improving the standalone building process 
(i.e. making it as easy as possible) rather than anything else.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

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

We don't need a Player (was Re: New(?) Idea for Standalones)

[Richard Gaskin via use-livecode]

TL/DR:

We don't need a generic player.

What we need is an updated Standalone Builder, to provide more complete 
tooling and better guidance for building a modern standalone.




- more complete version 


Background
--

This thread, and many others like it, didn't start with a desire for a 
player.  That was merely a response to the challenges of building 
standalones.


Building standalones is the point of LiveCode, the culmination of 
everything in LC's user experience.


And it's become a pain point for most, early-prohibitive for some.

OS changes are of course not LC's fault.  But they are LC's opportunity, 
if the company wants to maintain its place as the easiest solution for 
making apps.




The Last Great Deployment Change


Back in the early days, the IDE's Standalone Builder didn't provide any 
support for document associations, creator codes, or other essentials we 
now take for granted.  It was expected we'd open some dev tool from 
Apple (ResEdit) to set those up.


LC Ltd recognized those steps were cumbersome, and often error-prone 
where they were being done at all.


So they took the time to completely redesign the Standalone Builder to 
include support for nearly every detail apps need for solid deployment.




The Next Great Deployment Change


Many if not most deployment tooling required by OSes are command-line 
apps, lending themselves well to being called from another program, such 
as LC's Standalone Builder.


Automate everything possible.

And where a step can't be automated, guidance and be provided, such as a 
direct link right in the SB's UI to the necessary steps for completing 
the process, laid out with sufficient clarity and detail to allow the 
user to complete the build with confidence.


If a standalone building step is essential, it needs to be handled in 
the Standalone Builder.


Use direct automation where possible, or a direct link in the UI to 
step-by-step instructions needed to complete the task.




The Business Case
-
As we've seen here and many other threads like it from time to time, as 
long as building a standalone in LC is characterized by confusion and 
dread, people will seek alternatives.


Any alternative either compromises LC's revenue model (based as it is 
around standalone licensing), or eliminates it (if LC is just as hard to 
use as anything else, why not use anything else?).


No option provides as much return on investment as focusing on updating 
the Standalone Builder to be as simple and graceful as it can possibly be.


LC has a strong advantage with its language, made a nearly unbeatable 
with its integrated GUI object model.


Bring deployment up to par with the rest of the experience, and LC has a 
chance for a good life ahead, slowing attrition rates while accelerating 
growth.


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

[ANN] This Week in LiveCode 260

[panagiotis merakos via use-livecode]

Hi all,

Read about new developments in LiveCode open source and the open source
community in today's edition of the "This Week in LiveCode" newsletter!

Read issue #260 here: https://bit.ly/3u1lz5K

This is a weekly newsletter about LiveCode, focussing on what's been
going on in and around the open source project. New issues will be
released weekly on Mondays. We have a dedicated mailing list that will
deliver each issue directly to your e-mail, so you don't miss any!

If you have anything you'd like mentioned (a project, a discussion
somewhere, an upcoming event) then please get in touch.

-- 
Panagiotis Merakos 
LiveCode Software Developer

Everyone Can Create Apps 
___
use-livecode mailing list
use-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: mobileStoreMakePurchase not working for iOS

[panagiotis merakos via use-livecode]

Hello Andrew,

Just to mention that in-app purchases are not supported in the Simulator.

Kind regards,
Panos
--

On Fri, 26 Mar 2021 at 05:29, Andrew at MidWest Coast Media via
use-livecode  wrote:

> I have released my first project with in-app purchases but only to 50%
> platform success: Android works but iOS does not. I’m using the directions
> at
> https://lessons.livecode.com/m/4069/l/186807-how-do-i-implement-in-app-purchases-in-livecode-apple-appstore
> but am getting generic errors.
>
> I had been receiving the dreaded “Cannot connect to iTunes Store” error,
> but did the test user creation dance a couple times to step past that.
> When trying in the simulator with a real user account or registered
> sandbox user I’m getting a mobileStorePurchaseError of “UNKNOWN_ERROR"
> When trying on the device (production build from App Store) I’m getting a
> mobileStorePurchaseError of “An unknown error occurred”
>
> These are all submitted and approved consumables registered in App Store
> Connect. Is there anyway to track down a more descriptive error message?
> Same code is working for Google Play.
>
> Compiled with LiveCode 9.6.2rc3 on macOS 11.0.1 using Xcode 12.1
>
> —Andrew Bell
> ___
> use-livecode mailing list
> use-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: How to install tsNet correctly?

[Tiemo via use-livecode]

Thanks Matthias for your quick jump in.

It obviously was a very old behaviour of mine, regarding some very old version 

Tiemo


-Ursprüngliche Nachricht-
Von: use-livecode  Im Auftrag von 
matthias rebbe via use-livecode
Gesendet: Montag, 29. März 2021 15:47
An: How to use LiveCode 
Cc: matthias_livecode_150...@m-r-d.de
Betreff: Re: How to install tsNet correctly?

Hi Tiemo,

please see my answers below.

Regards,
Matthias


> Am 29.03.2021 um 15:24 schrieb Tiemo via use-livecode 
> :
> 
> Hello,
> 
> it's some time ago, that I build a new install.
> 
> 
> 
> On Windows I formerly just copied the "tsNet-x86" dll into the 
> Externals folder in my runtime dir and everything was fine.
> 
> When looking into the LC install dir on C:\programs\runrev\ there is a 
> \Ext\tsNet_Indy_1.4.2\ folder with quite some files and subfolders.
> 
> Is it still sufficient, to copy the tsNet-x86_64.dll (and 
> tsNet-x86.dll?) to my runtime dir, or should I copy the whole folder 
> \Ext\tsNet_Indy_1.4.2 into my runtime dir?
> 
LC handles the inclusion of tsNET if "search for required inclusions..." is 
selected in the standalone settings.

For Windows the tsNet external still is just the .dll (tsNet-x86.dll  for 32bit 
tsNet-x86_64.dll for 64bit)


> Or does LC handles everything automatically by now and I  don't I have 
> to copy the needed dlls manually? I really don't know anymore, I 
> couldn't follow the list for some time.
> 
> And on osMAC?
> 
Same, inclusion of tsNet is handled by LC if "search for..." is selected.

Btw., in which version of LC did you notice that faulty behaviour?

Regards,
Matthias


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


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


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

Re: How to install tsNet correctly?

[matthias rebbe via use-livecode]

Hi Tiemo,

please see my answers below.

Regards,
Matthias


> Am 29.03.2021 um 15:24 schrieb Tiemo via use-livecode 
> :
> 
> Hello,
> 
> it's some time ago, that I build a new install.
> 
> 
> 
> On Windows I formerly just copied the "tsNet-x86" dll into the Externals
> folder in my runtime dir and everything was fine.
> 
> When looking into the LC install dir on C:\programs\runrev\ there is a
> \Ext\tsNet_Indy_1.4.2\ folder with quite some files and subfolders.
> 
> Is it still sufficient, to copy the tsNet-x86_64.dll (and tsNet-x86.dll?) to
> my runtime dir, or should I copy the whole folder \Ext\tsNet_Indy_1.4.2 into
> my runtime dir?
> 
LC handles the inclusion of tsNET if "search for required inclusions..." is 
selected in the standalone settings.

For Windows the tsNet external still is just the .dll (tsNet-x86.dll  for 32bit 
tsNet-x86_64.dll for 64bit)


> Or does LC handles everything automatically by now and I  don't I have to
> copy the needed dlls manually? I really don't know anymore, I couldn't
> follow the list for some time.
> 
> And on osMAC?
> 
Same, inclusion of tsNet is handled by LC if "search for..." is selected.

Btw., in which version of LC did you notice that faulty behaviour?

Regards,
Matthias


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


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

Re: New(?) Idea for Standalones

[Craig Newman via use-livecode]

I have been following this thread with interest, and have no idea what anyone 
is talking about.

I make and update standalones regularly on my Mac, and distribute them to many 
Windows and Mac desktop users in my company. All for “personal’ use.

Somewhere in the middle of all this, I thought that the issue was distributing 
to mobile, and saw the problem, but then noticed that the issue was 
distributing to desktop, and became confused

So though I may be breaking the law, what prevents anyone from doing what i do?

What am i missing?

Craig

> On Mar 29, 2021, at 1:17 AM, John Balgenorth via use-livecode 
>  wrote:
> 
> Thanks for clarifying that for me!
> 
> As far as the license stuff goes on the community version I personally
> think the community is allowed to supersede LiveCode if they feel like
> investing the time.  It should not be able to be held back just to make
> sure all of the new features are done by the LiveCode Team. As long
> as it is kept public like the community version was designed to do.
> 
> JB
> 
>> On Mar 28, 2021, at 10:04 PM, Roger Guay via use-livecode 
>>  wrote:
>> 
>> John et al,
>> 
>> To recap: 
>> 
>> My ultimate goal is to get support for RunRev to provide a LiveCodeLight 
>> download that opens stacks but hides or strips the IDE. I can’t believe this 
>> would be difficult in any way.
>> 
>> In the meantime, I am trying to recreate the old Standalone app method (See 
>> Jacquelines’ post in this thread) that opens stacks. 2 or more OSs ago this 
>> was extremely easy to do, but because of the increasing complexity of Apple 
>> requirements (and Windows?) it is now quite difficult and I have yet to 
>> succeed at it. Even if it is still possible, I shudder to think what they 
>> will do next to further complicate our efforts to simple collaborate and 
>> share with family and friends.
>> 
>> Thanks to all who are taking an interest.
>> 
>> Roger
>> 
>> 
>> 
>>> On Mar 28, 2021, at 9:14 PM, John Balgenorth via use-livecode 
>>>  wrote:
>>> 
>>> I was thinking one of the reasons people were saying not to provide a
>>> scaled down version of the development system to do it was because
>>> they were afraid it would interfere with the license. But since you can
>>> do it according to some of you is proof you are allowed to automate
>>> the process and that should not interfere with the user license.
>>> 
>>> JB
>>> 
> On Mar 28, 2021, at 9:04 PM, Dev via use-livecode 
>  wrote:
 
 If it works, the upside is that anyone can do it themselves and coach 
 their family into doing the two step process once on the first time 
 install.
 
 If it doesn’t work, we need to get a real developer to make a real app 
 that jumps through Apple’s hoops. And then the developer has to keep it 
 updated every time Apple makes a change. 
 
 I agree this whole thing is a bother, but as other posts have pointed out, 
 “This is not the good old days and security is not going away” so this 
 whole discussion is trying to find the narrowest point to cross. If the 
 amateurs can do it themselves with a two step magic incantation, then this 
 puts the ball back in their court and allows them into the game with out 
 going through the Apple doorway.
 
 Kelly
 
> On 28 Mar, 2021, at 9:54 PM, John Balgenorth via use-livecode 
>  wrote:
> 
> I may have got lost on this subject but if his goal was to make it
> easy for people to open his app by doing something like using a
> scaled down version of the development system then this one
> step of doing it twice is a valid reason for using what he wanted
> because people do not want to be bothered with things like that.
> 
> JB
> 
>>> On Mar 28, 2021, at 8:41 PM, scott--- via use-livecode 
>>>  wrote:
>> 
>> 
>> I may have described it incorrectly. After re-testing here on OS 11.2.3  
>> I found that it required two tries. Trying to open it the first time 
>> meets with failure. But Right clicking and choosing “Open” the second 
>> time gives a second dialog that will allow it to open.
>> 
>> —
>> Scott
>> 
>>> On Mar 28, 2021, at 2:58 PM, Roger Guay via use-livecode 
>>>  wrote:
>>> 
>>> Nope! Right clicking on a standalone I’m trying to share with my wife 
>>> on her iMac w OS 11.2 results in this menu: Open Attachment - Quick 
>>> Look Attachment - Save Attachment…. - Save to Downloads Folder - Share 
>>> - Copy - Speech
>>> 
>>> Then, clicking on the “Open Attachment” menu item results in the same 
>>> response I reported earlier: a simple screen with this message: You do 
>>> not have permission to open the application “StackOmatic”. “Contact 
>>> your computer or network administrator for assistance” with a simple 
>>> “OK” button. Dead end as before!
>>> 
>>> Further, at Kelly's suggestion to try and adjust settings in 

Re: mouseenter/mouseleave and pointer tool

[Paul Dupuis via use-livecode]

I think if you are making a drawing app in Livecode, you need mouseEnter 
and mouseLeave with the pointer tool so you can have object scrips 
change the cursor icon to appropriate icons when over certain special 
objects that you want to interact with as objects.


On 3/29/2021 6:31 AM, Klaus major-k via use-livecode wrote:

Hi friends,

when the pointer tool is active, "mouseenter" and "mouseleave"
handlers are executed nevertheless!?

I don't this this is correct behaviour!

For the sake of "conceptional continuity" (©Frank Zappa) then all
other mouse handlers should be executed and we don't want that. :-)
All or nothing, right?

I could swear this was not the case in earlier version, so I searched my
archives and found that this must have started with version 5.x of LC

I have an old MetaCard version with Rev engine 4.1 where this does NOT happen.
But DOES with LC version 5.02

What do you think?


Best

Klaus
--
Klaus Major
https://www.major-k.de
https://www.major-k.de/bass
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

Re: mouseenter/mouseleave and pointer tool

[Paul Dupuis via use-livecode]

I think if you are making a drawing app in Livecode, you need mouseEnter 
and mouseLeave with the pointer tool so you can have object scrips 
change the cursor icon to appropriate icons when over certain special 
objects that you want to interact with as objects.



On 3/29/2021 6:17 AM, Klaus major-k via use-livecode wrote:

Hi friends,

when the pointer tool is active, "mouseenter" and "mouseleave"
handlers are executed nevertheless!?

I don't this this is correct behaviour!

For the sake of "conceptional continuity" (©Frank Zappa) then all
other mouse handlers should be executed and we don't want that. :-)
All or nothing, right?

I could swear this was not the case in earlier version, so I searched my
archives and found that this must have started with version 5.x of LC

I have an old MetaCard version with Rev engine 4.1 where this does NOT happen.
But DOES with LC version 5.02

What do you think?


Best

Klaus
--
Klaus Major
https://www.major-k.de
https://www.major-k.de/bass
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

Re: mouseenter/mouseleave and pointer tool

[Craig Newman via use-livecode]

Klaus.

I have always seen this. It does seem a little odd,, though. You can always 
place something like this wherever you need to, but I know your question is 
“Why do I need to”

on mouseEnter

if the tool = "browse tool" then pass mouseEnter

end mouseEnter


Craig


> On Mar 29, 2021, at 6:31 AM, Klaus major-k via use-livecode 
>  wrote:
> 
> Hi friends,
> 
> when the pointer tool is active, "mouseenter" and "mouseleave"
> handlers are executed nevertheless!? 
> 
> I don't this this is correct behaviour!
> 
> For the sake of "conceptional continuity" (©Frank Zappa) then all 
> other mouse handlers should be executed and we don't want that. :-)
> All or nothing, right?
> 
> I could swear this was not the case in earlier version, so I searched my
> archives and found that this must have started with version 5.x of LC
> 
> I have an old MetaCard version with Rev engine 4.1 where this does NOT happen.
> But DOES with LC version 5.02
> 
> What do you think?
> 
> 
> Best
> 
> Klaus
> --
> Klaus Major
> https://www.major-k.de
> https://www.major-k.de/bass
> 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

How to install tsNet correctly?

[Tiemo via use-livecode]

Hello,

it's some time ago, that I build a new install.

 

On Windows I formerly just copied the "tsNet-x86" dll into the Externals
folder in my runtime dir and everything was fine.

When looking into the LC install dir on C:\programs\runrev\ there is a
\Ext\tsNet_Indy_1.4.2\ folder with quite some files and subfolders.

Is it still sufficient, to copy the tsNet-x86_64.dll (and tsNet-x86.dll?) to
my runtime dir, or should I copy the whole folder \Ext\tsNet_Indy_1.4.2 into
my runtime dir?

Or does LC handles everything automatically by now and I  don't I have to
copy the needed dlls manually? I really don't know anymore, I couldn't
follow the list for some time.

And on osMAC?

 

Thanks

Tiemo

 

 

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

mouseenter/mouseleave and pointer tool

[Klaus major-k via use-livecode]

Hi friends,

when the pointer tool is active, "mouseenter" and "mouseleave"
handlers are executed nevertheless!? 

I don't this this is correct behaviour!

For the sake of "conceptional continuity" (©Frank Zappa) then all 
other mouse handlers should be executed and we don't want that. :-)
All or nothing, right?

I could swear this was not the case in earlier version, so I searched my
archives and found that this must have started with version 5.x of LC

I have an old MetaCard version with Rev engine 4.1 where this does NOT happen.
But DOES with LC version 5.02

What do you think?


Best

Klaus
--
Klaus Major
https://www.major-k.de
https://www.major-k.de/bass
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

mouseenter/mouseleave and pointer tool

[Klaus major-k via use-livecode]

Hi friends,

when the pointer tool is active, "mouseenter" and "mouseleave"
handlers are executed nevertheless!? 

I don't this this is correct behaviour!

For the sake of "conceptional continuity" (©Frank Zappa) then all 
other mouse handlers should be executed and we don't want that. :-)
All or nothing, right?

I could swear this was not the case in earlier version, so I searched my
archives and found that this must have started with version 5.x of LC

I have an old MetaCard version with Rev engine 4.1 where this does NOT happen.
But DOES with LC version 5.02

What do you think?


Best

Klaus
--
Klaus Major
https://www.major-k.de
https://www.major-k.de/bass
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

Re: Resources folder on mac, and the good old days

[David V Glasgow via use-livecode]

I am following this with interest because, as I have previously lamented, I 
would like to give away apps to colleagues without the huge, incomprehensible 
headache of certificates, signing and notarising etc.

I want to make absolutely sure that I understand it correctly, that a player 
app which was enabled to run on a machine (either by user or the more formal 
method) could be designed to list and run any number of stacks distributed as 
stacks, and placed in a designated folder or sub folder.

If correct, doesn’t that:

A/  Enable distribution and updating of any LC ‘app’ simply by the prospective 
user dropping it into the correct folder?  (AKA ‘the good old days')

B/  Undermine the fundamental intention of certification in the first place?  
(Personally, I would trust Livecoders, and indeed often run posted stacks 
without a second thought, but what if Richmond* went over to the dark side?) 

Cheers

David G

* Selected not because I think he might, but because the idea is amusing
___
use-livecode mailing list
use-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: Unreliable File Deletion

[Mark Waddingham via use-livecode]

On 2021-03-28 18:11, R.H. via use-livecode wrote:

@ Peter Reid

Your message found my attention.
Also I am working on Windows 10 and have the same problem using LC 
9.6.1

Indy version.

The similar or same problem as you have: I want to delete the text 
file.

The command I issue is "detele file ". The error it returns:
"Can't delete file".


All cases of people reporting bugs with 'delete file' on Windows that I 
have seen fall into one of two cases:


1) The path they give to 'delete file' is wrong.

2) The file they are trying to delete is open by the app, or by another 
app.


In terms of (1) - its easy to determine - log the path you are using, or 
use 'there is a file ' (but make sure the file you are 
checking for / logging *is* actually the same path as being passed to 
'delete file').


In terms of (2) - Windows and UNIX-derived OSes have a critical 
difference when it comes to filesystems - in UNIX land you can delete a 
file which another process has open, on Windows you can't. (Note: It is 
possible for multiple processes on Windows to open the same file, if 
none have requested exclusive access, but the file cannot be 
deleted/renamed/moved until it is not open by any process).



... // Delete temp file

... delete file ("binfile:")
... put the result into tResult
... if "can't delete that file" is in tResult then

.. myMSG tHInfo & "File could not be deleted." & tFilePath --> 
My

message handler


This script falls into category (1) above - you are giving delete file a 
binfile URL. The 'delete file' command requires a normal file path, not 
a URL of any kind.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-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: Resources folder on mac, and the good old days

[Mark Waddingham via use-livecode]

On 2021-03-29 03:13, Neville Smythe via use-livecode wrote:

you may already know this, but this will not work in a standalone!
We will surely not have write permissions in that folder!

As a workaround I would probably use -> specialfolderpath("temporary")
Or even write the text to -> the tempname



There is no problem writing to the resources folder. That’s the
logical place to put the user-changeable stack files for a standalone,
making the auxiliary files invisible to external fiddling by the user,
 which a Good Thing (although that does make the app look different on
Windows or Linux).


Unfortunately this has never been true on macOS X.

The Resources folder (which is in the macOS app bundle) should be 
treated as read-only...


This has always been true - the correct (Apple guideline compliant!) 
place to put files that are 'internal' to the app but created/modified 
at runtime and which should persist between restarts of the app is in 
the 'Application Support' folder - in a sub-folder which is named the 
same as the app's id (e.g. com.myapp.mycompany).


[ Apple guidance is here - 
 
]


The read-only ness of resources isn't strictly enforced - especially if 
the standalone is built on the machine it is run (app bundles downloaded 
from the internet, for example, have file attributes added which mark 
them as 'quarantined' - even if unpacked from a zip/archive)... However, 
you will notice some more 'unpleasant' effects, typically, if you move 
the standalone to another machine - these will range from prompt dialogs 
allowing access, to dialogs requesting root permission (if the user has 
put the standalone, say, in /Applications).


In contrast, I do not believe that writing to stuff under 'Application 
Support' ever produces a user-visible prompt dialog on any version of 
macOS.


Additionally, code-signing requirements are becoming more stringent over 
time - off the top of my head I can't remember whether codesign has 
started including non-executable resources in the signature - but as 
soon as it does (if it doesn't already), any signed and notarized app 
will break if any of the files in the app bundle are modified / removed 
/ added to.



As for the Good Old Days of free distribution to other Mac (desktop)
users, they haven’t gone. Apple is making it harder for the
uninitiated to find out how to open “unsafe” files, but they don't
keep it a secret. And while recent rumours abound  about unnotarized
apps not working at all on some future MacOS, it does seem unlikely
that will actually happen, and if they do that’s time for us all to
reboot to Linux.


Indeed, it is unlikely that Apple will ever completely stop unnotarized 
apps from running (although they keep changing what you have to toggle 
to enable right-click Open to open the app!) - but ensuring you use 
appropriate paths for temporary / private writable app files means the 
least friction for the user.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

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