Howard Schlossberg wrote:

I try to pass a $$variable from one file to another: I set a $$variable
and call a script in the second file.

The $$variable is dead on arrival in the second file. It seems that
unless I stay in the same file, I still need a global field in order to
pass on a value :-(
--
http://clk.ch

In article <1h5zay0.147fyou1ijxlkoN%clk (AT) freesurf (DOT) ch>, clk (AT) freesurf (DOT) ch
says...
Why not just pass a parameter?

Why can't you use a copy and paste from a text field?

Generally speaking, one should avoid as much as possible the copy-paste
technique because, in a network, one may at the same moment use the
'interim buffer' with another copy-paste, and then you may get in
'pasting' his 'copy' and not yours. Thus when designing a solution, one
should use globals that are 'local' ie specific to the user at least in
FMP6 and maybe - I don't know - 'parameters' in FM7-8.
Remi-Noel

42 <nospam (AT) nospam (DOT) com> hat geschrieben:

[$$variables dies when leaving the file]
What's a parameter in FMP?
--
http://clk.ch

In article <43784624$0$31903$626a54ce (AT) news (DOT) free.fr>, rnmenegaux (AT) free (DOT) fr
says...
Remi-Noel,

I agree with your sentiment, but I'd like clarification on your
reasoning..

Are you saying that copy/paste runs on the *servers* clipboard? If so,
are you sure?

I admit I don't use copy/paste script steps much, but I beleive that the
copy/paste functions in filemaker operate on the local systems operating
systems clipboard, not the servers. I honestly can't imagine what *use*
they would have if they ran on the server... I thought the whole purpose
of copy was to put data in the users clipboard so they could paste it
elsewhere - or equivalently retrieve data the user had copied to the
clipboard from elsewhere.

---


Regardless, I agree with your sentiment...but for a different reason.

Just as general programming practice, the guidelines as set out by the
os publishers regarding the clipboard are simple: don't touch it. Put
data into it when the user requests it, and retrieve data from it when
the user requests it.

Do not use it for interal inter-process or inter-thread communication
(and it goes without saying that this "prohibition" covers using it to
store parameters in function calls within a single application.

Using/copy paste for parameter passing blows out the contents of the
clipboard replacing it with data that the computer user had no intention
of putting there and which is not useful to him/her, and possibly
destroying valuable data he *did* put there.

When I copy, say an URL off a web page, then push a few buttons in
filemaker to create a new record etc... when I press ctrl-v to paste the
URL i copied earlier I expect it to still be there... and would be most
unimpressed if instead it pasted 1422552R-87B.

Generally globals in Pre7, and Parameters in 7+ is the best way to
handle script parameter handling. (Although there are some cases where
globals make more sense than parameters in 7+ as well)

In article <spjgn1l3jl478f0ct6023959nb44vm290c (AT) 4ax (DOT) com>, clk (AT) freesurf (DOT) ch
says...
Its a feature of FM7 and 8. (So if you have access to "variables" you
have access to script parameters.)

Scripts may have a "parameter" that may be specified when the script is
called.

It is set as either a 'static' value, or can be the result of calculated
expression as part of the "Perform Script" step. (You can also specify a
parameter when attaching a script to a button)

Its retreived inside the script with the Get(ScriptParameter) function.

Its incredibly useful, and can replace setting a global and calling a
script in a great many situations.

It also allows for much better script re-use. Where before you needed
whole familyies of scripts that were nearly identical you can often
condense it down to one parameterized one... particularly when you
wanted buttons to do similiar but slightly different things... you used
to need to have each button call its own script to set a global and then
have that script call the "real script" -- now you can just set the
script parameter and call the "real script" directly.

It also allows recursive scripts which, until parameters, were
cumbersome to do -- as you had to manually manage the call stack.

42 <nospam (AT) nospam (DOT) com> hat geschrieben:

[What's a parameter in FMP?]

Oh my. I thought parameters and variables were the same thing. Thanks
for the clarification.
--
http://clk.ch

lists such as BlueWorld and Experts.
I'll ask the question on the Experts list and I'll come back here if I
get something interesting.
Remi-Noel


"42" <nospam (AT) nospam (DOT) com> a écrit dans le message de news:
MPG.1de1f380e312824989dc0 (AT) shawn....shawcable.net...

I got 3 answers in the Experts list that all backup what you said, Dave
alias 42, and in short, I was right in not promoting copy-paste but I
was definitively wrong in the explanation.
Copy-paste is local and not at the server level, but using it in a
script may make one lose what is in the (local) clipboard, without
noticing it.
Thank you to put the right things in place.
Remi-Noel
For the records, below are the 4 comments (including yours) :

Comment #1
I agree with your sentiment, but I'd like clarification on your
reasoning..
Are you saying that copy/paste runs on the *servers* clipboard? If so,
are you sure?
I admit I don't use copy/paste script steps much, but I beleive that the
copy/paste functions in filemaker operate on the local systems operating
systems clipboard, not the servers. I honestly can't imagine what *use*
they would have if they ran on the server... I thought the whole purpose
of copy was to put data in the users clipboard so they could paste it
elsewhere - or equivalently retrieve data the user had copied to the
clipboard from elsewhere.
Regardless, I agree with your sentiment...but for a different reason.
Just as general programming practice, the guidelines as set out by the
os publishers regarding the clipboard are simple: don't touch it. Put
data into it when the user requests it, and retrieve data from it when
the user requests it.
Do not use it for interal inter-process or inter-thread communication
(and it goes without saying that this "prohibition" covers using it to
store parameters in function calls within a single application.
Using/copy paste for parameter passing blows out the contents of the
clipboard replacing it with data that the computer user had no intention
of putting there and which is not useful to him/her, and possibly
destroying valuable data he *did* put there.
When I copy, say an URL off a web page, then push a few buttons in
filemaker to create a new record etc... when I press ctrl-v to paste the
URL i copied earlier I expect it to still be there... and would be most
unimpressed if instead it pasted 1422552R-87B.
Generally globals in Pre7, and Parameters in 7+ is the best way to
handle script parameter handling. (Although there are some cases where
globals make more sense than parameters in 7+ as well).
Dave 42

Comment #2
I have never heard of the situation you describe. Copy/paste uses the
local computer's memory not the server's memory. I don't believe what
you describe could occur. You may receive a message to the contrary
from others and I'd be interested in learning how this could occur.
I believe the reason it's been recommended to avoid copy/paste is that
it changes the user's clipboard --- where they may have stored
something they need --- and it leaves the copied item on their
clipboard where it may be pasted into another application document ---
not always a good thing if a security issue is involved with the data.
A second reason to avoid copy/paste is that it requires the field
copy/pasted to be on the layout, where as Set Field does not.
Michele Olson

Comment #3
No, there is no sharing of the clipboard in a multi-user environment.
However, if the user is performing a manual copy/paste in another
application, that application and FMP *share* the same clipboard is the
sense that each application automatically pushes its *scrap contents* to
the clipboard when the application switches to the background, and
automatically pulls the *clipboard contents* to its private scrap when
the application switches from the background to the foreground.
I think this is what you mean when you said copy/paste could use "his
copy": you (the developer) could be changing his (the user) clipboard
contents, which he (the user) put there in another application, and
which he (the user) may expect to be there when he returns to that other
application, when you (the developer) write a script which uses
copy/paste.
Jason L. DeLooze

Comment #4
The Copy All Records command in FileMaker Pro places a delimited list
of record data, based on the fields on the current layout, onto the
user's clipboard. The field order is based on tab order although portal
data will appear at the end irrespective of tab order.
I have not heard or seen any situation in which FMP is able to access
the contents of another user's clipboard. I am not aware of any
provision within any version of FileMaker Server to share clipboard
contents across workstations.
The risk in using the Copy/Paste techniques is one of losing a user's
clipboard contents. There are plug-ins available to help prevent this
in FMP 6 and earlier and with the expanded capabilities of container
fields in FMP 8 it may be possible to use a global container field to
temporarily store and restore the contents of the clipboard during
these operations. That said, the need for Copy/Paste techniques in FMP
8 is greatly diminished by new and enhanced functionality in other
areas.
Corn Walker