Jump to content

Question on Cut&Paste


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

Recommended Posts

Copy/Paste is "bad" because:

1. The fields have to be on the layout for it to work;

2. Compared to SetField, it takes 2 or more script steps instead of 1 to do a copy and paste; and

3. It will overwrite anything else your user may have already had in the copy/paste buffer. So, if they've just copied 2000 words from a word document, run a copy/paste script in FMP and then tried to paste their 2000 words into a text field. What they will get is the "copy" contents of the script step. You and I may think this is funny - they won't.

SetField is much better because it doesn't rely on the field being on the layout. BUT, SetField relies more on the format of the field (text, date, time, etc). Sometimes you need to use InsertCalculated Result instead. For example, if you wanted to get "2/3/2002...2/8/2002" into a date field before executing a Find, SetField wouldn't do it because it won't recognise it as a date format, but InsertCalculatedResult would.

Russ Baker

[ March 21, 2002, 03:06 PM: Message edited by: Russell Baker ]

Link to comment
Share on other sites

Hi,

Lets get the ball rolling and see how many people agree/disagree. Should be fun.

The problem with cut/copy & paste is that the fields have to exist on the layout that you are doing the desired function on.

Therefore, we as developers like to make our lives easier. Who wants to either add fields from this or related databases just so we can copy them.

