Super Simple copy to clipboard script?

[Hungry Dragon]

Anyone know the best way to do a simple, powerful script so that when triggered by clicking on a field, the content of that field is copied to the clipboard?

[Lee Smith]

That would be the small normal script

Copy Field?

Make the field a Button and attach the script (I would also not allow entry in the field.

Maybe if you explained what you were trying to do, I could make it sexier. LOL

Lee

Edited December 5, 2007 by Guest

[Hungry Dragon]

Basically I have a lot of layouts that have entry disabled to prevent accidental altering of the data, and instead have the users use a different 'editing' layout when they want to make changed.

However this also means that you can't just select the field content and copy it to the clipboard, if they want to the paste it into some email or word document the user is writing up. So to get around this the user goes to the 'editing' layout, just to copy the text. I don't like this, it opens the data up to accidental alterations, and adds seemingly unnecessary steps for the user.

So what I would like it to just have the uneditable fields act as a button that when clicked on the content of just that field gets copied into the clipboard so that the user can do whatever they want with it.

The problem I've encountered is that the copy command in scriptmaker either requires the target field to be specified, or it'll copy the whole record. But as I want to do this to something like 50 fields, having to write a different script for each one doesn't sound like fun, plus is bad programing methodology.

Have looked into using a variable, and can get the data i want to be put in a variable, can't figure out how to get that into the clipboard.

Any ideas or pointers greatly welcome.

Cheers,

--Dave

[Lee Smith]

Isn't that what I just said? :qwery:

You can create a separate layout if you want, but basically, you can lock the field in Layout Mode to not allow entry in Browse. Select the field, and attach the Copy Script step, and you don't have to go into Scriptmaker to do it, you can select it in the Button Setup Dialog.

Lee

[Ocean West]

this may also be an appropriate technique

http://www.filemakermagazine.com/videos/copying-merge-fields.html

[Hungry Dragon]

You can create a separate layout if you want, but basically, you can lock the field in Layout Mode to not allow entry in Browse. Select the field, and attach the Copy Script step, and you don't have to go into Scriptmaker to do it, you can select it in the Button Setup Dialog.

I did try that, but it copies the whole record into the clipboard (as a long string of useless text noless), and all I want is the content of a specific field.

[Lee Smith]

don't use Copy ALL, use just Copy.

Lee

[Hungry Dragon]

I did, but it still copies the whole record, which is rather annoying.

[Lee Smith]

you haven't selected a field.

Lee

BTW, you have only been talking about one field. There have been Topics in the past on this subject, if you are needing to copy more than one field, this would change things.

Other then wanting to paste the contents of a field into the Clipboard, you really haven stated why. Using the Clipboard should be avoided, especially since you could probably accomplish what you are after using one of the others, such as Set Field, Insert Calculated Result, Duplicate Record, etc.

HTH

Lee

Edited December 6, 2007 by Guest

[_henry_]

Hello HungryDragon,

Using the Clipboard should be avoided, especially since you could probably accomplish what you are after using one of the others, such as Set Field, Insert Calculated Result, Duplicate Record, etc.

For me, I would "copy" or save the value of the record using variables. That would be easier, then if you want to "paste" the value, you can use "Set Field" or other functions...

[Hungry Dragon]

I still can't work out a good why to do this. At the moment the only option that works is to make a separate script for every field I want to be able to click on and copy the content to the clipboard. But the programmer in me just hates the idea of replicating almost identical scripts.

[Raybaudi]

What about a layout that has ALL calculated fields ?

The text inside them can be copied and even dragged and dropped, still preventing accidental altering of data.

[Hungry Dragon]

That is an interesting idea, it would work, but would require creating a calculated field for every field on a number of layouts... probably 100 or more extra fields, just so the contents is copyable... I will have to think this one over.

[Raybaudi]

... maybe you can give access to the user in this way ONLY to some relevant field, not to all.

[comment]

How about something simple?

PseudoSetClipoard.fp7.zip

[Hungry Dragon]

Oh, wow, that looks great. Simple, elegant, fast, flexible, my favorite sort of code. Will give it a go and let you know how I get on.

[Raybaudi]

Hi comment

why not a script of only one step:

Set field [ Table::gClipboard ; Get ( ScriptParameter ) ]

and let the gClipboard field enterable to the user for edit/copy/export ?

[comment]

Because that was not the request? True, the Insert Calculated Result[] can be replaced by Set Field[] - it makes very little difference here.

BTW, if you change gClipboard to type Container, it will work with all data types.

[Hungry Dragon]

Okay, have put it to work, its working perfectly. Exactly what I needed. Now I have to teach the users there is an easier way... :o

[LaRetta]

Hi Michael,

In your PseudoSetClipoard file, I notice you end with Go To Field [ ]. I know, in older versions of FileMaker, there was no Exit Records/Requests or (now) Commit Records/Requests and so it was pretty common to use; at least I THINK that's what I've understood. But I thought that, now with Commit Records, Go To Field [ ] had been pretty-much dropped.

I am wondering if you have a specific reason for using it (you usually do) or whether it was old habit or simple preference. It seems like a small question but it is still important and if there are any subtle differences on when to use one or the other, I'd love to know it! Both, it seems, removes the cursor from any field and gives up possession of the record. So why use Go To Field [ ] ?

LaRetta :wink2:

[comment]

That's a good question. Until you've brought this up, I thought Go to Field[] would exit the active object without committing the record. Which is true, but there's a catch: the action is equivalent to clicking outside any object, so if the layout is set to save automatically, the record WILL be committed; if not, the script will be rudely interrupted by a message asking if you want to save the changes.

Seems like the only way to "deselect all" without committing is to place a dummy non-enterable object (e.g. text or a rectangle) on the layout, and use Go to Object ["dummy"].

[LaRetta]

Well, I wondered if a global field took possession of a record. My test shows it does not. If this is correct, no commit would be necessary. BTW, I just opened a new window to test and have not (yet) run it by opening two simultaneous users to a served file. But I believe the results should be the same.

[comment]

A commit is NOT necessary - that's the point: I didn't want copy to have the side-effect of committing the record.

[LaRetta]

I just meant that, since the cursor will be sitting in a global field, it won't be necessary to even remove the cursor; why can't it be left there when the script ends? I appreciate the input a great deal, thank you!

[comment]

Well, the idea was to make all this transparent to the user. Disable the last script step in the attached file, and you'll see what I mean.

PseudoSetClipoard2.fp7.zip

[LaRetta]

Ah, gotcha ... because to put something onto the clipboard, we need to use Copy[] which requires Select Entire Contents and there is no way to hide it although one could go to another layout and back. I like your concept of using Go To Object ["Dummy" ] instead of layout hopping. One could also make the global field 1 px x 1 px and it wouldn't show at all.

[comment]

One could also make the global field 1 px x 1 px and it wouldn't show at all.

It would, if user started typing. It's not a "clean" solution.

[LaRetta]

Oh, duh, of course! Agreed! Thanks for setting me straight!

[comment]

No, thank you. If you hadn't insisted, I wouldn't have discovered the limitation of Go to Field and the Go to Object ["dummy"] workaround. You have made yet another entry in the "Not in the Manual" document, which I am sure will please you to no end. :)

