I think I have discovered an odd behavior in Filemaker Pro Advanced 8.0v1,
that did not occur in Filemaker Developer 7.0v3, when a solution I developed
crashed. It occurs only in the Windows version, not the MacOS version.

When copying from a field into a pop-up menu field, scripted Copy/paste
hangs (for a while you see the hourglass with ESC under it) and crashes the
program. Need to have data to be copied (blank field does not crash). In
script Paste step, also need to have checked "Select entire contents".

In the script Paste step, turning off "Select entire contents" keeps it from
crashing, but the pasted data then concatenates to whatever is already
there.

This behavior does not occur if the recipient field that you are pasting
into is formatted as a drop-down list. However, then someone can type into
the field using values not from the value list.

As a work-around, changing the format of the recipient field to "Select
entire contents of field on entry", and turning off the "Select entire
contents" in the script Paste step works, but it means changing all
occurrences in the scripts and changing a lot of field formats.

This topic, although not this particular problem was recently talked
about in this newsgroup.

The consensus by everyone is that you shouldn't use copy/paste to set
field values in scripts. Use script parameters, globals, or $variables
to hold your 'temporary' values instead of the clipboard, and use the
"set field" and "set variable" script steps instead of copy and paste.

It is poor programming practice to needlessly erase or tamper with the
contents of the *users* clipboard. For all you know the user has copied
something there that they value!!

Furthermore, why would you expect *pasting* into a popup menu to work in
the first place? While I'm surprised that it actually crashes, and think
you *have* found a bug, I'm not the least bit surprised that it doesn't
work. Popup menus are designed to allow users to select a value from a
list, with no provision to simply enter arbitrary values. I would have
expected filemaker to ignore your paste step entirely and set an error
condition.

I also wouldn't expect a manual paste operation (e.g. Ctrl-V or Apple-V)
to work in a popup menu.

Would you?

I mean, you posted your message with entourage, which uses many popup
menus... go under the Entourage menu into general preferences and switch
to the notifications tab. Try pasting values into the "sound scheme"
popup menu...you can't of course... and it doesn't really even make
sense to try. Which is entirely my point.

best regards,
Dave




In article <BF9EA228.68D8C%trashadd (AT) bigfoot (DOT) com>, trashadd (AT) bigfoot (DOT) com
says...

"42" <nospam (AT) nospam (DOT) com> wrote

I won't go so far as to say that. Only in the case where the field was not
otherwise modifiable should the step be skipped with an error code.

A popup, radio button, etc. are merely "formatting" and have no bearing on
the contents of the field. The Paste command with respect to fields should
be the equivalent of "set the [entire] contents of field X to the clipboard"
(and so on with the other clipboard commands). This is the behavior in prior
versions. It certainly shouldn't cause a crash.

I wouldn't either, but scripts in FileMaker are not like QuicKeys macros.

What if there were two copies of a field on a layout? Are you saying that
FileMaker should skip and return an error because it doesn't know which
version to paste into?

What about "Copy?" It seems to me a perfectly valid construction to have a
"Copy" button next to a popup menu -- for the purpose of say, transferring
the contents of that field to a word processor. You can't Copy from any
popup menus in other programs. Should FileMaker skip and return an error if
you try to do so in a database? No.

It's unambiguous what should happen in both Copy/Cut and Paste cases and the
program should enable you to do it. And it used to. But now it crashes, so
it's a bug. And the user is not an idiot.

The first part about "Copy/Paste = Bad" as a means of internal data exchange
I completely agree with, of course.

Bill

"42" <nospam (AT) nospam (DOT) com> wrote

In article <mJqdnXmWFrGQEuTeRVn-gw (AT) comcast (DOT) com>, wjm (AT) wjm (DOT) org says...
I disagree. Menus, radio buttons, & check boxes are more than mere
"formatting" they fundamentally alter the input method, filtering it
through 'selection' of allowed values instead of directly allowing
actual 'data' to be entered. Copy and Paste operate on 'data' not
'selection'.

Its like the difference between full serve and self serve gas. With self
serve you literally pour the gas into the car (paste data into the
field). With full serve you merely select what type of gas through the
UI widget (the attendant), and he puts the gas in the car. You never
touch actual gas; you just interact with the attendant verbally -- even
if you happen to have actual gas, you can't just pour it onto the
attendant -- he's not set up to take raw data, merely data selections.


A set of radio buttons A,B,C is designed to allow you to enter one of
A/B/C. You can't just go and paste PQRSTUVWXYZ onto a set of radio
buttons.

If the clipboard happened to contain one of A,B, or C it would be slick
if it did the mapping and made the correct selection for you and I'd
support that as a cool feature, but in practice that's not how they
usually work, and even if they did that still doesn't give you carte
blanche to paste arbitrary data.

If that was what the script step was called I'd have no quarrel

But its not. Its called "paste", it requires a field on the layout, it
takes into account the state of the ui widget on the layout -- cursor
position, highlighted text, modifiability, and so on - it clearly is not
the clipboard equivalent of 'set field'.

That's a good question. And all of your comments in the previous few
paragraphs beg another bigger question: Why do the copy and paste script
steps require the field to be on the layout at all, if you beleive they
should simply bypass the UI entirely like "set field", and move data
directly to/from the clipboard to/from the field?

The reality is that they *do* require the field to be on the layout, and
for paste at least it has to be modifiable. This suggests to me that
they are intended to 'filter' the data through the input method of the
UI. Indeed, the benefit we derive from this is that we have access to
work from the cursor position, and the ability to interact with
'highlighted' text within a field. Thus the copy and paste script steps,
imho, really are little more than script versions of ctrl-c, ctrl-v. I
think the analagy to quickeys macros was quite apt.

I suppose you could assert that filemaker "look" for a version of the
field that *is* suitable instead of returning an error if the first one
is no good. But frankly, I'd expect FM to fail after it encounters the
first one... that would be consistent with its handling of go to portal
row with multiple portals on the same layout, the inability to easily
use 'go to field' when there are more than one copy of the field, etc.

As a workaround you could use any of the goto field work arounds to
ensure that the cursor is in the correct version of the field prior to
the copy/paste action.

Sure I agree that could be a natural and useful function.

Freeze window
go to layout with field formatted as text
copy to clipboard
go to original layout


As you say:

**You can't copy/paste from any popup menu in any other program**

Should filemaker's popup menus deviate from a standard that both Mac OS
X *and* Windows (*and* every window manager I've ever used for Linux,
for that matter) adhere to. Of course not.

Rule #1 of UI design: Be consistent.


Is it really that unambiguous?

What should pasting "Hello World" onto a radio button with choices 1,2
and 3 do?

What about pasting: A,B onto a popup menu with the options A,B,C,D? What
about pasting Z into that popup menu? Or the full text of Othello?

FWIW I agree that copy semantics are fairly unambiguous... but its still
disallowed by the ui-widget by both operating systems. And if filemaker
did disallow it, its easy to workaround via the short script I outlined
above.

I agree its a bug. It shouldn't crash.
But I remain unconvinced that it should *ever* have been relied upon to
function in the manner its being used.

I didn't mean to imply that he was, merely that the behaviour he was
expecting, while it worked in previous versions really doesn't follow
the UI model for that type of input widget.

sincerely,
Dave

Here we go with our analogies and hypotheticals again The gas attendant
one really gives me the chuckles.

So you wanna paste Othello into a pop-up menu? Unfortunately, a pop-up item
can only have a maximum of 30,000 characters, so you'll only get the first
fifth of it.

Bill

"42" <nospam (AT) nospam (DOT) com> wrote

In article <N8CdnSBbTq12hufenZ2dnUVZ_sydnZ2d (AT) comcast (DOT) com>, wjm (AT) wjm (DOT) org
says...
Yeah, me too.

-cheers,
Dave

There is only very, very, very rarely a need to paste into a field via a
script. In fact, a scripted find mode is the only example I can think
of right now.

That said, FileMaker is aware of the problem with FM8 in a scripted
paste into a field formatted as drop-down, and it will likely be fixed
in the next update. Probably didn't get caught in pre-release debugging
and testing because that functionality just really isn't used.



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

FileMaker 7 Certified Developer
Associate Member, FileMaker Solutions Alliance

I use Copy/paste to keep the format unchanged - Set Field sometimes changes
it to a non-preferred format.

I paste a value from a value list that has been chosen, into a pop-up menu
that uses the same value list. That way, I don't have to enter the value in
two places. This also gives me the option to select a different value from
the vlaue list in the recipient field, if I choose.

I see your objections to the copy/paste; never gave it a thought (amateur
programmer ...). I may switch the script to use set field instead, based on
these objections. It's just that I have a working solution, and nows it's
broken. Since FileMaker info I have read never recommended against this
practice, I had no idea. (This is why I find this newsgroup very worthy.)

I didn't know FileMaker was aware of the problem, but it seems to affect the
Windows version only, and only with pop-up menus, not drop-down lists. The
drop-down list seems to remain unaffected when I experimented with it.

BTW, Howard, how did you know FileMaker was aware of the problem?

Thanks.


On 11/15/05 12:15 PM, in article 11nkgf3ma0g9l36 (AT) corp (DOT) supernews.com, "Howard
Schlossberg" <howard (AT) antispahm (DOT) fmprosolutions.com> wrote:

On 11/14/05 8:47 PM, in article
MPG.1de3086bc1c2139b989dc2 (AT) shaw....shawcable.net, "42"
<nospam (AT) nospam (DOT) com> wrote:
Why would I expect it to work? I dunno, it seemed logical to me that to
paste a value from a known value list from one field to the other, where the
value list is the same in both fields, would not be a problem. Once again,
it wasn't to enter arbitrary values, just to not have to enter the value in
two places.

Why not just display the same field in both places? Because I sometimes have
to change the recipient field to a different value.

I see your point: a random paste into a menued field should not work, but I
never planned to do that.

Thanks for the constructive criticism.

I've seen the posts here saying it's a bad idea to use the clipboard
and in theory I agree however I haven't found workarounds for common
tasks such as tagging a set of records when the tag uses a global text
field and a calc that just checks if that records ID is in the global
text field.

Assume you have tables A, B, and C, I find I often have to go to
related records from A to B, omit a set of records and possibly add
others, then go to related records in C.
Prior to FM8 I don't see how this was possible without using copy /
paste and even in 8 it's still easier to copy record IDs into a global
then work on the next batch of IDs then put the 2 sets together and
display the records.