LiveCode Forums.

I am hoping for some help on a pretty obscure problem. I have some code in a new-ish program (macOS) that (in part) allows the user to drag and drop lines of text in a list field.

The code is:
When the standalone is built, stapled and notarised and I run it, the first time it encounters this line the Mac up and asks "This program wants access to your camera. Do you allow?" (I am paraphrasing). The options are yes and deny. If I deny the program still works fine, the Mac never asks again, and the drag and drop with "image" works great.

If I say yes then something wacky happens to the drag and drop code and it forgets how to "let go" of the image. If you close and reopen the app all is ok again, but this looks spectacularly unprofessional.

Thoughts on potential workarounds? I could work up an example if that would be helpful. Obviously if I just build as a standalone the problem does not occur. It's just following the "installation" of a new (as far as Apple is concerned) app (and then only the first time this line is encountered).

I hope I have explained that accurately. (My ideal solution would be to never have the user presented with this dialog because based on the Deny response there is no loss of functionality in that situation anyway).

Cheers,
Mark

@marksmithhfx: If possible, could you file a bug report with sample stack showing this behavior? Something doesn't sound quite right here as taking a snapshot of the screen shouldn't require *camera* access (if user permission is required - then it should be more specific - although this does sound like an OS thing!).

However, I suspect the reason it is triggering is because you are using the 'screen' variant of export snapshot - this copies pixels directly from the current image displayed on the screen. If you use the object variant of export snapshot, then I suspect the problem will go away: Notice that exporting a snapshot of a rect from an object uses card-local co-ordinates - you can also export snapshot from a control directly - in which case *just* that control is rendered (snapshotting a card will render all objects intersecting the rect you specify).

LCMark wrote: ↑

Thu Jun 30, 2022 6:56 am

Notice that exporting a snapshot of a rect from an object uses card-local co-ordinates - you can also export snapshot from a control directly - in which case *just* that control is rendered (snapshotting a card will render all objects intersecting the rect you specify).

Thanks Mark,

All this talk of snapshot had me thinking camera but in fact, when I rebuilt it again (you have to change the name and rebuild for the alert to popup) I grabbed a screen shot and it was for "recording the screen", which, I presume is something different but had me in my haste thinking camera. I've attached the prompt.

Also, the context of the line and the way the image gets built will be more meaningful to you than to me. I feel fortunate I just happened to find it here on the forums (originally attributed to Scott Rossi) and it did most of what I was looking for. There was however, this one little problem with the OS alert and then another problem I found only today which was, if you drag the dragimage off the field and release the mouse the drag image does not disappear because the the mouse up message (I presume) does not go to the field? Or something like that. Anyway, once dragged off the card it stays attached to the mouse and then I believe at that point I was forced to quit and restart LiveCode to get rid of it. Even sometimes when I restarted LiveCode when I moved the mouse over the field again the drag image reappeared. Very messy. Anyway, I wanted to clean that up before sending along a sample stack. I did find a solution (very oddly, your immediate reaction when the image does not disappear up is to click the mouse button again. I added a mouseUp handler on the card and when that was triggered I deleted the drag image). This apparently cleaned up a lot of other problems. The whole operation is now significantly more robust. It seems the fact that the drag image was not "disappearing" when it should was creating ongoing problems.

The code for building the drag image:
Other oddities include (a) if you select Deny on OS alert it still functions normally. (b) If you select the "Open System Preferences" option and enable it, then later disable it, it also has no effect. ie. the prompt does not reappear and drag and drop continues to work normally. Happy to upload this to the QCC if it would be helpful to look at. Let me know.

Thanks btw, it did send me in a very useful direction in terms of resolving some issues.

Mark

LCMark wrote: ↑

Thu Jun 30, 2022 6:56 am

However, I suspect the reason it is triggering is because you are using the 'screen' variant of export snapshot - this copies pixels directly from the current image displayed on the screen. If you use the object variant of export snapshot, then I suspect the problem will go away:

Code: Select all

export snapshot from rect <local-rect> of this card to draggerData as PNG

Notice that exporting a snapshot of a rect from an object uses card-local co-ordinates - you can also export snapshot from a control directly - in which case *just* that control is rendered (snapshotting a card will render all objects intersecting the rect you specify).

Thanks Mark. When I changed the screen coordinates from global to local and added "of this card" the permission dialog for "recording screen" no longer appeared. Dead accurate as usual

After fooling around with it for a bit I realised the screen coordinates were originally recorded "locally" and then converted to global coordinates. So all I needed to do was remove the section titled "convert from screen to window coordinates - using globalLoc" and it worked fine, and did not invoke the macOS permissions dialog. I'll go add a note to that effect where the original message was posted.

Cheers and thanks,
Mark