Hi Paul I can confirm it is broken. I’ll patch it this morning. If it has been broken at some point during the refactor as the blame commit hash is a merge at that time. It’s an easy fix though which is good ;-)
Cheers Monte > On 17 May 2019, at 5:26 am, Paul Dupuis via use-livecode > <use-livecode@lists.runrev.com> wrote: > > Certainly there is a work around based on extensions. You and I have both > written them for Researchware ;-) However, Jeanne used this feature > extensively in a bunch of file i/o code she wrote for Researchware for > HyperTRANSCRIBE and HyperRESEARCH exports to many formats, which is why/how I > discovered it. Both HR and HT are in mid-beta on LC9 releases. > > I have already written work-around code. What I am really looking for is > CONFIRMATION this is a bug. > > I have not checked LC7 yet, but it was working in LC 6.7.11 and is not > working in 8.1.10 and 9.0.0 through 9.0.4. I am sometimes astonished that a > bug like this can go undetected through so many releases. It causes me to > worry about the adoption of LC as a serious commercial application building > tool. However, ultimately, LC's many advantages outweigh an issue like the > length of time this bug has gone undetected. > > -- Paul > > On 5/16/2019 1:30 PM, Richard Gaskin via use-livecode wrote: >> Paul Dupuis wrote: >> >> > I just filed a serious bug for LC904 that is only under OSX. When >> > using 'asnwer file <prompt> with type <typelist>' the selected type is >> > supposed to be returned in 'the result'. This works as expected under >> > Windows, but under OSX using LC904 STABLE, 'the result' is the same as >> > the 'it', both contain the file path selected. >> > >> > Please see https://quality.livecode.com/show_bug.cgi?id=22070 >> >> While it will be useful to have this fixed, the current state of macOS >> should provide a mildly-tedious-but-not-difficult workaround: >> >> The older Finder type codes (the four-character identifiers hidden away in >> the file's metadata) are long deprecated, and for more than a decade macOS >> relies on file extensions to determine type. >> >> Since the range of type options is limited to types you set, a few minutes >> writing a function to match the file extension with the type categories you >> provided should at least get you going while waiting for an engine fix. >> >> In the odd case where you may encounter a very old (or misnamed) file that >> has no type extension in its name, you could extend the function to see if >> the old Finder type is included in info provided with "the detailed files". >> >> If you were super-thorough, you might even provide another check of file >> contents to confirm type. Image formats have magic numbers, and text >> formats have patterns identifiable within a reasonably small number of >> bytes. A short read can confirm the type of misnamed files even beyond what >> can be expected with "answer file". >> >> >> Psuedocode: >> >> getFileNameExtension(fileName) >> if absent >> getDetailedFilesInfo >> convertFourCharTypetoExtensionString >> end if >> switch fileType >> case "png" >> case "jpg" >> case "jpeg" >> return "image" >> break >> case "text" >> case "rtf" >> return "text" >> break >> end switch >> -- bonus: >> confirmTypeByReadingSomeContent >> >> >> The case block for your supported types is likely still in your code base. >> Copying it to a new function and adding the earlier step of handling missing >> types by Finder code (if not already there) will make short work of this. >> > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
