Interesting, and clever!
But how do they do that? Since the app can’t be running at the time it is moved
to the trash, the code can’t be in the app itself. Which means they must
install *another piece of code*, probably a daemon, which is running all the
time; which would be necessary anyway
That is correct. On my Mac, I modify 2 of the data grid behaviors (still
waiting on nested data grid behaviors LC) and I have to launch the new LC app
first before I do so, otherwise I bork the app. Once I do I can happily modify
the behaviors without an issue. Haven’t tried on the lates MacOS
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.
> 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
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
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
> 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
>
I find this discussions strange - I had the
