Seeking 'beta' testers - MacOS and iOS
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
- Livecode Opensource Backer
- Posts: 10116
- Joined: Fri Feb 19, 2010 10:17 am
Re: Seeking 'beta' testers - MacOS and iOS
Um:
- -
ProductName: macOS, ProductVersion: 13.2, ProductVersionExtra: (a)
Using version 1.1.53 of Calendar Library
Calling CalCheckCalendarAuth
tAuthStatus is set to : Authorized
Access is Authorized, calling local handler GetListOfEvents
GetListOfEvents fires.
Requesting events from :2022-12-01 to 2022-12-31
executing at 10:00:20 PM
LCB Error -[EKEvent allDay]: unrecognized selector sent to instance 0x7feca566daf0
Object GetEventsArray
LCB File ReadCalendarEvents.lcb
LCB Line 617
- -
ProductName: macOS, ProductVersion: 13.2, ProductVersionExtra: (a)
Using version 1.1.53 of Calendar Library
Calling CalCheckCalendarAuth
tAuthStatus is set to : Authorized
Access is Authorized, calling local handler GetListOfEvents
GetListOfEvents fires.
Requesting events from :2022-12-01 to 2022-12-31
executing at 10:00:20 PM
LCB Error -[EKEvent allDay]: unrecognized selector sent to instance 0x7feca566daf0
Object GetEventsArray
LCB File ReadCalendarEvents.lcb
LCB Line 617
-
- Posts: 919
- Joined: Wed Nov 04, 2009 11:41 am
Re: Seeking 'beta' testers - MacOS and iOS
Probably not! Here is a screen shot of my build settings: In future builds I will tick the experimental box. I wonder if one problem with the application is that I manually added a dot entitlements file to the package; it would not surprise me if Apple have added a check that detects modifications made post build.Did you build for 64 bit and include ARM?
The stack file running in the IDE should be using the permissions granted to the Livecode IDE e.g. Note that the version number appears incorrect but should be read as all versions up to and including v10.
The error message that Richmond posted is exactly the same line of code that failed last time meaning that my simple protective fix has not worked. I now suspect that Apple have removed a property and failed to update the documentation or they have introduced a bug into the Eventkit on Ventura. After all they report having made significant changes in that area.
If you are both still willing to help I will remove properties from the library in the hope I can bypass the issue. Also the next time I build the application I will not add anything to the 'package' plus I will build with the experimental option selected.
Here is a screen shot of the last application running on Big Sur. It also runs on Monterey.
best wishes
Skids
Skids
-
- Posts: 919
- Joined: Wed Nov 04, 2009 11:41 am
Re: Seeking 'beta' testers - MacOS and iOS
continued as unable to attach more than three images.
The application returning data. so I'm not making it all up !
I need to test the cut down version of the library before I post it to dropbox just incase I've added even more problems.
The application returning data. so I'm not making it all up !

