I’m trying to write some software to help me manage my library of medical images (DICOM files). DICOM files are painfully complex. I’ve tried to write my own parsing library in Xojo without great success but I’ve found an open source collection of Terminal/Command Line binaries (dcmtk) that are able to get information out of DICOM files and convert them into JPEG files for display. I’d like to somehow bundle these into my app rather than insist on a user installing them into their system. Is this possible? If so, where should I copy the binaries to and what’s the best/safest way to call them from my app? Presumably if possible to include them with my app I could run them using the Shell class?
You can do it.
for example
add build step - copy and drop your file to the window
set Destination to ‘Resources Folder’
in OSX the Path is
dim myfile as FolderItem = app.ExecutableFile.Parent.Parent.Parent.Child _
(“Contents”).Child(“Resources”).Child(“yourcommandlinebinary”)
in Windows it could be
dim myfile as FolderItem = app.ExecutableFile.Parent.Child(“Resources”).Child(“yourcommandlinebinary”)
you can use the path in shell (myfile.ShellPath)
Sounds like you & Brian O’Brien should collaborate non “libDICOM” for xojo 
Are you intending to release this via the Mac App Store?
Tell me about it. It’s been an on-again-off-again love affair for too long…
You’re gonna tell me that it will violate sandboxing rules correct? I know but writing a native DICOM library in Xojo has proven too big a task for the project I need. It’s not that Xojo can’t be used to write a DICOM parser it’s just that the DICOM standard is the most convoluted pile of c**p I’ve come across and I’d rather cheat and use an existing implementation with Xojo as the UI.
Not in the way that you think; you won’t be able to use a Shell class, you’ll need to use NSTask to execute the console application, and you’ll need to sandbox the console application with the correct entitlements.
However I have found that some console applications do not like being Sandboxed at all; not sure why at this point. So you may need to move the file to a temporary location if it fails.
[quote=215976:@Axel Schneider]dim myfile as FolderItem = app.ExecutableFile.Parent.Parent.Parent.Child _
(“Contents”).Child(“Resources”).Child(“yourcommandlinebinary”)[/quote]
This won’t fly; you’re no longer allowed to include executable code in the “Resources” folder; it will need to be in the “MacOS”, “Frameworks” or “Helpers” sub folder of the “Contents” folder. Code signing will fail and Apple’s check once you’ve uploaded will reject it.
The usual suspects will help you with NSTask, MBS, MacOSLib (I think) and my own “Sandbox Kit”. As for Code signing and Sandboxing it correctly, use App Wrapper as I know that works.
I already used the Shell class (read: without NSTask) and sandboxed it succesfully. But as you say, for some reason not all console application will work.
Did you Sandbox the console app? Once a console application is Sandboxed it cannot be called via standard Xojo Shell, fails with error code -4 (IIRC).
It’s my understanding that for the Mac App Store, all executable code must be Sandboxed.
Didn’t know the console app also should be sandboxed. 
I only did tests with unix apps like mkiso etc… those are definitly not sandboxed and work fine when using the Shell class.
Don’t forget to check the EULA of the third-party tool(s) to make sure your doing so wouldn’t be a violation…
Just for reference; I recently encountered a third party console app that really didn’t appreciate being Sandboxed. I had to include it in the MacOS folder (or it would crash).
Any files I wanted to process with it, had to be moved to the temporary folder. Even though it was Sandboxed with inherited entitlements, for some reason it was unable to open any files (except from the temp folder) that the main application could open.