Script step for "Store only a reference to the file"

[Rich S]

I searched the threads herein but had no luck in finding a solution for this problem:

You tell users 'til you're blue in the face to be sure to enable the "Store only a reference to the file" option when inserting an image into a container field. But do they remember? Nooooooooooooooo.

Is there a "scriptable" command I can put in an Insert script so the box will be checked automatically after an image is inserted?

TIA for your help and replies!

Rich

[comment]

You can pre-select this option for users, but I don't think you can prevent them from deselecting it. You can, however, test for this and have your script reject the choice - and yell at the user for you.

Example:

Set Error Capture [ On ] 

Show Custom Dialog [ Message: "Select a file to insert. IMPORTANT: Do not deselect the "Store only a reference to the file" 

option."; Buttons: “OK” ] 

# 

Insert File [ Table::Container ] [ Reference ] 

If [ Get ( LastError ) ] 

Exit Script [  ] 

End If 

Commit Records/Requests 

# 

If [ IsEmpty ( Filter ( ¶ ; Table::Container ) ) ] 

Set Field [ Table::Container; "" ] 

Show Custom Dialog [ Title: "WHAT AN IDIOT YOU ARE"; Message: "You were specifically told NOT to deselect the 

"Store only a reference to the file" option!!"; Buttons: “Try Again”, “Cancel” ] 

# 

If [ Get ( LastMessageChoice ) = 1 ] 

Perform Script [ “Insert File” ] 

End If 

# 

Else 

Show Custom Dialog [ Message: "The rest of the script is running now."; Buttons: “OK” ] 

End If 

[Rich S]

Ahhhhhhhh, Comment--once again, your brilliance shines through.

The only real hang-up is calling the user an idiot...which is VERY tempting but I better not...at least if I want to remain employed. :)

[Rich S]

Thanks again for the help, Comment, but just for grins maybe I can learn more/something new from this script as I'm trying to get the hang of using variables in FM:

Say I have three images per record (image1, image2, and image3) but I don't want to create a copy of the same script for each image. (This would mean that if I had to change a piece of it I'd have to make the same change to each script.)

Can a "variableized" version of the above script be created to handle all three image fields? Would it consist of local or global variables?

I know I'm pushing my luck in asking for more of your time and patience, but it would be a good learning experience for us novices.

Edited September 2, 2007 by Guest
Additional question

[comment]

Well, you could attach the same script to three buttons, each having a different script parameter. However, since the target fields for Insert File [] and Set Field[] cannot be specified by calculation, you would have to triplicate those steps, and use If[] to run the appropriate one.

Alternatively, you could put the container field and the button in a portal to a related table. In such case the script would operate on the container field in the same portal row - as long as the focus hasn't been changed (the example above wouldn't work as is, because of the Commit Records step in the middle).

[Rich S]

Thanks tons--I didn't think of a portal-type solution so I'll try that.

One thing I did notice while tinkering with the script is something other FM users might be wary of: with the script step

Insert File [ Table::Container ] [ Reference ]

...if you (users) plan to allow insertion of different filetypes then you'll have to modify Comment's script to allow for that.

Ex. Say you use the Insert File script step above and a user wants to insert an image. When he or she runs the script, a shortcut will be inserted into the container field so they'll see the referenced file icon and not the image itself; that's because they would need to use Insert Image, not Insert File.

Just another misstep to avoid!

[comment]

Hm. I should think it's up to the developer to decide how a container field should be used, and accordingly provide the user with the correct script step.

In any case, you can change the type of reference after the fact by substituting, e.g:

Substitute ( Table::Container ; [ "file:" ; "image:" ] ; [ "filemac:" ; "imagemac:" ] ; [ "filewin:" ; "imagewin:" ] )

[Rich S]

That's an interesting point about who decides how the container field should be used...or any fields, for that matter.

*steps on soapbox*

From the developer side--and I'm not being condescending, here--it's far easier to herd the cattle (users) into one chute than offer them a choice of chutes and therefore create coding and data integrity headaches.

On the flip side, as a user I'd feel a little irked if I had no choice in the matter of setting up a field/db the way I want it since I'm the one who's going to be using it and--most importantly of all--I'm paying to have the database conform to me, not the other way around. Of course, this can drive a developer crazy since you're at the beck and call of the user.

Since I live paycheck-to-paycheck, I usually let the client determine what it wants since I can't afford to have an unhappy one, but I'll stand my ground and tactfully explain that what they want may not be the best way of doing things; if they balk, well...it just adds billable hours. :S

[comment]

Well, everything depends. I certainly have no problem with the user specifying what they want. I only think they should so specify BEFORE the solution is written. It's hard for me to imagine a situation where the user says "Oh, I'll use this field for a file. Or for an image. Or maybe a movie... just leave it open for me to decide". I am not saying it couldn't happen, but it's weird. A db solution should be written for a purpose, I think, and the purpose dictates how fields are to be used - and everything else besides.

[Fenton]

*also stepping onto soapbox*

Originally FileMaker controlled everything about choosing the file. Then we were given script Variables, which allow us to specify a file. This opens the possibility that we would set up an invalid choice, for say "Import Picture".

What we are still missing is a "choose file" ability; which just opens the standard OS dialog for choosing a file, then returns the result. We could then check it, translate it to FileMaker syntax, and automate the Insert or Import step, with no further dialog (thus not exposing the [x] Store as reference only).

AppleScript has it, all of the file manipulation plug-ins have it. FileMaker obviously has it for its internal use. Why not let us use it? As I said, we already have the ability to define an inappropriate path.

It would fit nicely as an option of the Set Variable step, so you would not really need to even set a field if you didn't want to.