I need to test the cut down version of the library before I post it to dropbox just incase I've added even more problems.
best wishes
Skids
Skids
Re: Seeking 'beta' testers - MacOS and iOS
Except, to state the obvious, LiveCode has not been granted permission in my case. And I can see way to grant permission.Simon Knight wrote: ↑Tue Dec 20, 2022 9:36 amThe stack file running in the IDE should be using the permissions granted to the Livecode IDE
There is no “+” sign I can see to add apps to the permissions list and I presume something has to trigger this from livecode IDE.
As yours is the only stack I’ve run that deals with Apple Calendar, I was hoping your stack may trigger this, but it doesn’t….
Any suggestions?
-
- Posts: 919
- Joined: Wed Nov 04, 2009 11:41 am
Re: Seeking 'beta' testers - MacOS and iOS
Updated application first.
I have built three versions : Intel only, Mac only ?ARM and both. I have not added the entitlements file as I am not convinced it is required and it may be triggering a gatekeeper response.
The version number matches the Library version and file comments have been added . The files have not been zipped.
Both check boxes checked Arm and Intel: https://www.dropbox.com/sh/3te72fzhgho1 ... DFI8a?dl=0
Intel only : https://www.dropbox.com/sh/0qddvxq3m289 ... CAOja?dl=0
ARM only : https://www.dropbox.com/sh/6j1c810t6xv8 ... 11mua?dl=0
Stack file and Library to follow
I have built three versions : Intel only, Mac only ?ARM and both. I have not added the entitlements file as I am not convinced it is required and it may be triggering a gatekeeper response.
The version number matches the Library version and file comments have been added . The files have not been zipped.
Both check boxes checked Arm and Intel: https://www.dropbox.com/sh/3te72fzhgho1 ... DFI8a?dl=0
Intel only : https://www.dropbox.com/sh/0qddvxq3m289 ... CAOja?dl=0
ARM only : https://www.dropbox.com/sh/6j1c810t6xv8 ... 11mua?dl=0
Stack file and Library to follow
best wishes
Skids
Skids
-
- Posts: 919
- Joined: Wed Nov 04, 2009 11:41 am
Re: Seeking 'beta' testers - MacOS and iOS
Updated livecode builder library package : https://www.dropbox.com/s/z5s9k6jzvv2uk ... 4.lce?dl=0
Unmodified stack file : https://www.dropbox.com/s/ua1ylvn8i6qwt ... ecode?dl=0
Unmodified stack file : https://www.dropbox.com/s/ua1ylvn8i6qwt ... ecode?dl=0
best wishes
Skids
Skids
-
- Posts: 919
- Joined: Wed Nov 04, 2009 11:41 am
Re: Seeking 'beta' testers - MacOS and iOS
The error that Richmond is seeing on Ventura :
I interpret to mean that the EKEvent property "allDay" is not being recognised. Version 1.1.54 no longer makes the call. Apple's documentation states: Line 617 was attempting to read the value of the allDay property and convert it into a string.executing at 10:00:20 PM
LCB Error -[EKEvent allDay]: unrecognized selector sent to instance 0x7feca566daf0
Object GetEventsArray
LCB File ReadCalendarEvents.lcb
LCB Line 617
best wishes
Skids
Skids
-
- Posts: 919
- Joined: Wed Nov 04, 2009 11:41 am
Re: Seeking 'beta' testers - MacOS and iOS
Stam
If you feel brave you can attempt to modify the SQLite database that is used to store the permissions. On Intel this can be achieved by using the tccutil command from the terminal. This may correct the situation where the database has been corrupted in some way.
From terminal :
and
and perhaps
as Apple seem to use either Contacts or AddressBook to refer to the same data.
These commands act as a permissions reset. After running them Livecode should prompt the user to grant permissions the next time it is run.
If the above fails then the only option is to edit the database directly by opening it in an application such as "DB Browser for SQLite". I have some notes somewhere that I will send if they are needed.
S
Well apart from moving to Linux I have no real idea. However......There is no “+” sign I can see to add apps to the permissions list and I presume something has to trigger this from livecode IDE.
As yours is the only stack I’ve run that deals with Apple Calendar, I was hoping your stack may trigger this, but it doesn’t….
Any suggestions?
If you feel brave you can attempt to modify the SQLite database that is used to store the permissions. On Intel this can be achieved by using the tccutil command from the terminal. This may correct the situation where the database has been corrupted in some way.
From terminal :
Code: Select all
tccutil reset Calendar com.runrev.livecode
Code: Select all
tccutil reset AddressBook com.runrev.livecode
Code: Select all
tccutil reset Contacts com.runrev.livecode
These commands act as a permissions reset. After running them Livecode should prompt the user to grant permissions the next time it is run.
If the above fails then the only option is to edit the database directly by opening it in an application such as "DB Browser for SQLite". I have some notes somewhere that I will send if they are needed.
S
best wishes
Skids
Skids
Re: Seeking 'beta' testers - MacOS and iOS
Hi Simon,Simon Knight wrote: ↑Tue Dec 20, 2022 10:16 amUpdated application first.
I have built three versions : Intel only, Mac only ?ARM and both. I have not added the entitlements file as I am not convinced it is required and it may be triggering a gatekeeper response.
The version number matches the Library version and file comments have been added . The files have not been zipped.
Both check boxes checked Arm and Intel: https://www.dropbox.com/sh/3te72fzhgho1 ... DFI8a?dl=0
Intel only : https://www.dropbox.com/sh/0qddvxq3m289 ... CAOja?dl=0
ARM only : https://www.dropbox.com/sh/6j1c810t6xv8 ... 11mua?dl=0
Stack file and Library to follow
not sure how/if you zipped these, but the download links all provide a .zip file. Unzipping them gives me the Contents folder of the app bundle, with no actual app bundle (ie instead of seeing Test_os_Eventkit.app, I just get a folder called "Contents")
The folder "Contents" I get unzipping the linked download is: given your comment on how you didn't zip the apps (really?) I tried just changing the extension from .app.zip to .app. Regardless of which version I try, I just get the response that the app cannot be run as it's not supported by this OS. I suspect the app needed to be zipped before transmitting as not doing so misses a vital element. Or probably more likely if you upload a folder (in this case the app.bundle), dropbox zips it for download by others and this does something funky.
If you would be kind enough to zip the files before uploading them, I'd be happy to try again...
S.
PS: tccutil did nothing to improve the situation. It did indeed reset the permissions to none; but running either liveCode or your stack did not actually give me the opportunity to add permissions. tccutil only sports the one command - reset - which of course does not add permissions.
And not sure how switching to linux would help lol

