Importing binary data into Filemaker in the background

General
1

I’m rewriting my data import into Filemaker. In the past I’ve dumped the content of complete tables into Filemaker. Now I’m doing this record by record which results in first a mail being written and then the attachments. For these I’ve been using an AppleScript

do script "Import File"

calling a Filemaker script:

Set Variable[$FilePath; Value:Attachment::DBInternal FilePath] Insert Path[Attachment::AttachmentData; "$FilePath"]

The big problem is that the Filemaker script always calls Filemaker to the front. When writing complete tables this was annoying. Now it’s not acceptable anymore because the export could take hours. Does anyone have an alternative idea? Preferably using AppleScript and for Filemaker >= 12 .

2

can’t you “hide filemaker” in applescript once the export script is started ?
I remember applescript always brings the app to the front, but after that I was able to hide it .
it was a long time ago and I dont remember the exact syntax.

3

The problem is that the Filemaker script is bringing Filemaker to front. Not the AppleScript itself.

4

I’ve beaten my head against this in the past without success. Please post if you do find a workaround.

5

Could you not minimize Filemaker ?

6

When minimizing Filemaker it comes back, too.

I’ve even looked at the MBS plugin for Filemaker. Apart from the very expensive price I would have to lock the Filemaker solution. But this part is meant to be integrated into the customers solution. And so the Filemaker database isn’t locked at all.

7

Here is an idea :

// The window is a Global Floating Window self.FullScreen = True activatetextedit // Script dragged into the project that activates TextEdit // Take back front from the activated app. declare function NSClassFromString lib "Cocoa" ( inName as CFStringRef ) as Ptr declare function sharedApplication lib "Cocoa" selector "sharedApplication" ( classRef as Ptr ) as Ptr Dim myApplication as Ptr = sharedApplication( NSClassFromString( "NSApplication" ) ) declare sub activateIgnoringOtherApps lib "Cocoa" selector "activateIgnoringOtherApps:" ( appRef as Ptr, flag as boolean ) activateIgnoringOtherApps( myApplication, True )

The window becomes full screen, masking the activated app window. Then the declares makes your app front, so the activated app is in the background. Hopefully that won’t freeze Filemaker.

If you want you can grab the screen right before full screen and place it as window background, so the user will still see a desktop view. In that case you may want to show a new Global Floating Window that will place itself on front, so the user gets an interactive UI.

You can start with the first window invisible and make it visible with the screen background after fullscreen, so it appears instantly. Then the user will only see the second window as the default one.

8

@Michel: thanks, that’s a clever idea. The question is if the Filemaker script will still work. Off to the drawing board.

9

Another idea, is it possible to launch in a separate terminal session?

For example, on Windows I can run psexec in which I can launch an application in a seperate session which will not show for the current user.

10

Better but not good because the frontmost app flickers badly. And when typing there are some beeps. In pseudo code:

  • set the frontmost process to LastProcess
  • start a delegating timer with a period of 10 ms
  • write attachments to Filemaker
  • stop timer

And the timer action is:

dim theProcess as new ProcessMBS theProcess.GetFrontProcess if LastProcess.BundleID <> theProcess.BundleID then LastProcess.SetFrontProcessWithOptions(1) end if

11

This works well. However, since it calls System Events, it cannot be used in a sandboxed application :

tell application "TextEdit" activate end tell tell application "System Events" set visible of process "TextEdit" to false end tell