Disallow Permission result in a Crash…

At a point in my project, I read a Service text file and Big Sur (m1) ask me for permission.

Of course, I denied and get a crash (Ne pas autoriser) at:

Title_List_TIS = TextInputStream.Open(Title_List_FI)

IOException 1

The code is located in a PopupMenu and it takes text from a file to populate the PopupMenu.

The LR says nothing about how to trap that error condition (what an idea to deny the permission… But it is something an user is capable of)

OK: bad day. I’d better do something different

Trap the exception using Try Catch.

1 Like
Try
  Title_List_TIS = TextInputStream.Open(Title_List_FI)
  /// --- Do stuff with title_list_TIS

Catch err as IOException
  // --- Read error code and display message.
  //     1 = "Operation Not Permitted", permissions error.
End Try
1 Like

Yes, Try/Catch is the way here. You may need to experiment a bit to find exactly which statement provokes the OS to issue the pop-up to the user. In my case, I had made a FolderItem for the Documents folder, created another folder inside it, checked that this new folder was readable and writeable, and it was then when I wanted to open a logfile there that I needed the Try/Catch:


try  // Here we see whether the user allowed access to these files
  op = TextOutputStream.Open (fptr)
catch
  msg = "Unable to create or access data files" // Big Sur and later
  quitDialog (msg)  // Here, quit with a message to the user.
end try

I must add that Error 1: Might be incorrect permissions or macOS Security interfering. I’m going to try to find an easy way to determine this. So that when we tell the customer they can either correct the permissions or update the macOS security.

IOException and 1 were in the Debugger.

I realized that after sending the question (and ben home).

Then, I implemented your suggestion and the crash still occured (running in the IDE)…
I checked and found the code right now.

Remember: users do crazy things. In the current months, they will click in Dismiss (a part of them been afraid to accept).

Here’s the relevant code with the crash line…

Big Sur 11.5.1 / Xojo 2021r2

If they did deny the permissions, what does your app do next? Mine quits.

The debugger is going to stop there, it’s up to you to hit Run to go into the Catch. You can turn off Break on Exceptions in the Project menu of the IDE, or surround your code in the following:

#Pragma BreakOnExceptions Off
Try
  // your code
Catch e As NilObjectException
  // handle exception
End Try
#Pragma BreakOnExceptions Default // Restore setting from Project menu

Look at the debugger screen shot. No application generated here.

Hi Anthony,

thank you for resolving the case.

Now, the only need is to share the solution into the LR (TextInputStream, etc. if needed).

Have a nice day.

But you are running an application. What do you expect it to do if the user refuses permission?

1 Like

The file will not be read.

Not my choice, user choice.

Are-you running Big Sur ?

So what will your application do if it is denied access to that file?

In this case, the file holds data that is used to populate a PopupMenu with default names.

When the user refuse the permissions, the PopupMenu stays empty, the user can type text into a TextField.

The user can also quit the application, run it a second time and then accept to give the permission.

Remember: this is from Big Sur new security. I totally dislike that, but no one ask my advice nor my permission :wink:

Read back my code screenshot above: I tell the user what happens (the sentence can be improved for real users instead of me) and why. I will add something about re-run the application and give permission.

Simple example:

I’m trying to write a generic IOException handler, for this problem, this is what I have so far.

When the customer clicks on "Open “System Preferences” I call showURL with the following link.

x-apple.systempreferences:com.apple.preference.security?Privacy_DocumentsFolder

I was unaware of the “Default” option in pragmas :thinking:
Even though I’m using Xojo since it was RealBasic, there are a lot of things that goes unnoticed from releases to releases; this isn’t the first time.

What surprised me was:



    #Pragma BreakOnExceptions ON
    #Pragma BreakOnExceptions Default

I was more thinking of ON / OFF. I checked on the LR and found:
True, False, and Default here:

https://documentation.xojo.com/api/language/pragma_directives.html

But if that works, why complaining.

Nota: I use REALbasic since before 1.0, and I sure forget many things from RN.