-
- Posts: 919
- Joined: Wed Nov 04, 2009 11:41 am
Re: Seeking 'beta' testers - MacOS and iOS
Arrrrgh!!!!
My view of drop box shows the files as .app which are packages so I guess that dropbox is zipping them in some way.
So I have put the three apps into one archive, it is 30Mbytes and should be on this link.
https://www.dropbox.com/s/b1bze0youxqak ... e.zip?dl=0
Simon
My view of drop box shows the files as .app which are packages so I guess that dropbox is zipping them in some way.
So I have put the three apps into one archive, it is 30Mbytes and should be on this link.
https://www.dropbox.com/s/b1bze0youxqak ... e.zip?dl=0
Simon
best wishes
Skids
Skids
-
- Posts: 919
- Joined: Wed Nov 04, 2009 11:41 am
Re: Seeking 'beta' testers - MacOS and iOS
I conducted some internet searches with reference to Ventura and Apple's "protection" mechanisms. Apple acknowledge that Ventura has issues with "Full Disc Access" with applications being listed as having access yet being denied. The forum of the note taking application Obsidian reports issues getting access to Calendar items: https://forum.obsidian.md/t/calendar-pe ... tura/46165.
So I wonder if the issues you both are seeing are more to do with Ventura than my Library. I have one last idea that I can try if the latest versions of the library and test application (links above) fail and that is to add the file Entitlements.plist via the Livecode standalone settings panel. However I do not believe this is necessary because there are three types of application protection :
1. - Nil, the old wild west no requirement for entitlements, developer ID etc - this is my test app.
2. - Hardened : requires entitlement file and be processed by Automatic Apple processing to generate and register some form of code (code-signing) available as a terminal command. Gatekeeper uses to confirm that nothing nasty has been added en-route to the computer trying to run the application.
3. - Full Sandbox : all hardened plus code notarisation by Apple. Full on Big Brother and required if Application is to be sold on the Application Store.
Note that the requirements for 2 and 3 overlap and are described across various documents published by Apple and are not very clear to me in so far as they assume that the reader knows what the terminology actually means. This link may be of interest https://wiki.freepascal.org/Hardened_runtime_for_macOS.
For unknown reasons Richmond is able to run the stack file whereas Stam is not. Richmond's version of Livecode is listed in the Privacy pane, Stam's is not. Perhaps this comes down to the status of the Privacy Pane at the time Ventura was installed.
I hope it is obvious that I may be writing rubbish but it would be useful to know what is going on.
Simon
So I wonder if the issues you both are seeing are more to do with Ventura than my Library. I have one last idea that I can try if the latest versions of the library and test application (links above) fail and that is to add the file Entitlements.plist via the Livecode standalone settings panel. However I do not believe this is necessary because there are three types of application protection :
1. - Nil, the old wild west no requirement for entitlements, developer ID etc - this is my test app.
2. - Hardened : requires entitlement file and be processed by Automatic Apple processing to generate and register some form of code (code-signing) available as a terminal command. Gatekeeper uses to confirm that nothing nasty has been added en-route to the computer trying to run the application.
3. - Full Sandbox : all hardened plus code notarisation by Apple. Full on Big Brother and required if Application is to be sold on the Application Store.
Note that the requirements for 2 and 3 overlap and are described across various documents published by Apple and are not very clear to me in so far as they assume that the reader knows what the terminology actually means. This link may be of interest https://wiki.freepascal.org/Hardened_runtime_for_macOS.
For unknown reasons Richmond is able to run the stack file whereas Stam is not. Richmond's version of Livecode is listed in the Privacy pane, Stam's is not. Perhaps this comes down to the status of the Privacy Pane at the time Ventura was installed.
I hope it is obvious that I may be writing rubbish but it would be useful to know what is going on.
Simon
best wishes
Skids
Skids
Re: Seeking 'beta' testers - MacOS and iOS
SUCCESS!Simon Knight wrote: ↑Tue Dec 20, 2022 10:01 pmArrrrgh!!!!
My view of drop box shows the files as .app which are packages so I guess that dropbox is zipping them in some way.
So I have put the three apps into one archive, it is 30Mbytes and should be on this link.
https://www.dropbox.com/s/b1bze0youxqak ... e.zip?dl=0
Simon
Again the dropbox weirdness of navigating into a zip like it's a folder and treating app bundles like normal folders does no one any favours.
But I did eventually just get it and clicked 'download even though I was just seeing 3 folders - and got 3 apps. I tested the ARM app and it worked fine.
This time it asked me for permission and was granted.
It instantly loaded a bunch of events from my calendar - I've not checked to see if it found everything as I have about 20 calendars, but it certainly did find many.
Log text:
HTHProductName: macOS, ProductVersion: 13.0.1, BuildVersion: 22A400
Using version 1.1.54 (all boolean values removed) of Calendar Library
Calling CalCheckCalendarAuth
tAuthStatus is set to : NotDetermined
Access is NotDetermined, calling CalRequestAuthorization()
EventKitRequestPermissionsCallBack fires!!!!
GetListOfEvents fires.
Requesting events from :2022-12-01 to 2022-12-31
110 events have been read from your calendar.
S.
Last edited by stam on Wed Dec 21, 2022 10:42 am, edited 1 time in total.
Re: Seeking 'beta' testers - MacOS and iOS
This is probably correct. If I get a chance I'll fire up an old intel Mac running MacOS Mojave and run the stack again if I have time (but time is scarce).Simon Knight wrote: ↑Wed Dec 21, 2022 10:18 amPerhaps this comes down to the status of the Privacy Pane at the time Ventura was installed.
Certainly the stack did not ask me to grant permissions on MacOS Ventura - but as above, your latest standalone does and it works as expected (I guess - I've not checked to see if all calendars have been retrieved).
S.
-
- Posts: 919
- Joined: Wed Nov 04, 2009 11:41 am
Re: Seeking 'beta' testers - MacOS and iOS
Thats great news although I wish I knew why it has started working. One reason is that I have just raised a bug report, https://quality.livecode.com/show_bug.cgi?id=24054
So to be clear you have confirmed that the Arm version of the application works when using version 1.1.54 of the Library.
Did you press the button a second time to confirm that the app did not ask for permission a second time ? Don't worry if not it should work ok as it is ok on Big Sur and Monterey.
Big Thanks and Merry Christmas.
Simon
So to be clear you have confirmed that the Arm version of the application works when using version 1.1.54 of the Library.
Did you press the button a second time to confirm that the app did not ask for permission a second time ? Don't worry if not it should work ok as it is ok on Big Sur and Monterey.
Big Thanks and Merry Christmas.
Simon
best wishes
Skids
Skids
Re: Seeking 'beta' testers - MacOS and iOS
Yes, I only tested the ARM version. Keep in mind I had reset privileges with tccutil, so no app was listed in the calendar permissions pane.
On clicking the populate button (once), it brought up the dialog box to ask for permission, it was granted and everything worked as expected.
What happened with the stack previously was that it did not ask for permission - I only tested the stack because the previous app you released had the same issue as the the one I reported, causing issues because the app was uploaded unzipped.
This current app works as expected. I presume this includes a manifest etc that enables asking permissions or some such.
========================
EDIT: all 3 versions work on my M2 MacBook Air. Interestingly, every time I launch a different app, it seems to reset the permissions and I need to grant them again; but once granted, relaunching the same app just works without having to grant permissions again - not sure if that's what you were asking?
On clicking the populate button (once), it brought up the dialog box to ask for permission, it was granted and everything worked as expected.
What happened with the stack previously was that it did not ask for permission - I only tested the stack because the previous app you released had the same issue as the the one I reported, causing issues because the app was uploaded unzipped.
This current app works as expected. I presume this includes a manifest etc that enables asking permissions or some such.
========================
EDIT: all 3 versions work on my M2 MacBook Air. Interestingly, every time I launch a different app, it seems to reset the permissions and I need to grant them again; but once granted, relaunching the same app just works without having to grant permissions again - not sure if that's what you were asking?