I discovered that calling SpecialFolder.GetResource on Windows CRASHES on the second attempt, giving a Windows Access Violation exception.
In the example below both files are correctly copied into the resources folder via a CopyFiles build step. And either file can be located correctly if it’s tried first. But the second attempt will always crash regardless of which file is tried first vs second. So the issue isn’t related to the particular files. FWIW The ShellPath to the first file seems a bit wonky, the last character is missing. However the NativePath and the AbsolutePath seem correct. So something may be corrupted from the first GetResource call resulting in a crash on the second call.
The workaround I found is to use the Parent folderitem from the first call to directly create my own reference to the second file.
[code]dim CityFile, ISPFile as FolderItem
Try
// The second call to SpecialFolder.GetResource crashes on Win7, both 32 and 64 bit Xojo builds
’ CityFile = GetFolderItem (Xojo.IO.SpecialFolder.GetResource(“GeoLite2-City.mmdb”).Path, FolderItem.PathTypeNative)
’ ISPFile = GetFolderItem (Xojo.IO.SpecialFolder.GetResource(“GeoIP2-ISP.mmdb”).Path, FolderItem.PathTypeNative)
// This code works OK
CityFile = GetFolderItem (Xojo.IO.SpecialFolder.GetResource("GeoLite2-City.mmdb").Path, FolderItem.PathTypeNative)
ISPFile = CityFile.Parent.Child("GeoIP2-ISP.mmdb")
Catch
Log "LocationLookup_GeoLite2: Unable to find MaxMind mmdb database"
End Try[/code]
Indeed GetResource cannot be used like other SpecialFolder. This was discussed during the beta of iOS : the file MUST be there. AFAIK this is intended.
The solution is to use a Try Catch when you are not sure the resource is actually present.
Well, it did crash very well in iOS , I filed a report during 2015R1 beta, and got a “by design” reply explaining it did trigger an exception. that should be handled Maybe that is the same here.
<https://xojo.com/issue/37504>
Your example fires an exception on iOS. Unhandled exceptions (regardless of cause) on iOS always terminate. That is different from the Windows platform issue being discussed here.
Michel Yes I had read the separate issue with the file needing to exist. (And note that this code DOES use Try Catch for just that reason.)
In this case BOTH files do exist, either one can be obtained successfully if it’s the FIRST call to GetResource. But it’s the SECOND call to GetResource that crashes (Windows Access exception), even though that file does exist.
This behavior is 100% reproducible in my app, and I hope it stays that way in a small demo app. FWIW It occurs via the remote debugger and also in built 32 bit and 64 bit apps when run on Windows 7.
Also note that both calls to GetResource work fine on OSX builds.
