If you have a post build step that copies resources after building then while you are debugging those resources aren’t available and my app fails.
why not just drag them into the project instead of a post-build step?
would they then be locatable as resources relative to the application?
These are executable files that I shell out to from the App.
Or just use a copy files step that targets the Resources directory. Then you can reference them with SpecialFolder.Resources.
Check that the “Applies to:” field says “Both” to make sure it copies the resources for both debug and release.
Not to start an argument, but for at least my education if not that of others…
But WHY is a build phase copy “better”/“preferred” to just dragging the resource into the project via the IDE?
Doesn’t the resource (image, text, script, database, whatever) end up in exactly the same place, and therefore referenced in exactly the same way?
copying them into the project may cause them to load into memory when you dont want
and once loaded you cannot unload them
resources you can load & unload by reading a picture, for instance, then eventually niling the picture
resources when copied into the app do cause your project to take longer to build because the IDE has to do extra wotk with them
not so when they are in the resources dir
and loading them all into the project can lead to some slowness when you open the project
ask anyone who has resources on drop box etc 
I have some helper apps. These are built in an IDE script and copied into the main app.
You can’t use the copy file script because the helper apps aren’t always there and then you loose them in the script.
Using an IDE script for the file type icons makes saving a project and using the SVN client waayyyyyy faster.
Norman… thanks for the explanation… but I’m still not getting it.
It was my understanding (and perhaps incorrect, but borne out by observation)
If you drag a resource into the IDE, when compiled that resource is copied into the /RESOURCE directory (which can be seen by opening the App package) ,and the App code then can reference it by “name”
If you add a copy script, doesn’t that put the resource in the exact same place? I can (per Beatrix) how it might speed up SVN because the resource isn’t part of the project code.
The only real difference I am seeing is
- drag into IDE, resource is available by “name”, and therefore a static reference is created (it can’t be nil’d), but the resource can also be “loaded” from SpecialFolder.Resources if required.
- copy script, resource must be “loaded” from Specialfolder.resources, and therefore can be nil’d as the reference is now dynamic
For Xojo I always drag resources into the IDE, but then I usually don’t need to dereference the resource.
but for Swift its actually a combination… You can drag the resource into the project which places it in the /Resources directory of the application, but in order to use it, you must “load” it.
You can do whatever one you like.
There are pros and cons to each approach.
If you have large resources that you dont want to retain in memory all the time I would not drag them into the IDE because the first time you use the named reference its loaded and you cannot unload it.
So several hundred large movies or pdf’s suck up memory and there’s nothing you can do.
Plus the amount of code you save is really trivial. Maybe 5 lines ?
For a tiny handful of resources its no big deal.
For thousands or really large ones it is.
[quote=429463:@Norman Palardy]
You can do whatever one you like.
There are pros and cons to each approach.[/quote]
and that is exactly what I have been trying to ascertain
after that line @Norman Palardy explains the Pros/Cons. to sum them up.
dragging items into the app:
pro:
- easy to do
- no coding required
con:
- they are loaded into memory and you cant remove them from memory.
- large items or large number of items will chew up a lot of memory fast.
copy step:
pro:
- can copy any set/subset of files you want to whereever you want. you have full control.
- doesnt autoload the files into memory, taking up RAM.
- more control over what the app uses or doesnt use.
cons:
- have to load the items yourself.
- few lines of code.
I can be wrong but that is the impression I got from the thread plus my experiences. aka not an expert.
And @scott boss with the name drop! 
Another pro-CopyFiles for me personally is that the project is cleaner. Less items to clutter up auto-complete and the navigator.
Both the mentioned solution will slow down the debugging process because they lead to extra file copy operations.
Why not do this instead:
Assuming you usually copy your resource files into a specific directory, you’d have a property that gets set to that folder in App.Open.
However, when you are debugging, set it to the folder where the original resides, like this:
#if DebugBuild
f = GetFolderItem("App Resources")
#else
f = app.ExecutableFile.Parent.Parent // "Contents" folder
f = f.Child("Resources")
#endif
App.ResourcesFolder = f
And then you use that App.ResourcesFolder whenever you want to access your resources folder.
I manage one project that does just that and it’s a nightmare to maintain. Out of the three approaches, that would be the last one I choose.
Some problems I’ve personally run into with that approach:
- Case sensitive file systems causing problems
- Cross machine source maintenance
- Translocation issues (client puts media in the folder after it’s built)
But that’s just my personal experience, you may find you like that approach.
[quote=429472:@Thomas Tempelmann]Both the mentioned solution will slow down the debugging process because they lead to extra file copy operations.
Why not do this instead[/quote]
You still need to copy them into your app resources when you build to finally deploy so it only saves you a bit of time at the point you debug
Even with something as huge as the IDE + all its images I never found that to be a significant hold up
YMMV
I’m thinking that
Dim file As FolderItem = SpecialFolder.GetResource("MyDb.sqlite")Should isolate coders from the intricacies of locating resource no matter how they are ‘managed’.
Still not getting the difference, but Im sure it lies in this sentence.
Drag a large image into the app… it gets loaded and cannot be unloaded
But drag a large image into the resources , and it…
A/ -doesn’t get loaded until needed? (Is that a delay waiting to happen?)
B/ -can be unloaded (How???)
say its a picture and you have opened with picture.open
as long as you nil all references when the last one is set nil the picture is release from memory
Would you be seeing that under Windows ?
Debug resides in a different subfolder than a normal build.
How are you accessing the resources ?