It's clearly running the wildcards one at a time and returning the first file found with one of the wildcards, and not the first file found with all wildcards.
It's easily verifiable via the following test (see first screnshot). The order of my wildcard parameters should NOT matter.
Obviously if i'm sending a set of wildcards, I am looking for the first file out of all of them, not just the first file found in one of the [the first? the last? i didn't bother to check that deeply] wildcards sent.
BACKSTORY: I'm using this to find the first image file in a folder, and images can be one of many extensions! I've included a 2nd screenshot of how I intend to use this function. Note in my 2nd screenshot, the test would pass, but only by the coincidence of jpg being the first wildcard mentioned, and jpg being my first file. If my first file is not a jpg, using it this way fails. There's no way for me to get around this without loooping through every extension myself. It's possible, but it would be nice if TCC returned the correct value of the first file found in wildcard passed to %@FINDFIRST :)
Long story short: There is no way to find the first image file out of all possible image extensions with the %@FINDFIRST function, due to this TCC bug. Note the last two lines in this screenshot, and how the "first" result is returned incorrectly when the parameters are reversed.
It's easily verifiable via the following test (see first screnshot). The order of my wildcard parameters should NOT matter.
Obviously if i'm sending a set of wildcards, I am looking for the first file out of all of them, not just the first file found in one of the [the first? the last? i didn't bother to check that deeply] wildcards sent.
BACKSTORY: I'm using this to find the first image file in a folder, and images can be one of many extensions! I've included a 2nd screenshot of how I intend to use this function. Note in my 2nd screenshot, the test would pass, but only by the coincidence of jpg being the first wildcard mentioned, and jpg being my first file. If my first file is not a jpg, using it this way fails. There's no way for me to get around this without loooping through every extension myself. It's possible, but it would be nice if TCC returned the correct value of the first file found in wildcard passed to %@FINDFIRST :)
Long story short: There is no way to find the first image file out of all possible image extensions with the %@FINDFIRST function, due to this TCC bug. Note the last two lines in this screenshot, and how the "first" result is returned incorrectly when the parameters are reversed.
Last edited: