Hi all,

I often find that I want to make a field available on a layout that the
user shouldn't be able to change, but I want them to be able to put the
cursor, to select text in the field - e.g. to copy & paste.

This should be trivial, and in fact is in most programming
environments... usually you just set a property of the textbox instance
to 'read only'. In filemaker, this natural intuitive method doesn't seem
to exist. (The closest we have is 'allow entry into the field, or not'.)

Filemaker DOES let you do it in any of several backhanded ways, each
with its own drawbacks.

This can be accomplished a number of ways:

a) make the field "prohibit modification" in field defs... works great,
but means that you can never make the field directly modifiable on a
layout, which can be a pain.

b) make the field "read only" in user priviledges... works great, but
like a) above, prevents you from making the field modifiable, and now
you can't even use scripts to change the value unless they are running
in 'all access' in the file the table resides in.

c) make the layout "read only" in user privs... works great, but only if
none of the fields on the layout are directly modifiable, a serious
restriction.

d) define a custom calculation on the user privs for the field that
makes the field readonly if the current layout is such, and editable
otherwise. (or vice versa)

(I've never actually tried d) ... in theory it should work, although if
you have scripts modifying the field, you'd need to make sure you aren't
on one of the restricted layouts when it happens. At any rate, even if
it works this is so far removed from the actual textbox I'm trying to
control that it feels horridly kludgy.)

e) unstored calc = real field. essentially a copy of the field, but as
its a calc its unmodifiable. This works great, but clutters up the field
defs, especially if you want to do this for a lot of fields.

How do others solve this problem? Is there a better solution than the
one's I've come up with?

One of the really annoying things about this simple problem is that all
all the solutions except for c) violate the code/data separation model,
as they all require changes to the user privs or field defs in the data
file. [and c) is too restrictive to be generally useful].

--------------

A semi related question, how do you test user-priviledges. I, quite
frankly, have never gotten really used them beyond basic settings
because I've found them a royal pain to test and debug.

Whats the best test setup? Networked with a [full-access] box, and a
"user" box? I assume priv changes propogate more or less 'instantly' (on
par with layout and script updates)?

Just looking for some general advice,
-Dave

42 wrote:
All your suggestions are valid, but it might be easier to throw a 'copy'
button onto the layout next to the field.

Create a script and put it on the menu for testing, either to pop up a
re-login dialog, or to automatically relogin at a specific level. This
makes it very easy to go back and forth between user level for testing
and dev level for making adjustments.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg (818) 883-2846
FM Pro Solutions Los Angeles, California

FileMaker 7 Certified Developer
Associate Member, FileMaker Solutions Alliance

Howard's suggestion for creating a "copy" button is good. Also it helps
prevent mistakes with the copy action (eg missing some characters).

For "user priviliges" I expect you will need to set up a user table that
has the priviliges in a field. See my earlier post with an example of
checking the the current user - an example from FM8 help.

Michael Paine


42 wrote:

Thanks.

I agree that the copy button is a good idea, and, IMO, is the best
solution in cases where you -expect- the user to need to copy the field
on some routine basis.

(Although if I *know* the user is going to need to copy/paste the fields
on a regular basis I'd probably look to writing a script to automate the
underlying task the user is really trying to accomplish.)

So I tend to only want to provide this copy/paste support for read only
fields that normally the user wouldn't need to copy/paste.

e.g. maybe someone is trying to sort out a client concern, and is
browsing the customer history and wants to to copy some arbitrary
subseet of invoice#s, credits, ship dates, and courier tracking numbers
to notepad while making notes to help him organize his thoughts and sort
it out. I don't want to force him to manually type out these numbers
because mistakes will happen and courier tracking numbers in particular
are lengthy messes in general.

While i could certainly *could* put a copy button next to the invoice
number, ship date, post date, order date, salesrep code, commission
code, destination city, postal code, tracking number, and so forth,...
as you can imagine all these buttons start to clutter the thing up.

Another alternative is to make it an invisble button overlaying the
field that does the copy, but i don't like invisible buttons that do
non-intuitive things, particularly non-intuitive destructive things like
overwriting the clipboard.

Given that no-one pointed me at the checkbox that simply says: "this
textbox is readonly" I'll assume that there isn't one in FM8, and keep
kludging by... I just didn't want to keep kludging if they'd added it
and I didn't notice it, or if there was some more natural way to do it
that I hadn't thought of.

Thanks much,
Dave

In article <436145ae$0$26940$afc38c87 (AT) news (DOT) optusnet.com.au>,
mpaine (AT) tpgi (DOT) com.au says...

In article <43614083.70500 (AT) antispahm (DOT) fmprosolutions.com>,
howard (AT) antispahm (DOT) fmprosolutions.com says...

Wow. That's exactly what I should use:... relogin -- didn't realize that
script step existed, nor what it could do for me!

Now if only FM had had the read-only textbox checkbox i was also hoping
for...

Thanks,
Dave

Just thought I'd point out on the Mac you can run both FileMaker 7 and
8 at the same time and use 1 FM as the host and the other as the guest,
works great for testing muli-user.

I agree there should be a read only checkbox, an alternate suggestion
is to combine the different parts of the record and display the data in
a global field in a new window?

42 wrote:
OK -- here's another idea -- depends on the situation, but may work for
some solutions. Add a global field (number). Set your access
privileges for editing so that if the flag is '1', then fields are
editable, otherwise not (or the other way around). Use scripts upon
opening, switching layouts, certain conditions, etc, to mark the global
with a one and fields will be enterable but not editable.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg (818) 883-2846
FM Pro Solutions Los Angeles, California

FileMaker 7 Certified Developer
Associate Member, FileMaker Solutions Alliance

In article <11m3ah7t0geclf1 (AT) corp (DOT) supernews.com>,
howard (AT) antispahm (DOT) fmprosolutions.com says...
Hmmm playing around with this more - it looks like the ability to set
dynamic access "yes-no" calculations is at the record level not at the
field level. At the field level I can make it view/modifiable/none...
but can't define a calculation on it.

Not the end of the world, but it is a limitation. There is after all,
the possibility that their might be fields that I want always
modifiable.

--

On a related note, does anyone know offhand if globals are exempt from
record modification priviledges. (ie if a record is not modifiable, can
you edit a global field while sitting on that record?)

What about related records viewd through a portal from a non-modifiable
record?

I think Howard was referring to putting a validation on the field from
within "Define Fields". If the global equals 1 you can edit, if not
then the validation fails and you can't modify it.
Since you can use the same global for all fields it rather simple to
allow / deny access to a set of fields. The pain in the ass is you
have to copy and paste the validation for each field AND remember that
those fields have a validation on them when you use them in scripts.

In record modification privileges if you specify you can not view or
modify the record, the user can still see and modify the globals in
that table.

Actually, that would work, too. But I was originally thinking in
Privileges, to apply across the whole table.

FP wrote:
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg (818) 883-2846
FM Pro Solutions Los Angeles, California

FileMaker 7 Certified Developer
Associate Member, FileMaker Solutions Alliance