So with the release of my app around the corner I’ve come to share some of the modules I created in the process.
Maybe you’ll find one you like All free, no strings attached. More details and downloads are here: http://timi.me/xojo.html
TPUpdates - Drop in update checker.
TPSF (TPSpecialFolders) - SpecialFolder doesn’t have anything neat like SpecialFolder.Resources or SpecialFolder.Frameworks - this fixes that.
TPBetaDater - Expiring builds. Drop in, set expiration, call it during App.Open
[quote=125535:@Tim Parnell]So with the release of my app around the corner I’ve come to share some of the modules I created in the process.
Maybe you’ll find one you like All free, no strings attached. More details and downloads are here: http://timi.me/xojo.html
TPUpdates - Drop in update checker.
TPSF (TPSpecialFolders) - SpecialFolder doesn’t have anything neat like SpecialFolder.Resources or SpecialFolder.Frameworks - this fixes that.
TPBetaDater - Expiring builds. Drop in, set expiration, call it during App.Open
[quote=125535:@Tim Parnell]So with the release of my app around the corner I’ve come to share some of the modules I created in the process.
Maybe you’ll find one you like All free, no strings attached. More details and downloads are here: http://timi.me/xojo.html
TPUpdates - Drop in update checker.
TPSF (TPSpecialFolders) - SpecialFolder doesn’t have anything neat like SpecialFolder.Resources or SpecialFolder.Frameworks - this fixes that.
TPBetaDater - Expiring builds. Drop in, set expiration, call it during App.Open[/quote]
Just wanted to let you all know these have been updated!
Thanks to Sam, TPSF (which now I kind of feel bad about sticking TP on…) features more future-resistant Cocoa declares. I didn’t add the plugins thing because I’m not sure what the plugins folder is in relation to Xojo (so I would have no way of testing it!) I’ll be happy to add it though if you guys think I made the wrong choice
I’ve also updated TPUpdates! It’s now more robust, and features a new logic method (instead of just is cdbl1 > cdbl2) where it supports Major.Minor.Revision.Patch numbering or any variation you can come up with. Everything Revision and on is combined into a double value, so that Version 1.0.1 comes out as newer than version 1.0.0.2
The only use I’ve come across for the plugins folder was custom Core Image filters… However these can also be crated dynamically in code, so I’m fine without it
[quote=125535:@Tim Parnell]So with the release of my app around the corner I’ve come to share some of the modules I created in the process.
Maybe you’ll find one you like All free, no strings attached. More details and downloads are here: http://timi.me/xojo.html.
TPSF (TPSpecialFolders) - SpecialFolder doesn’t have anything neat like SpecialFolder.Resources or SpecialFolder.Frameworks - this fixes that.
Enjoy![/quote]
Not a big deal and this method is meant to be used on Mac, but in the Resources method, this is wrong :
#elseif TargetWin32 then
return App.ExecutableFile.Parent.Child("Resources")
#endif
[quote=129691:@Michel Bujardet]Not a big deal and this method is meant to be used on Mac, but in the Resources method, this is wrong :
#elseif TargetWin32 then
return App.ExecutableFile.Parent.Child("Resources")
#endif
There is no Resources folder in Windows.[/quote]
There can be. If you have dynamic constants for localization, they end up in the Resources folder. It’s also a target for CopyFileSteps.
The Resources folder is where I stick my stock database, that both the Mac and Windows gets and copies to the correct locations in SpecialFolder.ApplicationData… if it detects it is missing this when the program first starts. This is always on the first run and then again if the database file somehow disappeared if a user messed with the folder structure for some unknown reason.
I assumed this was OK to do on Windows as well from what I had read on the forums. I realize I could copy the file to the correct location with the Windows installer I use, but seemed just as easy, made it self-repairing, and made the code consistent with the Mac version if I just used the Resources folder in the code.
If this is not good to do on Windows, I’d like to know. Seemed like it was OK to use from what I have read here over the years.
[quote=129741:@Merv Pate]The Resources folder is where I stick my stock database, that both the Mac and Windows gets and copies to the correct locations in SpecialFolder.ApplicationData… if it detects it is missing this when the program first starts. This is always on the first run and then again if the database file somehow disappeared if a user messed with the folder structure for some unknown reason.
I assumed this was OK to do on Windows as well from what I had read on the forums. I realize I could copy the file to the correct location with the Windows installer I use, but seemed just as easy, made it self-repairing, and made the code consistent with the Mac version if I just used the Resources folder in the code.
If this is not good to do on Windows, I’d like to know. Seemed like it was OK to use from what I have read here over the years.[/quote]
You can always create a ‘Resources’ folder in Windows next to the executable and use it as such for better cross platform compatibility. My point is that the Resource folder is a component of the Macintosh bundle that has no counterpart in Windows. There is no such thing as a C:\\Program Files (x86)\\Resources or C:\\Program Files\\Resourcesfolder.
The Resources method in TPSF returns a non standard folder under Win32. It would probably be better not to return anything.