Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 5594 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

Ok I have a fairly simple problem I think.

I have a filemaker database where designers can import 10 photo's...

I'm sure you can see where this is going....

I would an applescript that would...

I need the image to be fairly High resolution but the quality can be 60% or there abouts..

Size Image should be resized to fit a box... Y high and X wide

Copy the Chosen file to the temp folder.

Perform a conversion of the file so it is no longer massive,

write the new file to the temp folder..

Filemaker can then grab it and import it.

The user is none the wiser but the FM database will be loads smaller and also if a record is emailed it will be WAY smaller than the unconverted image...

Any help most greatfully appreciated....

Posted

This example file resizes the chose image file, and inserts the resized file into FileMaker. If the original was a PNG, it respects that, otherwise it saves the resized image as JPEG. It handles many different "kind" of image files, but does not currently do PDF, nor other esoteric types. It probably could, but it would need to be modified to do so. I set the resize to 600 pixels; that's the maximum for either height or width. It's in the AppleScript itself, as a "property" at the top, so you have to change it there.

I did not include the raw AppleScript file, as it is somewhat different when run from outside FileMaker, and it seems to just confuse people when I include them.

Insert_Resized.fp7.zip

Posted

BTW, if you want to see the little image files, run this AppleScript

property tempFolder :) path to temporary items

tell application "Finder" to open tempFolder

Posted

See what I mean about confusion? Yes, the AppleScript is in the file, in a Perform AppleScript step in the [] Insert Picture wAS script ("[]" meaning, to me, "it's run by a button").

But I didn't write it in FileMaker, as it has a very limited AppleScript editor. I wrote it in Script Editor, as a regular AppleScript file. Then copy/pasted into FileMaker's Perform AppleScript step, then modified it slightly for running from FileMaker. In this case the external AppleScript file is different, because it must ask FileMaker to run an Insert Picture script, whereas within FileMaker you don't need that, you can just run the steps need to Insert Picture after running the Perform AppleScript step.

However, if you need to modify the currently embedded AppleScript extensively, you'd want to modify the external one, test, then add/modify it again, to put back in FileMaker. You have to learn to move back and forth between them to develop anything other than simple AppleScripts for FileMaker.

FileMaker runs AppleScript very well, often faster than Script Editor (likely because of its RAM). But it has poor editing and testing ability. Script Editor can not only tell you what is wrong, but show you where in the script it hit the error, which is pretty important. AppleScript error messages and its error dialogs can be a bit cryptic, though I've read that they've made some improvements with Leopard.

Posted

Thanks for that Fenton!

However, I have a client that runs their solution entirely on Windows.

Is there a plugin or other way to alter the picture size on FM Windows?

Posted

Length(TheField) delivers the size of the field, which means I have a workable solution now! :

Posted

I would look at the SuperContainer plug-in. It is a Java applet which runs on the file server machine, in a network environment. It handles a lot of these problems of images. I haven't used it myself, but seen it used (by our own Stephen Dolenski).

Posted (edited)

Thanks, Fenton I got three errors with this.

Finder got an error: Disk some object wan't found.

then when I press OK I get...

Unknown Error: -35.

Then when I press OK I get...

The file"" could not be found and is required to complete this operation.

Then when I press OK it says....

The previous script step, "Insert Picture" could not be completed because of an error. Do you whish to continue with this script?

Then it stops....

I am on Leopard 10.5.1 + filemaker 9

If I recompile the script in the script editor it runs until it gets to the my FM_Insert(smFile) which it does not understand and I have to take out the last paragraph of script to compile it at all so assume this is to do with running inside or outside the Filemaker program...

Thanks...

Edited by Guest
Posted

Are you trying this with my file? I'm a bit lost, as it works fine on mine, and, AFAIK there's nothing hard-coded in the AppleScript specific to my environment. I don't have Leopard though, still on Tiger; I can't see that AppleScript would be changed for these things, possible however.

Yes, it will not compile in Script Editor, as it does not have the: tell application "FileMaker Pro Advanced" lines. So here is the original AppleScript. If you run it this way at least it will tell you where it stops.

Also, you just have a record in FileMaker and be on the layout with the container.

Scale_Image_Temp.scpt.zip

Posted

In that case perhaps you could just copy/paste it into the FileMaker Perform AppleScript step instead of the one that is there. But then you don't need the FileMaker script steps after that step. Are you using my file? Because if not it's possible you either do not have the Filepath field on the layout, or something like that. That field name is hard-coded into the AppleScript; which you have to do. AppleScript (like almost all external scripting environments) is not going to recognize a field or layout if you change its name in FileMaker.

Posted

Is there a way to make this script work so it can be a step when inserting any image into any container ?

I have 10 containers I would like to use this on maybe 12 so this would need to be a step or else I will have to re write the whole script each time... ?

Thanks...

Posted

