Freeze window command via AppleScript?

[mikedr]

Is there a way in AppleScript, when communicating with FM (i.e., an AS triggered from outside of FM) to tell FM to freeze the window?

[The Shadow]

You could make a script that does freeze window, then use "do script", but the script would need to not exit for a while.  In any case, I doubt it would "hide" your AppleScript actions, assuming that's your intent, AppleScript is much more like manipulating the UI elements themselves.

[Rick Whitelaw]

Why would you want to do this? Assuming FMP is open of course.

[mikedr]

You could make a script that does freeze window, then use "do script", but the script would need to not exit for a while.  In any case, I doubt it would "hide" your AppleScript actions, assuming that's your intent, AppleScript is much more like manipulating the UI elements themselves.

 

Why would you want to do this? Assuming FMP is open of course.

 

Here's the long story on the motivation.  A patent application can be referenced by patent application number, law firm docket number, or client docket number.  A patent application number can be of the form XXYYYZZZ, XX/YYY,ZZZ, or XX/YYYZZZ.  Before we migrated to FM from an Excel spreadsheet, I wrote an AppleScript that is accessible as a service.  So, a user can select any of the aforementioned numbers, where a patent app number can be in any form, in an email, right-click, and select "show patent application," which would show the relevant application in the Excel spreadsheet. 

 

When we first migrated to FM, I just rewrote the AppleScript so it searched FM instead (I was proficient at AppleScript but not at FM scripting at the time).  The way AppleScript interacts with FM for searching is a bit odd, which meant that any time I modified the main layout in FM, I had to modify the AppleScript (from what I can tell, when executing searches of FM from AS, you have to order the fields in the order they're shown in the layout, from left to right and from top to bottom, so if you add a new field somewhere, you have to allow for that in the AS).  The way I fixed having to re-modify the script all the time was to add a layout that just lists the fields that will be searched -- the AS jumps to that layout, does the search, and then jumps back to the main layout. 

 

What I don't like is that you when you do a search, you can see momentarily the search layout.  Looks amateur-ish.  Hence my desire to do a freezewindow.

 

I think what I'm going to do is rewrite the search script in FM, and then have the AS simply call the FM script, passing the selected text as a parameter.  I know FM scripting well enough now that this won't be difficult, just a bit of work.

 

BTW, the ability to interact with FM "both ways" (FM calling AS's, and AS's calling FM) is a great boon.  I have FM doing neat things with Microsoft Word, Adobe Acrobat, and Cultured Code's Things.  And being able to select text in an email and then automatically showing the record in FM is a great timesaver.  AS is archaic, though. 

[eos]

AS is archaic, though. 

 

Yosemite now supports JavaScript as an alternative to AS, which may be more to your taste; so either wait for FM14 (?) to implement “Perform JavaScript”, or from FM launch an AppleScript to issue a shell command to perform a JavaScript … 

 

What I don't like is that you when you do a search, you can see momentarily the search layout.  Looks amateur-ish.  Hence my desire to do a freezewindow.

 

Since you're performing an automated search, there should be no need to display any of the things a human operator would need (visible field objects, for instance); you could as well use an empty layout that just displays a “Search in Progress …" message.

[mikedr]

Mavericks now offers support for JavaScript, which may be more to your taste; so either wait for FM14 (?) to implement “Perform Javascript”, or call an AppleScript to issue a shell command to perform a JavaScript … 

 

 

Since you're performing an automated search, there should be no need to display any of the things a human operator would need (visible field objects, for instance); you could as well use an empty layout that just displays a “Search in Progress …" message.

 

I know!  Now I have to learn JavaScript tho.  :

 

The empty layout doesn't work with the way AS interacts with FM -- the fields in question have to be on the layout for AS to be able to search them, because AS seems to interact with FM as if the user was entering in the search fields itself.  Now, an open question is whether I could hide the fields from view, or make them the same color as the background screen (the latter would definitely work).

 

The thing I don't like about this approach, either, is that it's still messy -- the search in progress window would only show up for a half second.  Sometimes not at all.  My paralegal doesn't mind (and didn't even "see" it until I brought it to her attention), but it bothers me in its lack of elegance.  Rewriting the script in FM won't be hard, just gotta find the time!

[MikeKD]

Could you just put a panel in front of them with "Search in progress" text on it?

[mikedr]

OK, I don't know what a panel is. 

[MikeKD]

oops, wrong programme :-/

Could you cover your fields with the rectangle tool & stick some text on it?

[mikedr]

Perfect!  That worked like a dream.  I made the text box cover the entire layout, with a solid background to cover the fields.  Beautiful!  Thanks so much! 

[MikeKD]

Yay; I helped someone! :-)

[bruceR]

Note that there is an approach in AppleScript that eliminates the screen flash you are complaining about, by using the equivalent of Filemaker's set field. Set data cell "cellname" of table "tablename" is the general approach. This works especially well with global fields. Like an SQL query you must specify additional criteria if you need to target a specific record.