Feature suggestion: Enhancing the Stationary Script Context with Note Title

Hi Michael,

I’ve been experimenting a bit with custom format notes and I’ve been following the great documentation available on the subject.

One thing that I’ve found a bit limiting is the lack of access to a new note title from within the metadata script details. The context contains some details about the location of the note to be created, but the title you enter manually is not available in that context.

So for example if my notes follow a custom filename pattern (e.g. date-title.extension), I cannot do this in one step through the metadata script.

Do you think it would be possible to include this bit of information in the context record that gets passed to the script?

thanks,

A://

I will add that to do the to-do list. For now, I think it would work if you made the File column visible. Then EagleFiler would no longer bring up the sheet to ask you for the filename. You could then add a “display dialog” command to your metadata script that prompts for a filename, and then it would be available to you within the script.

I went this route and sometimes it works, but sometimes I’m getting a weird error back:


AEError: {
  NSAppleScriptErrorAppName = EagleFiler;
  NSAppleScriptErrorBriefMessage = "No user interaction allowed.";
  NSAppleScriptErrorMessage = "No user interaction allowed.";
  NSAppleScriptErrorNumber = "-1713";
  NSAppleScriptErrorRange = "NSRange: {0,0}";
}

Now the error message is spelled out, but I cannot figure out what it really means (or why it works sometimes).

My stationary script is as simple as:


on metadata(_context)
	set _title to text returned of (display dialog ¬
		"Enter note name" with title ¬
		"EagleFiler Markdown Note" default answer ¬
		"" buttons {"Continue…"} ¬
		default button 1)
	set _base to do shell script "date '+%Y%m%d%H%M%S'"
	set _basename to _base & "-" & _title
	set _tags to {"note", "markdown"}
	return {basename:_basename, tags:_tags, title:_title}
end metadata

Any ideas?

thanks a lot,

A://

It seems to be working on my Mac. Do you get consistent results within a given EagleFiler launch session?

Hmmm… that’s a good question. I guess the answer would be yes, as once I’m noticing it doesn’t work there’s nothing I can do to make it work. For example today, it works. I’ll keep this question in mind and try to validate it.

Do you have any thoughts what might trigger this behavior? It makes me think of some permission related behavior that would not allow AS scripts to display visual elements (the input dialog) when the app was started automatically…

I wonder if restarting EagleFiler or your Mac would help.

I’ve typically seen this error when the script is run from a context in which there is no user interface. For example, logged into a Mac via Terminal and then running the script with “osascript”. However, in this case the script is running from within EagleFiler, which is obviously already displaying a user interface. So I’m not sure what the problem is.

It would also be interesting to see what happens if you put the “display dialog” inside a “tell” for another application…

I don’t to that.

I think this last part might do it. I remember using a similar trick for displaying a dialog from an AS script triggered by cron.

I think I’ve finally identified a scenario that leads to this error:

  1. leave EagleFile running
  2. put computer to sleep
  3. wake up
  4. create new item (using custom stationary script)

The only workaround I’ve found is restarting EagleFiler.

I’m not sure there’s anything that can be done or if this represents a more serious bug in the way Mac OS X changes app attributes after a sleep-wakeup cycle (I’m not a OS X developer so I shouldn’t comment on this though).

A://

It sounds like a potential bug in Mac OS X. However, I was not able to reproduce this problem on my Mac with a stock installation of 10.7.3. So there might be some other software involved.