Basically if you have 10 containers, you could change the AppleScript to target each field by name, then call those separate Perform AppleScript steps, 1-10.

Or you could alternatively pass each field name to AppleScript via a reset global field, so that the AppleScript was the same, but the field name passed was different. Since the field name (cell) in AppleScript is text anyway, that should work (never tried it though).

Probably it's easier to just duplicate the AppleScript and change the 1 field name (cell) at the bottom.

Or you could use proper relational design and put the 10 containers as 1 container in a little related table. That's what I'd do. There is no advantage to putting all 10 in the parent table, as containers are by definition unstored fields. It would require a little more scripting, to either go to the correct related record, or portal row.

One glitch when using AppleScript is that it cannot write to an "open" record. So if you create new record using FileMaker, then call an AppleScript to set a field in the record, then you should Commit the record in FileMaker first. You could run into the same thing with just FileMaker, when creating and editing related records.

Posted

How do you mean put them in one ? do you mean have one container and then select which picture appears in it ?

I would like to do that sometime, but when i experimented the container field looks different from other fields and it was not obvious how to select a different image from a related filemaker file...

maybe you could give me a pointer ...

However in this case all 10 have to be printed out 2 to a sheet on 5 sheets so it's a different story I think ....

Unless you mean all the containers could be multiple instances of one container each showing a different image in which case I am kind of back to my first question how would you select each image...

Posted

You could select them by clicking in a portal of smaller thumbnails; which resets a local field, in the parent record to the unique ID of that related image. You show the related larger image in a larger related field. The relationship is on the unique ImageID (you could include the ParentID also, but it's not needed if the ImageID is unique).

The thumbnails could be either real thumbnails, or just the larger image with the Reduce Graphic option turned on. Thumbnails are faster, like in a List view; it depends on speed whether they are worth it. The AppleScript could also create the thumbnail. The best way I think would be to Insert the 1st resized picture, then have AppleScript resize it again (since you know its path), and insert that as a thumbnail. The size is up to you.

Anyway, here's a "toggle" example. It has real thumbnails, but that's irrelevant to the toggle routine (which is dead simple).

ThumbsImages.zip

Posted

I guess the real question about whether to do container fields 1-10, or use 1 related container is whether they each have some special function/size/place on printout, etc.. If so, the maybe 1-10 is best. But I always try for proper relational design whenever possible.

Posted

You know for Mac only implementation this is far far better than say Media manager, after all it's free, which is great.

Is there any scripting Language in Windows like applescript ?

Oh well...

What I am going to try to do is actually implement this in my solution windows users will just have to lump it I think or move to mac !

Question is if I have containers 1- 10

which parts of the script are going to need configuring :

I will have to look at this,

But thanks, this is great....

Posted (edited)

OK so I have got stuck on one last bit...

the

set field "Filepath" of current record to UnixPath

If I show the field all works well in my solution, if I do not use the image path on the actual record but the field is in the database & therefore could be refrenced for each record but not be visible it does not work.

So How do I set the Field when the field is not actually present on the record :(?

Apart from that it all works beautifuly.....

What would happen if a windows user tried this :?

how do I put in an If else to find out what people are using and alter the script accordingly ...?

Edited by Guest
Posted (edited)

There are certain defaults in AppleScript for FileMaker. The current window and its layout and found set are the defaults (notice, not the current record, that must be specified or it will set the 1st record). But if you use this simple syntax the field must be on the current layout. In other words, AppleScript's 'set' is not exactly the same as FileMaker's Set Field [ ] step, in how it evaluates its access to a field.

If you want to set a field that is not on the current layout, then you need to specify its layout. Then the field does not have to be on the current layout. You can also specify fields via a 'table' name, but 'table' in AppleScript actually means table occurrence (on the Relationship Graph) in FileMaker. And a table does not have a current record. So that reference is useful for things like getting all the table's values for a field.

Both of the methods above have a weakness, which is that the name is typed in, hard-coded. If you later change the name of the layout (or table occurrence if 'table' is used) in FileMaker, your AppleScript will break. (As will removing the field from the layout if you haven't specified the above.)

So, for anything except the very simplest AppleScripts I just create a dedicated layout, name it something dead simple like "AS", and switch there, Perform AppleScript, then switch back. But either method is fine.

Obviously a Windows user could not run any AppleScript. You can check for that with, Abs ( Get (SystemPlatform)) = 1 is Mac (2 is Windows).

If you've got a cross-platform environment and want to dynamically resize images you should look into plug-ins like Troi File, or SuperContainer.

Edited by Guest
Posted

hmmm,

So what if I actually did put the field in every layout I need, but send it to the back behind another object and make it non printing, messy but.... it would work... I've tried it...

I wanted a nice clean way to do it but maybe a bit messy as I describe and it would work...

set field "Filepath" of current record to UnixPath

Apple scripting like this is very powerful...

Lastly I would like PC's to use teh same layout, but they will obviously miss the applescript bit so I will have to script around that using an if else statement... How do I find the user system Type ?

Get(SystemPlatform)

It's long winded but it works well...

is there any way to specify the quality of an image say jpg 80% ?

Posted

This works beautifully... On Leopard... But not on Tiger what on earth is going on in Tiger the First Error is

Disk finder got an error "Disk some object wasn't found"

next

unknown error -35

next

the file "" could not be found and was required to complete this operation.

next

The previous script"insert Picture" because of an error. do you wish to continue with this script?

Posted

I wrote it on Tiger, not Leopard. So something else must be going on? The only way find out what exactly is to run AppleScripts from Script Editor (or equivalent). It's very hard to tell from FileMaker, because it does not show you WHERE in the AppleScript it hit the error.

Posted (edited)

this is odd isn't it because this is the exact same error I got when the script was run as you originally had it can you see ?

but we overcame that error on leopard by doing what we did,

but on Tiger this work around that works in leopard obviously causes the same error we had originally....

so hopefully we will find the reason fairly easily....

Lovely script by the way thanks....

It will reduce the database size by about 98% when it is being used....

Edited by Guest
Posted

Yes, but "object not found" and "file not found" are such common errors that unless you run it in Script Editor so you can see what object it couldn't find (the error dialog doesn't tell you), it's hard to fix. Especially if, as you say, it runs in one version of the OS and not in another. There's likely subtle differences in AppleScript between Tiger and Leopard. Or even between FileMaker on Tiger and Leopard. Or the Finder. Or ??

The best thing is to run it in Script Editor. But then you have to know how/where to tweak it so that it will run there.

I can't really tell what's wrong, because both methods (internal to FileMaker, and external) work for me, FileMaker 8.5 (mostly; I can run 9, but its ScriptMaker is annoying), OS 10.4.11.

Posted (edited)

OK I can see that somehow the applescript is not handing on the filepath variable to the Field "Filepath" in Tiger but it does in Leopard.....

So I will carry on looking

and then use it :)

Edited by Guest
Posted (edited)

OK I am getting there there seems to be a problem with the temporary file and Tiger with Filemaker 9....

If I use your original Solution with the button in Image_resize....

The script saves the file to the Temporary folder correctly, however when the Insert Image part of the script tries to retrieve it is does not use my disk name "Hard Drive" it seems to default to Macintosh HD, but only when run inside Filemaker, outside filemaker if you run in script editor the second script "insert Image" picks up the correct Disk Name...

So I think the problem resides somewhere in this issue....

NOt sure how to get around it...

However on further thought could not just the file name be put in the field "filepath" and use Get to get the path to the temporary folder adding the filename to the end, this would eliminate all variables that may be causing the bug between applescriping the OS and Filemaker... ??

That would work I am sure....

Just not sure how to do it.....

What do you think :)

