July 12, 200817 yr I would like to allow a filemaker user to enter a field in order to be able to copy the contents for a later paste into a different application. I don't want the user to be able edit the field or change it by mistake. I guess I could create a button for copy to the clipboard and leave the field not enterable in browse mode, but that seems a poor work around especially if I want all fields to behave the same way. Is there some secret filemaker dialog box that allows you to enter a field in browse mode and copy but not modify the data? Thanks - Mark Using FM 9 advanced on OSX
July 12, 200817 yr Hi a way is to put, in the layout where the user has to copy the contents of the field "yourField", NOT the real field but a calculated one with calc: yourField
July 13, 200817 yr Hi Mark, I would much rather turn off entry to a field than create a calculation of it just to restrict entry!! And, with many fields, turning EACH into a calculation just to restrict entry is a bit much! Here's another option (see attached). Regardless, you will have a bit of work to do but I think this would be simpler. I added the paste into another field just to show the clipboard contents. It, of course, wouldn't be necessary in the final solution. LaRetta CopyOnly.zip
July 18, 200817 yr Author Thank you LaRetta for your example file. I think your example will work. Still I wish it was a native function of Filemaker, I guess it's time for a feature request. Thanks Too Daniele, that would certainly work, don't know about the "elegant" aspect of that approach. - Your english is just fine by the way. cheers, Mark
July 18, 200817 yr As a user, I wouldn't consider having to type the field name just to copy it as "elegant". with many fields, turning EACH into a calculation just to restrict entry is a bit much! That's why I joined: http://fmforums.com/forum/showtopic.php?tid/190245/ DisplayFields.fp7.zip
July 18, 200817 yr Now that is just plain sweet! It feels like Choose() Oh! IT *is* Choose(). Man, it's been a long night ... But Repeaters sure rock!!! Edited July 18, 200817 yr by Guest Changed 'such' to 'sure'. geez
July 18, 200817 yr As long as I am at it - this is how I would implement your idea: DisplayFields2.fp7.zip
July 18, 200817 yr Well there are all kinds of goodies here to explore but ... since it is calc and you had 'select all' on the field, CTRL-C would work just as well. Of course I don't need to tell YOU that but ... I guess I just did anyway. Ha ha! It feels like you complicated your own solution! Edited July 18, 200817 yr by Guest
July 18, 200817 yr Oh wait ... if you complicated your own solution to show me how you would implement MY solution then I guess it is saying that MY solution was ... uhm, over complicated. :jester:
July 18, 200817 yr I'm afraid you are missing the point: this (second) file does NOT use calculation fields, or any extra fields at all - the display-only fields are the same fields with entry disabled.
July 18, 200817 yr Oh, yes, I see, thanks for making that clear. But your point was ... it isn't elegant to take the time to attach an object to each field, so instead you attach a script parameter and turn off entry to each field? Well, it'll probably all make more sense after sleep. :wink2:
July 6, 200916 yr Newbies Hi Mark I was just looking for a good way to do this myself, and stumbled on your post. Here is my little idea; it is based on using script triggers in FM10. Have a look at the attached file: it uses one OnObjectEnter trigger script in browse mode that switches to find mode and allows the user to do whatever s/he wants with the content (copy, cut) until they leave the field again. The OnObjectExit script then does not complete the find operation but simply switches back to browse mode. The good thing about this method is that you can attach the _same_ two scripts and triggers to any field you like, on any layout you like. The bad thing is that you have to "mock-enter" find mode in the process, which may confuse users unless your solution (or at least the particular layout) hides the status bar. Also, the fact that the field reverts to its previous value even if the user performs a "cut" operation may not be the best user feedback practice... Hmm, I have to think about this a little more... Cheers, V. DisplayFieldsVogel.zip
July 6, 200916 yr Script triggers do change the way we solve a lot of problems. But I wouldn't use Find mode to achieve this. I'd load the field name and contents into global variables on field entry and then back into the field on exit.
Create an account or sign in to comment