Seeking confirmation of a bug...
monte at appisle.net
Thu May 16 15:43:03 EDT 2019
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 ;-)
> On 17 May 2019, at 5:26 am, Paul Dupuis via use-livecode <use-livecode at 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".
>> if absent
>> end if
>> switch fileType
>> case "png"
>> case "jpg"
>> case "jpeg"
>> return "image"
>> case "text"
>> case "rtf"
>> return "text"
>> end switch
>> -- bonus:
>> 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
More information about the Use-livecode