LiveCode Forums.

After a restart:
- -
executing at 8:54:26 PM
LCB Error -[EKEvent allDay]: unrecognized selector sent to instance 0x7fb68e4aa700
Object GetEventsArray
LCB File ReadCalendarEvents.lcb
LCB Line 612

Interesting and confusing in equal measure.

All the elements of an Event from the EventKit have to be converted to text and it looks like this may be failing. The line referenced calls a routine that converts a C-Boolean to a string. This could be the reason why the compiled application fails although I have no idea why the access status is not being read correctly on Ventura.

Thanks again.

Simon

Must be cold in Lindsey . . .

I have no idea why the access status is not being read correctly on Ventura.

Obviously, between macOS 12 and macOS 13 there have been more changes than meet the eye.

The stack does state that access has been authorised now:
- -
The problem seems to come about later on in your LiveCode Builder file:

executing at 9:42:44 PM
LCB Error -[EKEvent allDay]: unrecognized selector sent to instance 0x7fa8d1a62310
Object GetEventsArray
LCB File ReadCalendarEvents.lcb
LCB Line 612

Must be cold in Lindsey . . .

Yes it is, although West Lindsey is on the other side of the River Trent from home. Our council is North Lincolnshire but we live in the Isle of Axholme. Its a few degrees warmer than the past few days but we now have a wind which is making the house feel cooler.

Returning to the Calendar I need to find a more modern computer to conduct some tests on. I'm wondering if Apple have changed the default settings of an event and now leave boolean values as undefined/nil whereas in Big Sur they defaulted to false. Should be a simple fix.

Think I may go back to using a filofax!

Simon

In macOS Ventura 13, the EventKit framework has seen significant changes. This document highlights some of the notable changes.

The above from the Apple developer site.

Great

Think I may go back to using a filofax!

The filofax passed me by. I use lots of odd scraps of paper
that keep getting lost.

In macOS Ventura 13, the EventKit framework has seen significant changes. This document highlights some of the notable changes.
The above from the Apple developer site.

Great

Bloody marvellous, as you'll now have to write 2 variants: one for 'Big Slur' and one for 'Ace Ventura', and, no doubt another one
for 'Cannery Row' or whatever it is called when it comes down the pike in about 9 months time.

Bloody marvellous, as you'll now have to write 2 variants: one for 'Big Slur' and one for 'Ace Ventura'

Isn't it just!

Also note how Apple only mention significant changes.

I think I will have to harden all the calls so that they deal with a nil/nothing object.

Perhaps tomorrow.

S

Over here, in Bulgaria, I am 2 hours ahead of you and off to bed.

But will be back from work at about 6 pm your time tomorrow and perfectly happy to try out you next version

Thanks, I'll take you up on your offer. It will probably be late morning as I have a doctors appointment first thing.

Good night,

Simon

I tried downloading the latest version... but it's a stack, not an app; when I run it, it does not ask me to give permission (I had revoked permissions when I stopped testing the first version).

I re-ran the first version and again it asked me for permission for access to calendar (only), granted and confirmed granted.
On running the 'new' stack, it still insists permissions are denied.
Screenshot below shows the log and the permissions: Not sure how to proceed from here - would it help if I built the stack into a standalone?

I tried downloading the latest version... but it's a stack, not an app; when I run it, it does not ask me to give permission (I had revoked permissions when I stopped testing the first version).

Hi Stam,

Trying to understand how permissions work is a bit of a challenge with Apple making access to resources ever more complicated. I only have a limited understanding and the documentation only goes so far.

Initial requests for permission may only be made via a call to a system Objective-C or Swift method; on recent versions of MacOS the end user is unable to grant permission by adding applications to their privacy pane. Also for the call to succeed two entries have to be made in the built applications plist file.

Also or perhaps an "entitlements" file has to be included in the final build. My initial test application did not include such a file.

I should add that my library and application runs here on Big Sur and Monterey but is failing when run on Ventura.

When developing an application in Livecode it can get confusing as a stack being run from the IDE will use the permissions granted to Livecode. This means that it is not possible to test the applications own "request for permission mechanism" from within the IDE; all such tests have to be conducted with built applications.

I included the stack file because Richmond has discovered a flaw in my library when run on Ventura. The hope was that running it from the IDE might shed more light on what is going wrong as it seems that Apple has made significant changes to how the EventKit works but has not really published a full list of these changes. Richmond was able to identify a line number in the library that is reported as the fault line. However, I don't really see any problems unless apple has changed how unset Boolean values are being returned.

Its worth pointing out that to run the stack from the IDE it is also necessary to install the Library file, uninstalling any earlier versions should they be present.

I have made a change and looked over my code and am ready to rebuild the application and run some more tests.

What version of OS are you testing on ?

best wishes and thanks
Simon

Hi Simon - I should have clarified that I installed the LCB library as this being a stack (rather than standalone) it was obviously not included.

I’m on the latest version of MacOS Ventura (on an M2 MacBook Air).

Running the stack and clicking the button to get events does not prompt the “give permission” dialog.

Hence I used the previous version of the built app to do so (and that works).
But the stack still reports permission denied.

S.

Ventura is causing issues especially as I don't have a machine capable of running it.

I have made some changes to the library and perhaps discovered a bug in the Eventkit or Big Sur's Calendar Application : all events return true when checked if they have an alarm set. Older entries i.e. those made five years ago do correctly report true/false. This may be significant as Richmond's test failed on a line attempting to convert a cBool to text, true or false.

Updated test application that uses the updated library and includes an entitlements file may be downloaded from https://www.dropbox.com/s/wu62ttnnqmkg6 ... p.zip?dl=0


Updated Library Changed so that it should be protected from a Null boolean object which may have been an issue - a guess!

Updated Test Application Changed to use the updated library. Reports the library and OS version in the log field.

Simon

Hmmm

You built app fails and MacOS refuses to run it at all. Did you build for 64 bit and include ARM?
I tried the 'manual' method: I installed the updated library and then ran the stack (having restarted LC, to be on the safe side).
It still insists I have denied access, even though I can clearly see in my security preferences that the app Test_os_Eventkit has been granted access (admittedly this probably doesn't apply to the stack, but I am not prompted to do this and can see no way of manually adding access).

The log:

ProductName: macOS, ProductVersion: 13.0.1, BuildVersion: 22A400
Using version 1.1.53 of Calendar Library
Calling CalCheckCalendarAuth
tAuthStatus is set to : NotDetermined
Access is NotDetermined, calling CalRequestAuthorization()
EventKitRequestPermissionsCallBack fires!!!!

S.

On an INTEL Mac Mini there is a similar problem:
-