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