Edited by Guest
Posted

I think what may be happening is that when I set up the script using the term "property", it compiled with "Macintosh HD" as the drive name, and didn't change. That's kind of a "feature" of property, that it stores the value, but it's sometimes misunderstood (by dilettantes such as myself :)-).

There is such a thing as "scope" of variables within AppleScript tell blocks and subroutines, which can bite you. "Property" and "global" are used to overcome that problem.

You could copy the AppleScript out, create a new one, and paste it back in again. It would recompile, and get your location.

Or, you could not use property (it doesn't seem to be needed anyway), and just set the value, since it's only used in top-level tell blocks.

Replace this:

property tempFolder :) path to temporary items

property tempFolder_txt : tempFolder as Unicode text

With this:

set tempFolder to path to temporary items

set tempFolder_txt to tempFolder as Unicode text

If you were going to use the objects inside a subroutine (on this() or to this()), then you'd also need to say:

global tempFolder

global tempFolder_txt

But I didn't use those objects inside the:

on FM_Insert(smFile)

subroutine, so I didn't need to use property, nor do we need global.

Posted (edited)

Thanks....

That now works perfectly.....

Very nice,

This will save 98 % of disk space when used on mac's so that is excellent...

I guess there is no similar coding that can be done on Windows :)

Edited by Guest
Posted

Thanks,

I would like to not touch the file if it is a PDF file, can we do an IF .pdf then skip to end of script :)

This would be so that if the file is a PDF I can still import it but the resize script will leave it alone....??

What do you think :

Posted

This will kind answer both of your recent posts. If you make a calculation field.

Right (Your Container Field; 3 )

You can then search this field for any specific ext. Or Omit the ones you don't want the script to perform in the found set.

Michael

Posted

Red,

If you make the calculation field and in the example above "Your Container Field" is the field where you are inserting the PDF or picture. You can then place this new Calc field on your layout to view what the extension is or search for specific extensions.

Michael

This topic is 5594 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.