I’m a little bit confused since Xojo 2015.2 windows builds have a resource folder. My questions are:
What happens if I have more then one EXE file in that folder? Because the folder name is always the same, do I have to merge the content of both exe files in one resource folder?
There are some tips in the xojo blog to use virtual volumes instead of the resource folder to hide the content. Are there some example project that show this solution?
For some reasons the “resource folder” solution looks not very well-conceived. Why not making this process easier with a build option (build dialog)?
Now I have to work on my existing projects or go back to 2015.1.
[quote=183323:@Claudius Warzecha]I’m a little bit confused since Xojo 2015.2 windows builds have a resource folder. My questions are:
What happens if I have more then one EXE file in that folder? Because the folder name is always the same, do I have to merge the content of both exe files in one resource folder?
There are some tips in the xojo blog to use virtual volumes instead of the resource folder to hide the content. Are there some example project that show this solution?
For some reasons the “resource folder” solution looks not very well-conceived. Why not making this process easier with a build option (build dialog)?
Now I have to work on my existing projects or go back to 2015.1.[/quote]
if you have two exe in the same folder, make sure to rename the “myapp Libs” to “libs” if both EXE are complied with the same version of Xojo. For resources, yes, both EXE will look into the same Resources folder.
If you want to hide things inside the code as before, you can use a constant containing an encodeBase4 version of the file or picture you need in a constant.
Finally, as a cross platform developer, I think having a Resources folder is a good idea for consistency. In Mac OS X, the resources folder is inside the bundle, but it exists as well, so it is nice to be able to find the files there. Note that in the past, you could always have a Resources folder made, to host your files and stuff, instead of having a mess of files in the application folder. It is also much cleaner to deal with for the installer, IMHO.
A good FR: <https://xojo.com/issue/39116>
This would allow “Appname Resources” just like “Appname Libs”
[quote=183369:@Michael Diehr]A good FR: <https://xojo.com/issue/39116>
This would allow “Appname Resources” just like “Appname Libs”[/quote]
Actually, I am not so sure that would be a good idea. In a Mac OS X app, Resources is always Resources no matter the number of Unix executables within the bundle. If one uses TPS to find the path to Resources, “myApp Libs” will never be found.
The true analogy between Mac OS X and Windows in regards to executable folder is not between Windows exe and Mac OS X .app, but between .exe and Unix executable within the bundle. Then you got to consider the folder in which the .exe resides like a Windows form or app bundle. And having one Resources folder only makes sense.
There is no perfect solution, but I believe it is more in the spirit of cross platform, which is Xojo’s strong point, to have consistency between platforms, so if one day we have SpecialFolder.Resources ( <https://xojo.com/issue/6306> since 2009), it will be consistent as well.
[quote=183385:@Michel Bujardet]Actually, I am not so sure that would be a good idea. In a Mac OS X app, Resources is always Resources no matter the number of Unix executables within the bundle. If one uses TPS to find the path to Resources, “myApp Libs” will never be found.
The true analogy between Mac OS X and Windows in regards to executable folder is not between Windows exe and Mac OS X .app, but between .exe and Unix executable within the bundle. Then you got to consider the folder in which the .exe resides like a Windows form or app bundle. And having one Resources folder only makes sense.
There is no perfect solution, but I believe it is more in the spirit of cross platform, which is Xojo’s strong point, to have consistency between platforms, so if one day we have SpecialFolder.Resources ( <https://xojo.com/issue/6306> since 2009), it will be consistent as well.[/quote]
You can’t compare OS X bundles with Windows folders. The fact they share a similar structure for Resources, etc. is something you can’t explain to users.
On OS X a user see an application, while on Windows a folder.
Many OS X user doesn’t even know the application is (truly) a folder and never thought to navigate into it.
That said, It could make sense to have a single library folder for a group of applications and a Resource folder as well.
BUT, what happens having two applications using a picture with the same name but different content? Clearly the folder should be separated (or separable).
[quote=183408:@Massimo Valle]You can’t compare OS X bundles with Windows folders. The fact they share a similar structure for Resources, etc. is something you can’t explain to users.
On OS X a user see an application, while on Windows a folder.
Many OS X user doesn’t even know the application is (truly) a folder and never thought to navigate into it.
That said, It could make sense to have a single library folder for a group of applications and a Resource folder as well.
BUT, what happens having two applications using a picture with the same name but different content? Clearly the folder should be separated (or separable).[/quote]
Indeed a user does not have to know what the structure of the bundle is. But it is not because Apple guised it into an app that its executable folder is any different than an EXE and the Lib folder, Resources folder, etc. I talked about consistency between platforms and not users. The issue with the same picture file name is one of bad management, pretty much like using all the time the same pet property or variable, until a nasty bug ensues. It is rather easy to make sure there is no conflict, if a developer absolutely has to shove several EXE in the same folder. BTW placing several EXE in the same folder is not terribly elegant anyway. Even on Mac for helpers, they are not supposed to reside in the same subfolder as the app Unix executable.
But weel. On Windows anything goes. Who am I to object ?
We already have target-specific build properties.
Should be simple enough to have ‘Resource Folder Name’ as a Windows build property.
That could default to ‘Resources’ (if you want 2 apps in the same folder to share), and be amendable to
‘Banana’ or
‘Please dont look in here because these are my resources’
if you don’t.
Michel, I think you misunderstand: That’s a windows-only feature request. Nothing to do with OS X builds.
I am just noting that since the Resource folder now exists in both environments, having the same name is interesting for developers who have products in both Mac OS X and Windows. No more.
TPSF can be updated to find the proper folder the way Libs does should Xojo allow for MyApp Resources in the future 
Yeah - exposing all internal pictures and other resources in a project was not the brightest of ideas…
It’s been that way on Mac for more than 10 years. In a similar way that the Resources folder is hidden inside an app bundle on Mac, Windows users hardly ever explore an app’s install folder - most simply use the installer/uninstaller. Separating the resources from the executable allows for some advancements, and I believe I read it’s the preferred way from Microsoft.
Besides, if you’re more concerned users are going to steal artwork from your app than the app itself you have an entirely different problem.