I’m using Xojo 2016r1.1 on macOS Sierra, and for years now I’ve had a .plist that gets copied into my project when it’s built. This worked great until earlier this week, when I found that Xojo was setting the Document type info Role to “None” for every document type, including ones that are defined as “Exported” in the project’s FileType sets. In my plist, I set the Role to “Editor”.
So clearly, Xojo is replacing my .plist with its own despite the file copy step. I know from a previous discussion on this that what I should do is make a .plist with just items for Xojo to merge into the one it builds and placing it into the project, replacing the build’s copy files step. I tried this just now, including only the document type names and their roles, but Xojo is still replacing all of the Role entries with None. This means double-clicking any of my app’s data files fails to launch the app.
The only solution I can see for now is to manually copy my .plist into the built app before I sign it.
John, they added an extra step for Mac files when they fixed some stuff regarding UTI assignment.
Double check that you’ve set up your file definitions correctly in both places, I made a video to show you where the second location is: https://dl.dropboxusercontent.com/u/10504478/MacFileTypesExtraStep.mp4
Tim, you win! I don’t know how those all got changed, apparently something happened to my project file between last week and this. Thank you for getting me back to work so quickly!
[quote=309653:@Tim Parnell]John, they added an extra step for Mac files when they fixed some stuff regarding UTI assignment.
Double check that you’ve set up your file definitions correctly in both places, I made a video to show you where the second location is: https://dl.dropboxusercontent.com/u/10504478/MacFileTypesExtraStep.mp4[/quote]
That has existed since … well … forever
In 2010r4.1 you click on APP and edit the AcceptFileTypes property in the inspector
And its been present since at least then
IF your copy file step is AFTER the “Build” item there’s no way the IDE is replacing it, the step copies in yours, then the IDE replaces it again.
Steps AFTER the build item in the build step list are literally “AFTER” the ide is done compiling your project
The only thing that the IDE might do after everything is create the tar file when it needs to
Now its possible the copy is failing to copy yours in so you’re left with the one the IDE generated
As it happens, the build step was after the Build item (Build was first on the list), but it’s possible that the copy was failing.
I do have a RunIDEScriptStep that sets high resolution YES and additional CopyFiles steps for various resources and helper apps, all of those are working fine.
Easy way to test is to put something distinctive in the plist that is NOT there by default
And the nice thing is you can stick pretty much whatever keys in there you want without penalty
@Tim Parnell I’m using 2016r1.1, I need to support HiDPI on just Mac, as Windows support for it isn’t available in 2016r1.1, hence the special step for Mac instead of using the built-in option. Hoping that 2017r1 clears up the Windows printing issues, if so then I’ll switch to it and do HiDPI on both platforms.