Forum > Carbon
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:
--- Quote from: cobata on February 14, 2017, 01:59:37 pm ---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/'
--- End quote ---
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
Navigation
[0] Message Index
[#] Next page