Myriad Tables update

FYI, version 1.0.6 is now available. Changes are:

  • Ability to show cells containing more than one line;

  • Ability to hide the Cancel button;

  • Improved handling of threading issues with accessory views;

  • Ability to specify monospaced digits (10.11 and later only);

  • Ability to have negative numbers appear in red;

  • Ability to have column(s) appear in bold;

  • Japanese localization.

You can download it here:

I’m using this in a little utility I’ve written for others. They’ll have the choice of either downloading the utility as an .app with MT v1.0.6 in the bundle, or they’ll be able to download my source script and follow directions to install MT themselves locally from the macosxautomation site.

In the latter case, will my source script work without changes in the future if they download a later version of MT (e.g. a hypothetical v1.0.7)

My script’s import statement is

use script "Myriad Tables Lib" version "1.0.6"

Does the MT source code allow the stated version or higher, or is it strict to the actual version stated?

It’s a minimum requirement. It’s actually enforced by AppleScript, following the same approach as a use AppleScript version... statement.

Barring unforeseen accidents, I intend to maintain backwards compatibility.

Cool! That what I was hoping you were going to say! :+1:t3:

For anyone interested, the compiled version of the utility in question is now available freely from here.

Nice table :slight_smile:

So how come it’s showing my last CCC backup, without installing the postRun script?

It’ll show the backup of the source disk without the shell script, which it gets from CCC’s Task History, but it won’t show when any of your connected disks were last backed up until they’ve been backed up with the shell script.

BTW, the script is now included in the bundle’s Resources/Scripts folder in v1.1 (and so is the Myriad Tables Lib, which I forgot to add in v1 and didn’t notice as it was running from my own installed version. :scream:).

Also the applet isn’t saved as ‘run only’ so all can marvel at my bad coding practices; resist the temptation to “improve” it though, as that’ll break the codesigning. :wink:


This is a bit more friendly to non-English speakers:

set s to do shell script "tmutil latestbackup"
set s_String to NSString's stringWithString:s
set theIndex to location of (s_String's rangeOfString:"/" options:(current application's NSBackwardsSearch))
set timeString to s_String's substringFromIndex:(theIndex + 1)
set dateFormatter to current application's NSDateFormatter's new()
dateFormatter's setDateFormat:("yyyy-MM-dd-HHmmss")
set theDate to dateFormatter's dateFromString:timeString
dateFormatter's setDateStyle:(current application's NSDateFormatterLongStyle)
dateFormatter's setTimeStyle:(current application's NSDateFormatterShortStyle)
set timeString to (dateFormatter's stringFromDate:theDate) as text
1 Like

Thanks, I’ll try to add such niceties in v1.3. Right now I’m having nightmares with codesigning. The earlier versions passed on the latest beta of 10.12, but now I can’t get either SD or SE to codesign the bundle correctly. One and the same signed bundle gives me different results depending on what I try to download it onto:

10.10.5 & 10.11.6 - pass
10.12.1 release - pass, but flagged as ‘weak’ in RB App Checker Lite
10.12.2 16C63a - fail

Totally flumoxed. I don’t see that I’ve done anything different from the version this morning to the one I’m trying to do now.

EDIT: solved by rebuilding the whole project on Sierra beta and codesigning there. Not fun!

If you’re only interested in Gatekeeper compliance, use this in Terminal:

spctl -a -t exec -vv /path/to/

If that says accepted, and provided you’re running under 10.9 or later, you’re good to go.

The problem was that signing the app in 10.11.6 would pass Gatekeeper on 10.11.6 but not 10.12.2. (by which I mean downloading it to my own machine externally from the aws host threw the ‘unidentified developer’ dialog in the latter but not the former).

For reasons I haven’t yet determined, that didn’t occur with v1 or v1.1 built only a few hours earlier on the same machine and install.

I encounted a few other problems at the same time with SD and autosave and with copying resources into the bundle (is there any way to stop SD autosaving?); my impression was that the corruption was something to do with the order in which SD was autosaving and signing the current state of the app, but tbh, I was more concerned with fixing the problem ASAP than analysing the cause. I’ll be able to take a more leisurely approach when I do the 1.3 update (forewarned, forearmed an’ all that). :slight_smile:

You might try signing the lib separately first.

According to RB App Checker Lite, the problem was the Info.plist was not signed or had been altered after signing. That’s what led me to think it was something to do with the order of the save/signing process.

It occurred to me earlier today that I should turn code signing off until the final build / save. As SD code signs on each and every compile, run and save, perhaps the whole signing signature had become corrupted in some way.

Anyways, if it occurs again I’ll take the trouble to document some reproducible steps and we can take it from there.

Yes, continual signing is probably not a good idea for anything other than a simple applet with no embedded resources.

This might be a good thread to point to this article again:

I strongly recommend keeping all but the simplest of script libraries out of bundles during development, and adding them only when ready to export deployment versions. There’s a script in that article that can be adapted to make it a simple process.

FYI, I’ve just released version 1.0.8. It fixes a problem that occurs in scripts run from the Scripts menu in some versions of Script Debugger.

Link? ( should know this but don’t have it bookmarked)

Can I suggest you use the “Open in script debugger” for quoted scripts on the SD web page?

I gather it’s not possible using WordPress, which is what’s used for those pages.


1 Like