1 of 1 people found this helpful
No, there is no difference. The SetField function is a newer function and in the very old days we only did copy, paste and clear. Those functions are still here even though we rarely use them anymore. But they still work just fine!
1 of 1 people found this helpful
Clear belongs to the "Editing" group of steps. It requires the target field to be present on the current layout.
Unless there are overriding reasons, you should always use Set Field to modify field data.
Thank-you so much for the help. I thought that there was no real difference. Im busy trying to get my head around a program that has been developed by a few different developers over the years, and I have only been using FM for the last 4 months, so I just wanted to make sure. Thanx again
I thought that there was no real difference.
In case I haven't made it enitrely clear (no pun intended): there is a BIG difference. One works on the layout level, the other directly at the data level.
Since they accomplish the exact same thing which is to remove a value from a field in a layout, I disagree that there is a "BIG" difference. Lets put it in perspective with the question: No, ndveitch does not need to go through all his/her old scripts and remove the "clear" statements and replace with setfields. They will still work just fine. Granted it advertises old school scripting, but they both will work. Another way of putting this is that my clients, who could never tell the difference either way, would Pay me to go through old scripts just to replace "clears" with "setfields". And as you pointed out, there is a minor difference in that the "clear" only works at a layout level for a field that exists on that layout and setfield talks directly to the data table. My recommendation is to leave old working scripts alone and to write new ones using the setfield script step.
Clearly (pun) the field MUST appear on the layout, but not if SET correctly.
-- sent from my iPhone4 --
Taylor is correct, with one caveat: Any scripting that uses Clear will necessarily mean the developer will have to be careful about removing fields from layouts. If you remove a field from a layout where a Clear is used, it will break the script.
So be vewy, vewy caweful when modifying layouts that you double-check to make sure the field you're removing isn't referenced by an editing step (like Clear or one of the Inserts).
Well - not to beat a horse to death, only to then beat the dead horse....but as this issue caused a night of pain for me many moons ago, it seems as worthy as any to call 'big' in that there is a clear cut distinction between the functionality in clear versus that found in setfield. This is heightened by the OPs reference to the goal of clearing a remote layout. This particular night's pain landed at an ah ha moment where I locked in the distinction between that which operates on the editing level and thus requires said action be done while on a layout which has the physical object present and accounted for.e.g. insert , clear, versus those which are acting at the data handling level and can zip in and out of the matrix without any layout dependencies. As I made my way into custom web publishing and began to learn the differences in firing scripts at an api versus doing so in a filemaker client environment,
these distinctions became even more relevant. In summary, it seems more helpful for the OP to walk away knowing that 'clear' requires its target layout object be present and in context when the script step is evaluated whereas set field only requires access to the target field as opposed to walking away with a sense that set field is a newer , better clear.
Again - apologies to the horse and family.
It is interesting, when you finally take a close look at things you always took for granted
Both script steps existed as far back as FileMaker 3, so not new, and are COMPLETELY different ( e.g you can Undo a Clear )
And yes, you can use both to accomplish the same thing, in most cases. Just try it
And yes, there is no shame in leaving the Clears as is
> Well - not to beat a horse to death
Agreed and a good point to be aware of!
Taylor is correct, with one caveat: Any scripting that uses Clear will necessarily mean the developer will have to be careful about removing fields from layouts.
That's not the only caveat. There are also script triggers to consider, for example. There maybe others that don't come to mind at the moment. So you can either be very careful - or just do the right thing from the beginning.