Access violation on TOpenDialog.Execute on Mac sandboxed app.

[cobata]

Hello guys,

I am back with a problem dating from 2011-2012, it is reported and in the Delphi community:
http://forum.lazarus.freepascal.org/index.php?topic=16081.0

Is there any improvement here?

The guys suggest to use NSOpenPanel/ NSSavePanel.
To what in ObjC or ObjPas is mapped the LCL TOpenDialog/ TSaveDialog component?
Is there some workaround found here?
Is there some easy replaceable alternative of LCL TOpenDialog/ TSaveDialog component?

I am on El Captain.
I am using this signed app entitlement:
<?xml version="1.0" encoding="utf-8"?>
<plist version="1.0">
  <dict>
    <key>com.apple.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.files.user-selected.read-write</key>
    <true/>
    <key>com.apple.security.documents.user-selected.read-write</key>
    <true/>
    <key>com.apple.security.downloads.user-selected.read-write</key>
    <true/>
  </dict>
</plist>

In the code before the violation and the OpenDialog.Execute, I am setting:
OpenDialog.InitialDir:=GetCurrentDir+'/Downloads/';  // with and without the last '/'
// end show the OpenDialog.InitialDir
ShowMessage(OpenDialog.InitialDir);  // '/Users/user-name/Library/Containers/bundle-id/Data/Downloads/'

Any suggestions, infos... urls are welcome.

Best Regards

[Phil]

In the code before the violation and the OpenDialog.Execute, I am setting:
OpenDialog.InitialDir:=GetCurrentDir+'/Downloads/';  // with and without the last '/'
// end show the OpenDialog.InitialDir
ShowMessage(OpenDialog.InitialDir);  // '/Users/user-name/Library/Containers/bundle-id/Data/Downloads/'

Apple's docs suggest that a sandboxed app's container is not to be used for user files. Perhaps that's related to your problem.

I would suggest that you think through what you're trying to do (and why), then describe it here.

https://developer.apple.com/library/content/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html

[cobata]

Hello Phil,

Thanks for your response.
Actually, it is not the problem. I am just using the code snippet to show where the OS X positions me (by using GetCurrentDir) and add '/Downloads/' in order to use the auto-generated shortcuts (in the app container) buy the software first run. The software is launched from the /Applications dir.

I experimented by using absolute and relative OpenDialog.InitialDir paths to push the TOpenDialog appear opened in some dir, but instead of opening the dialog at all - Access violation is raised. The entitlements signed into do not play any role - just enabling the sandboxing.

But it seems from here: http://forums.realsoftware.com/viewtopic.php?f=7&t=44162 (and from many other places) that the Carbon TOpenDialog/TSaveDialog/TOpenPictureDialog do not use the Powerbox, but the Powerbox is used by the NSOpenPanel and NSSavePanel.

The link contains links to code snippets, which should solve the problem or to suggest solution, but they are dead or are used as marketing tricks, however the discussion is correct - I am observing the same problem

Also, I used this code just to figure out a possible way for solution:
...
var
  v: NSOpenPanel;  { unit AppKit }
begin
  v:=NSOpenPanel.Create;
  v.runModal;
...
and the open dialog (panel) is opening in the desired Documents/ folder

But, I am searching for elegant solution, for example a solution that use TOpen/Save/Picture dialogs, which redirect to Powerbox and this solution is tested and released.

It is not OK when the software is ready for release and when the tests of the signed software have to be just to validate and adjust it by entitlements to start writing modules which inter-operate with the OS specifics.

Any suggesting are welcome!

Best Regards

[felipemdc]

Does it work if you use the LCL Cocoa interface? If yes, they why not compile your app for LCL-Cocoa?

[cobata]

Hello, Felipe,

That is good.
I thought about it, but the only widgetsets, which worked on El Captain where GTK2 and Carbon.
The Carbon is the default (you know) and does not use additional dylibs, for which I have to care about in the case of GTK. I tested my software with the Carbon and adjusted it (it was a lot of tests, I posted a lot of problems here and I solved them).

I have to investigate time to test with Lazarus 1.6.2 (or the latest version) with Cocoa.
I am on Laz 1.4.4. I am on Laz 1.4.4, because I tested it well (even with FPC 3.0.0 - but I found some disturbing issues - I reported here, and felled back to FPC 1.6.4). I am testing Laz 1.6.2 on Windows 10, and my observations are not pointing different expectations from Laz 1.4.4 regarding the widgetsets (it is subjectively off course).

Actually, I want to provide near to equal quality of my software for Win and Mac and a main part of this goal is to use the same Dev Environment (Laz 1.4.4).

When I release the software the maintenance will continue by using the latest Laz, FPC, Mac OS, XCode, Packaging technologies releases.

Best Regards

[Phil]

The Carbon is the default (you know) and does not use additional dylibs

The Cocoa frameworks obviously are standard on all Macs. You won't need any additional .dylibs.

You need to use the Cocoa widgetset, ideally from trunk, if you want to use the NS common dialogs.

[cobata]

Phil,

It is right,

But, you know that but - release, means release, I investigate a lot of time for testing, and then I release. Release, means to work with (subjectively) the most tested and qualitative software, tools, etc.

That is

I think that as default and the only working released (Mac native) widgetset Carbon, with some workarounds (those I am searching for), have to play with Apple App Store. The problem I am wailing for dates since 2012...

Best

[felipemdc]

The Carbon is the default (you know)

It is the default because the default is used for building the IDE, and the Cocoa interface is still inferior for running the IDE, which is a very complex project which uses nearly all LCL functionality.

But being the default is not the same as "being recommended for user apps", I'd say that the Cocoa interface is recommended, unless you hit some kind of limitation that is fixed by switching to the Carbon interface.

and does not use additional dylibs

LCL-Cocoa does not use additional dylibs

I have to investigate time to test with Lazarus 1.6.2 (or the latest version) with Cocoa.

I would use lazarus SVN trunk for Cocoa. Laz 1.4.4 is too old for Cocoa. I'm not sure about 1.6.2 with Cocoa.

[cobata]

It's my tribute to the community:

http://www.COBATA.com/download.php?file=nsdialogs

[cobata]

Update:
- On the latest FPC/ Lazarus (3.0.4/ 1.8.4), on compiling nsdialogs.pas:

 - nsdialogs.pas(83,103) Error: Incompatible type for arg no. 1: Got "CFARRAY.CFArrayRef", expected "MACOSALL.CFArrayRef"

- Fixed by changing the uses clause:
 - from "SysUtils, Classes, AppKit, MacTypes, CFString;"
 - to "SysUtils, Classes, AppKit, MacOSAll;"

- The download is updated (above).