[aldipalo]

Wrong post.

Edited November 28, 2008 by Guest

[LaRetta]

It does indeed tickle me! I, like ChindoguMaker, enjoy discovering, uncovering or recovering strange things ... and even BEING strange things! :jester:

[Raybaudi]

A little bird hits my ear... :)

[Jason Maskell]

A really simple way to do it, which was my modification of some of the suggestions, is to create one script that use IF statement branching based on the script paramater passed in.

This worked for me, as I only had a handful of fields on different layouts, etc... My use case was being able to copy email addresses from different areas of the solution.

So for each field I wanted to give the click to copy behaviour, I setup the field as a button, and assigned it my script below, which I created. The script paramater is a string that makes sense (in my case different tables that have the desired field, which might be used on different layouts - so this reduces the number of IF branches).

It copies the field and then selects nothing, so that the field doesn't become editable.

The script I created is as follows:

Freeze Window
Allow User Abort [Off]

Set Variable [$param; Value: Get ( ScriptParameter )]

If [$param = "approvers"]
	Copy [Select; Approvers::Email]
Else If [$param = "contacts"]
	Copy [Select; Contacts::Email]
Else If [$param = "companies"]
	Copy [Select; Companies::Email]
Else
	Halt Script
End If

Go to Field []

Even if there was a reasonably large number of fields, it wouldn't be too big of a job to setup.

[mr_vodka]

You are replying to a topic from almost 12 years ago. 😉