OK, thanks for clarifying.
If you use a copy file step to build a windows exe it has to put those items somewhere
And so yes you can end up with a Resources folder on Windows
[quote=129811:@Norman Palardy]If you use a copy file step to build a windows exe it has to put those items somewhere
And so yes you can end up with a Resources folder on Windows[/quote]
I am sorry, I do not understand.
Go to your install of the IDE and Feedback on Windows.
Note the directories installed.
Both have a resources dir next to the exe.
And it’s easy to create an app that, when deployed to Windows, has a Resources dir.
Localized string files will be there too.
And the built app will expect it to be present.
The modules location for “Resources” on Windows IS 100% correct from a Xojo app perspective.
[quote=129814:@Norman Palardy]Go to your install of the IDE and Feedback on Windows.
Note the directories installed.
Both have a resources dir next to the exe.
And it’s easy to create an app that, when deployed to Windows, has a Resources dir.
Localized string files will be there too.
And the built app will expect it to be present.
The modules location for “Resources” on Windows IS 100% correct from a Xojo app perspective.[/quote]
OK. I was talking about the default “out of the box” app, which comes with only the Lib folder, unlike a Mac bundle where the Resources folder is always there.
Of course, it is easy to add a Resources folder. But since it is not there automatically, it would seem necessary to test it is present before returning a path.
My point is it IS there automatically under a number of circumstances.
Just make your app have dynamic string constants and voila !
Or use a copy file step
There are many circumstances that will result in the resources folder being present.
And the path to it is correct as far as the module is concerned and as far a a Xojo app is concerned.
Now you could argue that the module should on Windows test it before returning the folderitem
But thats a different function than the what the module currently implements which is “where is the resources folder”
Not “does it exist”
TPSF has been updated!
You can now quickly get your bundle identifier on Mac (App.BundleIdentifier as string)
Also, now you can reliably access your application support folder (TPSF.AppSupport as FolderItem) which returns a child of SpecialFolder.ApplicationData that on Mac is your bundle identifier, and on windows is your app name. One function, cross platform easy.
Big thanks to @Sam Rowlands for these two features ( cross platform on AppSupport was me 
)
tl;dr
TPSF now includes App.BundleIdentifier and TPSF.AppSupport for direct access to your own ApplicationData folder.
I just recommended TPSF for a Mac user, but as I know you also support PC folders, you may want to update the resource folders based on the current 2015R3.1 naming conventions.
See https://forum.xojo.com/27698-accessing-resources-folder/last
TPSF has been updated for the recent changes to the naming of the Resources folder.
This change affects Windows only. It is backwards compatible for older Xojo IDEs, and will look for plain old “Resources” first. If it is not found TPSF will return “[MyGreatApp] Resources.” Please remember to double check that the FolderItem TPSF returns exists prior to using the FolderItem!
Hello Tim, when I saw the post’s title with the [Updated 12/17] I read it as December 2017 but I guess is December 17, 2015.
Do you have new links?
Thank you.
Sorry, I’ve updated the title to be more clear!
I have moved all my projects to github, and that’s where TPSF lives now.
Tim you don’t have to apologize, the title was correct, it was my fault that I didn’t see that the last post was 12/17/2015.
Thank you for the current links.
I don’t know if there are other posts with old links, maybe you can put a redirect on your webpage to your GitHub page.