We could always go to a layout with all fields on and then perform the task, but therein lies more scripting and we do like to do things the easy way (well, who wouldn't).

Hence set field comes into play. The field doesn't have to be on the layout in this database (heck, it can even be in a related database) and we can set its contents to whatever we like (including calculated functions).

So, there you have it. The low down on the no good copy-paste routines.

Right, who is up for some more on this.

Dan, I know you are out there watching .

Link to comment
Share on other sites

OK, I'll jump in here if I may...

Another BIG advantage of Set Field as opposed to Cut/Copy & Paste is when you begin to work with multiple/related files (if you're not already) and want to push or pull information to/from another file. You can use some global fields and Set Field based only on a relationship - you won't have to go to the other file, find the appropriate record(s), paste the data, then go back to the original file - a fairly long script. Whereas using Set Field can be a single step script.

Link to comment
Share on other sites

But if you replace your cut and paste commands with set field, you'd need an extra global field in most instances for it to work, correct? Especially for transferring info across files.

Are there any data integrity issues or stability issues that arise from cut&paste?

[ March 21, 2002, 04:47 PM: Message edited by: ASNL ]

Link to comment
Share on other sites

There are one or two situations where you can't avoid using cut and paste, like when you are setting up a date range for a find operation. In these situations, you can preserve the contents of the clipboard at the beginning of your script, and then restore it when you are done so that the user doesn't lose the prior contents. Here are two scripts that save and restore the clipboard.

code:


# This sub-script saves the contents of the clipboard.

# The clipboard layout contains the fields gClipboard1 and gClipboard2

Go to Layout [Clipboardlayout]

Clear [gClipboard1]

Clear [gClipboard2]

# gClipboard1 is a global text field which will save the clipboard contents if it happens to be text

Paste [gClipboard1][select all]

# gClipboard2 is a global container field which will store everything else

Paste [gClipboard2][select all]

Go to Layout [original layout]

code:


# This sub-script restores the contents of the clipboard.

Go to Layout [Clipboardlayout]

# Determine whether the saved clipboard data is text or other, and restore accordingly.

If [not IsEmpty(gClipboard1)]

Copy [gClipboard1][select all]

Else

Copy [gClipboard2][select all]

End If

Go to Layout [original layout]

Link to comment
Share on other sites

The absolutely only time I use the clipboard in FileMaker is with the Copy All Records script step. Placing a single ID field on a layout, copying all record and pasting the result into a global field will give you a return separated list of all the IDs of the records in the found set. By building a relationship between this global field and the key field in another database, you can use Go to Related Records [show] to create a found set in a related database of all the records that are related to any records in the current database.

Truthfully, however, this could conceivalby be done with a loop instead, so I can't really think of a reason to use the clipboard in FileMaker scripts. It gets rid of the contents that the user may currently have in the clipboard, and while you can use tecniques like Bob's to preserve the clipboard and restore it when you're done, why go through the trouble when it's unecessary?

Chuck

Link to comment
Share on other sites

Thank you very much for your input. After going through a few of my scripts on a current project and implementing a set field, It reduced the number of steps in half. The method i'm using is having a gClip field in the Child and a relationship of Always_1 on both files, I do my set command to set the gClip field, and then another set command to take the info out of the gClip and into where I need it in the child. This sound ok?

Link to comment
Share on other sites

  • 3 weeks later...

Having read this message thread, I agree, that in most instances, set field is much better. However, frustrated as I am, I must ask all of you for your advice on my current dilemna.

I have built a FileMaker solution (.fp5) for Windows platform. The main reason for building this solution, is because of the lousy and cumbersome system which exists in my workplace already, which allows me no flexibility whatsoever. (Sorry to digress). In any case, my goal is to eliminate redundant data entry, so I find myself having to share data ACROSS applications. One, my FileMaker Solution, which I can control, and the other (We'll call it R&R) which I can only input data through typing. (I cannot import data into it etc etc.)

My problem is this, I want to copy the contents of a calculation field (Which basically is name & "

Link to comment
Share on other sites

Hi,

If you create a layout with that field on (or go to a layout with all fields on)

then you can script it

Freeze window

Go To Layout (that your calc exists on)

Copy (calc field)

Go To Layout (Original Layout)

Exit Record Request.

Now the field doesnt have to be there and the freeze window will stop you seeing it going to that other layout.

HTH

Link to comment
Share on other sites

Copy/Paste is good when you need to preserve the format of the source, i.e. bold or underline.

It also copies exactly what's on screen, so a number field formatted to fixed 2dp yields what you see, but the set field command will get the real data - possibly with lots most post dp.

Other than that I'm a devotee of the Set Field

Link to comment
Share on other sites

"When I am on a parent record and want to create a child record,..."

You can make a script that goes to the last portal row, then sets related::non-keyfield to something, then optionally set that same field to "" (blank). That creates a related record.

Or you could set a global to the key field, then open the related file, make a new record, and set its key field to the global via a constant::constant relation.

Eeek, our posts crossed in the fibers. tongue.gif

[ April 11, 2002, 01:07 PM: Message edited by: Fitch ]

Link to comment
Share on other sites

As far as using copy/paste: I use Set Field wherever I can, because of the already-cited reasons, i.e., fewer script steps and no reliance on fields presence on layouts. However, when the need arises (e.g. Copy All Records) I generally don't worry about preserving the clipboard. (Go ahead, throw your tomatoes.)

First of all, my solutions are typically stand-alone, so the client pretty much stays in the program all day. Second, if I copy some text or whatever in some other program, it seems to me my next move is highly likely to be... to paste it! Eh? How many users are going to think, "OK, I'm copying... oh, I think I'll go do something in the database... (5 minutes later...) now where was I? Oh yes, I'm going to paste. WHAAAAT? My clipboard is gone! This is an outrage!" cool.gif

Link to comment
Share on other sites

quote:

Originally posted by Chuck:

The absolutely only time I use the clipboard in FileMaker is with the Copy All Records script step. Placing a single ID field on a layout, copying all record and pasting the result into a global field will give you a return separated list of all the IDs of the records in the found set. By building a relationship between this global field and the key field in another database, you can use Go to Related Records [show] to create a found set in a related database of all the records that are related to any records in the current database.

Chuck

Link to comment
Share on other sites

quote:

Originally posted by BobWeaver:

... you can preserve the contents of the clipboard at the beginning of your script, and then restore it when you are done so that the user doesn't lose the prior contents...

Ahhhh Bob, I've seen a couple of these "restore clipboard" systems, but this is the first that considers the fact that the clipboard can contain anything other then text! Well done!!

Link to comment
Share on other sites

I have a question, too.

When I am on a parent record and want to create a child record, can I use Set Field to enter the correct value in the match field to establish the relationship? It seems like the relationship from parent to child needs to already be established before Set Field is useful.

Link to comment
Share on other sites

If you are creating the new related record in a portal, the key (match) field is automatically entered. If you are not using a portal you have to create a new record in the related file with an external sub-script. In that case, you should have a global field in the parent file that you set equal to the parent key value (using a set field command), and then in the child file, create new record and set the child key field equal to the global field in the parent file (using a set field command via a constant relationship*).

* Constant relationship is one based on a field that always has the same value in all records in both files. Eg, create a calculated field ConstKey with the formula:

1

in both files, and use that as the key fields for the constant relationship. This then allows you to access data from globals in others files even if you have not yet established the main parent/child link in the new record.

Link to comment
Share on other sites

In designing a client's solution to chart behavior values I wanted to be able to find a subset of records in a related database and using related fields to plot the data in a master file. To illustrate, the related file, BehaviorsUtility.fp5, contains thousands of records, each record the hourly data on behavior for an individual student on a given day, with one record per student per school day. Because the client needs to chart information on a student for variable periods, such as a time of day, date range, monthly, etc, only subsets of the student's records would usually be used. The charting database, Charting.fp5, consists of one record and only a handful of fields, but lots of scripts, in order to reduce calculations, searches, and sorts to a bare minimum. I am using xmChart plugin to do the charting within FileMaker; and xmChart uses the clipboard to build the chart from a text field. So I had several challenges here: first I wanted to avoid using the clipboard for anything other than xmChart, and second, I needed a way to get the data from the subset into the Chart file with minimum sorting. In doing so, I dug around for some techniques in the Forum.

First I wanted to be able to script finds for date ranges, and thought I could just enter Find Mode, use Set Field using global fields to enter date ranges and with greater than and less than symbols, or the range symbol "..." . Discovered you can't do that, as Set Field does not recognize mixed text and date when setting date fields and gives some interesting but useless results. But Insert Calculated Result with a text caclulation equal to the start date & "..." & end date, where start date worked just fine. So I got the first part done without using copy and paste. Good.

Next I wanted to be able to create a return separated list of the record IDs in the found set once I had drilled down to the student and date range and get that set of record IDs to my chart database, again without cut and paste.

I dug up a technique in the Forums to create return-separated list of all the IDs of the records in a related found set. But the technique required the IDs to be displayed as the only field on a layout, with a script step that jumped to that layout, a Copy All Records step, followed by a paste in the master file into a global field. Not wanting to cut and paste here either, or to bob back and forth between layouts in both databases, I worked out a better way which uses the Set Field script step and no copy and paste. And it is fast.

Here is my way of obtaining the record IDs of a found set and setting a multi-key field in onother file without cut and paste. Be patient. It is not as complicated as it looks, and it permits very fast searches, sorts, and manipulations.

It requires the following relationships, fields, scripts, and one important value list.

Two files: BehaviorsUtility.fp5 and Charting.fp5

In BehaviorAnalysis.fp5

Relationships:

SelfkeyFoundSetConstant key_FoundSet = fmcConstant

Fields:

RecordID Calculation, Text Result, <Capt Kurt's ID Method>

key_FoundSet Number

fmcConstant Calculation, Number Result, = 1

FileName Calculation, Text Result, status(CurrentFileName)

Scripts:

Set Found Set key

Replace("key_FoundSet", "1")

Find Found Set key

Restore Find ("key_FoundSet" ="1")

Clear Found Set key

Replace("key_FoundSet", "0")

Value List:

"Found Records" (From Relationship, Field: "SelfkeyFoundSet[Constant::RecordID)

In Charting.fp5

Relationships:

BehaviorsUtilityConstant: fmcConstant = ::key_FoundSet

Fields:

fmcConstant Calculation, Number Result, = 1

g_SelectedRecordIDs Global, Text

Scripts:

Set Related Record Key

setField(g_SelectedRecordIDs, ValueListItems(BehaviorsUtilityConstant::FileName, "Found Records")

Once set up, run any script in Charts.fp5 to find and sort your desired set of records in behaviors.

Then run the script Set Found Set Key in BehaviorsUtility.fp5 followed by Set Related Record Key in Charts.fp5. The second script sets the global to the new set of record IDs thanks to the Value List, Found Records, which automatically is updated to the records found in BehaviorsUtility. It may seem like too much work but it took only about ten minutes to set it up, the calculations are no-brainers, and it permits me to achieve a major set of functionalities throughout the rest of the system without resorting to copy and paste.

And it is fast.

Link to comment
Share on other sites

  • 2 weeks later...

I have noticed another cut/copy/paste problem. It is not as crucial as the ones that you all have written, but it could be frustrating.

You shouldn't copy/paste images onto layouts, because they become metafiles (PC) that cannot be viewed if you run the solution on a Mac. Use Insert/Picture instead. Like I said, not as important but something to consider.

Ken

Link to comment
Share on other sites

  • 3 weeks later...

Hi Bob,

You wrote:

If you are not using a portal you have to create a new record in the related file with an external sub-script. In that case, you should have a global field in the parent file that you set equal to the parent key value (using a set field command), and then in the child file, create new record and set the child key field equal to the global field in the parent file (using a set field command via a constant relationship*).

----

No don't need to have a constant relationship to do this.

You can set a global field in the child file (equal to the parent key value) even before the child record is created. For this to work you can use the existing parent/child relation! This will work when you run a script with the Set Error Capture Error [ON] and will work only for global fields. Then in the child file, create a new record and set the child key field equal to it's own global field. Your ready ...

This little trick will even work if the child file is completely empty, so no previous records in the child file. You only must use Set Error Capture Error [ON] to get this thing working.

Even more to say. This writing to globals will even work on locked records, in child or parent files, doesn't even matter. As long as you are using Set Error Capture Error [ON] lines in your scripts ...

Now a hear other readers saying wooooowww is this true? Yes it is ...

So, there should be no limit on data moving accross your FM solutions.

Regards,

Link to comment
Share on other sites

This topic is 7987 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.