https://github.com/livecode/livecode/pull/7056 <https://github.com/livecode/livecode/pull/7056>
> On 17 May 2019, at 5:43 am, Monte Goulding via use-livecode > <use-livecode@lists.runrev.com> wrote: > > 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 _______________________________________________ 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
