# Scrolling in a Non-Enterable (Read-Only) Text Field **URL:** \ **Category:** Lounge (Discussions)\ **Tags:** text-field, scrolling\ **Created:** [November 22, 2020, 9:42am UTC](https://the.fmsoup.org/t/scrolling-in-a-non-enterable-read-only-text-field/1480 "2020-11-22T09:42:45Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Torsten](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/torsten/32/1574_2.png) [@Torsten](https://the.fmsoup.org/u/Torsten)\ **Post date:** [November 22, 2020, 9:42am UTC](https://the.fmsoup.org/t/scrolling-in-a-non-enterable-read-only-text-field/1480/1 "2020-11-22T09:42:45Z")
5 years ago, RichardSRussel posted a feature request for scrollable, non-editable text fields: [Permit Scrolling in a Non-Enterable (Read-Only) Text Field](https://community.claris.com/en/s/idea/0870H000000fyTwQAI/detail) The request features among the top 10 of ‘ideas’. While this is not an available feature, I resort to calculated fields (adding to the data table), especially when the field is required in a portal. Otherwise the web viewer can be handy. How do you implement scrollable, non-editable text fields in layout? ---
**Author:** ![harvest](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/harvest/32/231_2.png) [@harvest](https://the.fmsoup.org/u/harvest)\ **Post date:** [November 22, 2020, 11:20am UTC](https://the.fmsoup.org/t/scrolling-in-a-non-enterable-read-only-text-field/1480/2 "2020-11-22T11:20:02Z")
Hi Torsten, if this can't be avoided I use a popover whose position should not hide the original data. I place a one-fits-all global stored textfield with the required content that is scrollable inside for displaying whatever the user needs. This can be text from a long textfield, content the user wants to copy for reusage, aggregated data from one or more table/record for showing things not in the users data domain... Holger ---
**Author:** ![AndyHibbs](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/andyhibbs/32/3089_2.png) [@AndyHibbs](https://the.fmsoup.org/u/AndyHibbs)\ **Post date:** [November 22, 2020, 11:44am UTC](https://the.fmsoup.org/t/scrolling-in-a-non-enterable-read-only-text-field/1480/3 "2020-11-22T11:44:05Z")
We simply check the ‘Prohibit modification of value during data entry’ in the field options. Works very well. ---
**Author:** ![cheesus](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/cheesus/32/182_2.png) [@cheesus](https://the.fmsoup.org/u/cheesus)\ **Post date:** [November 22, 2020, 12:22pm UTC](https://the.fmsoup.org/t/scrolling-in-a-non-enterable-read-only-text-field/1480/4 "2020-11-22T12:22:44Z")
I'm using two script triggers: the first on field entry, which writes the value of the active field to a global variable. And the second trigger on changing field that resets the field to the global variable and displays a dialog if both values are not identical. ---
**Author:** ![EfficientBizz](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/efficientbizz/32/252_2.png) [@EfficientBizz](https://the.fmsoup.org/u/EfficientBizz)\ **Post date:** [November 22, 2020, 1:59pm UTC](https://the.fmsoup.org/t/scrolling-in-a-non-enterable-read-only-text-field/1480/5 "2020-11-22T13:59:46Z")
> [@Torsten](#): > > Otherwise the web viewer can be handy. That's what I do: // WV html CSS Template "data:text/html," & GetAsCSS ( TextFont ( TextSize ( "Here goes the text either as plaintext, $$Var or as a formula" ; 10) ; "Arial") ) ---
**Author:** ![Markus](https://avatars.discourse-cdn.com/v4/letter/m/b782af/32.png) [@Markus](https://the.fmsoup.org/u/Markus)\ **Post date:** [November 22, 2020, 3:58pm UTC](https://the.fmsoup.org/t/scrolling-in-a-non-enterable-read-only-text-field/1480/6 "2020-11-22T15:58:39Z")
in the early days, we had formula fields for this - today, we are using a trigger (mostly with the name 'DoNotTouch') that refuses changes. If there is the need of change the fields content, we set a $$ variable for bypassing.. ---
**Author:** ![AndyHibbs](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/andyhibbs/32/3089_2.png) [@AndyHibbs](https://the.fmsoup.org/u/AndyHibbs)\ **Post date:** [November 22, 2020, 4:32pm UTC](https://the.fmsoup.org/t/scrolling-in-a-non-enterable-read-only-text-field/1480/7 "2020-11-22T16:32:20Z")
I don’t really see the problem. Using script triggers isn’t viable as drag and drop doesn’t fire the OnObjectEnter script so the field isn’t protected. Preventing entry in browse mode doesn’t allow scrolling Calculation fields just add overheads, web viewers can have display issues. ‘Prohibit modification of value during data entry’ in field options within manage database is a standard feature, the field can be populated by scripts, allows scrolling, doesn’t allow modification and is a one-click solution. ---
**Author:** ![Torsten](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/torsten/32/1574_2.png) [@Torsten](https://the.fmsoup.org/u/Torsten)\ **Post date:** [November 22, 2020, 5:14pm UTC](https://the.fmsoup.org/t/scrolling-in-a-non-enterable-read-only-text-field/1480/8 "2020-11-22T17:14:03Z")
Thank you for sharing this with us. To my understanding, one limitation applies: the field cannot be user-edited at all. For editing, a separate user-editable field is required with scripted transfer of content from and to the field in question. ---
**Author:** ![AndyHibbs](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/andyhibbs/32/3089_2.png) [@AndyHibbs](https://the.fmsoup.org/u/AndyHibbs)\ **Post date:** [November 22, 2020, 6:24pm UTC](https://the.fmsoup.org/t/scrolling-in-a-non-enterable-read-only-text-field/1480/9 "2020-11-22T18:24:31Z")
Hi Torsten That’s correct, I was interpreting the following from your existing post. > [@Torsten](#): > > scrollable, non-editable text fields: If you wish for it to be selectively editable, then you’re back to the problem. Regards Andy ---
**Author:** ![planteg](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/planteg/32/627_2.png) [@planteg](https://the.fmsoup.org/u/planteg)\ **Post date:** [November 22, 2020, 6:52pm UTC](https://the.fmsoup.org/t/scrolling-in-a-non-enterable-read-only-text-field/1480/10 "2020-11-22T18:52:09Z")
Yes FileMaker should provide a way to have non-editable text field scrollable . . . I use a WebViewer as a workaround. Does the job. ---
**Author:** ![Torsten](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/torsten/32/1574_2.png) [@Torsten](https://the.fmsoup.org/u/Torsten)\ **Post date:** [November 22, 2020, 7:14pm UTC](https://the.fmsoup.org/t/scrolling-in-a-non-enterable-read-only-text-field/1480/11 "2020-11-22T19:14:05Z")
Hi Andy, yes, it’s back to square one. The issue is that the ‘scrollable’ property of a (GUI) box showing field content is intrinsically linked to the ‘editable’ property. This design limitation requires workarounds in many solutions. ---
**Author:** ![Torsten](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/torsten/32/1574_2.png) [@Torsten](https://the.fmsoup.org/u/Torsten)\ **Post date:** [November 22, 2020, 7:16pm UTC](https://the.fmsoup.org/t/scrolling-in-a-non-enterable-read-only-text-field/1480/12 "2020-11-22T19:16:38Z")
Thank you, @EfficientBizz. That is a concise way to get the job via WV done! ---
**Author:** ![Torsten](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/torsten/32/1574_2.png) [@Torsten](https://the.fmsoup.org/u/Torsten)\ **Post date:** [November 22, 2020, 7:21pm UTC](https://the.fmsoup.org/t/scrolling-in-a-non-enterable-read-only-text-field/1480/13 "2020-11-22T19:21:15Z")
Hi @Markus, I considered using triggers but came back to boxes with state-controlled properties, using the ‘hide’ functionality in order to work around the limitation. ---
**Author:** ![AndyHibbs](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/andyhibbs/32/3089_2.png) [@AndyHibbs](https://the.fmsoup.org/u/AndyHibbs)\ **Post date:** [November 23, 2020, 8:22am UTC](https://the.fmsoup.org/t/scrolling-in-a-non-enterable-read-only-text-field/1480/14 "2020-11-23T08:22:13Z")
Hi Markus How to you overcome the drag and drop issue of not firing the OnObjectEnter trigger? We’ve looked at this, we didn’t want to use revert record as other edits may have been made that should be kept. Backspace 1 character only works if someone hasn’t pasted something. I’d be interested to hear. Thanks Andy ---
**Author:** ![Markus](https://avatars.discourse-cdn.com/v4/letter/m/b782af/32.png) [@Markus](https://the.fmsoup.org/u/Markus)\ **Post date:** [November 23, 2020, 8:54am UTC](https://the.fmsoup.org/t/scrolling-in-a-non-enterable-read-only-text-field/1480/15 "2020-11-23T08:54:51Z")
it is dependant to the customer. We got the trigger on exit field, not on enter (revert changes). Users are informed (instructions). btw. drag&drop is not activated on that site (custom menu) If that is not possible, I prefer Holger's method (or similar) ---
**Author:** ![AndyHibbs](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/andyhibbs/32/3089_2.png) [@AndyHibbs](https://the.fmsoup.org/u/AndyHibbs)\ **Post date:** [November 23, 2020, 9:59am UTC](https://the.fmsoup.org/t/scrolling-in-a-non-enterable-read-only-text-field/1480/16 "2020-11-23T09:59:03Z")
I guess it would be possible to create a list of of fields and set their contents in JSON using OnRecordLoad and FieldNames (), then be able to refer back in the event of a change. However, the lack of OnRecordUnload or OnRecordExit script trigger again makes this difficult. ---
**Author:** ![Markus](https://avatars.discourse-cdn.com/v4/letter/m/b782af/32.png) [@Markus](https://the.fmsoup.org/u/Markus)\ **Post date:** [November 23, 2020, 11:06am UTC](https://the.fmsoup.org/t/scrolling-in-a-non-enterable-read-only-text-field/1480/17 "2020-11-23T11:06:50Z")
that would be something like an audit system (MBS has that functionality, basicly) it's also a question of e&b (effort and benefit). For our needs in some of the customers solution, the 'on field exit' method is quite ok. The 'audit' method would be a bigger effort What's about of defining a role that allows field edit only under some circumstances? (will be tricky if based on one field) ---
**Author:** ![AndyHibbs](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/andyhibbs/32/3089_2.png) [@AndyHibbs](https://the.fmsoup.org/u/AndyHibbs)\ **Post date:** [November 23, 2020, 11:41am UTC](https://the.fmsoup.org/t/scrolling-in-a-non-enterable-read-only-text-field/1480/18 "2020-11-23T11:41:55Z")
None of it is easy if you wish conditional editing, then the scrolling is a problem a and all the work around are needed. We primarily use scrolling uneditable fields for features such as audit logs, which are all populated by scripts. Hence, the prohibit modification suggestion above is a very easy way of achieving this. Due to the drag and drop issue, which is available to switch on/off in Edit Preferences, which is also where the default User Name is stored, trying to protect a field using triggers can’t be 100%. The use of a calculation field or web viewer would be safer. ---
**Author:** ![Cecile](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/cecile/32/98_2.png) [@Cecile](https://the.fmsoup.org/u/Cecile)\ **Post date:** [November 23, 2020, 12:02pm UTC](https://the.fmsoup.org/t/scrolling-in-a-non-enterable-read-only-text-field/1480/19 "2020-11-23T12:02:32Z")
You could stack 2 same field(s), one locked for editing and scroll bar set to never and the unlocked one below with scroll bar always so that the scroll bar is unobstructed. That will prevent drag and drop. ---
**Author:** ![Markus](https://avatars.discourse-cdn.com/v4/letter/m/b782af/32.png) [@Markus](https://the.fmsoup.org/u/Markus)\ **Post date:** [November 23, 2020, 12:15pm UTC](https://the.fmsoup.org/t/scrolling-in-a-non-enterable-read-only-text-field/1480/20 "2020-11-23T12:15:55Z")
Yes - but 2 fields wherever viewing the whole content is needed... It would be so cool to have the functionality nativ [Next page](https://the.fmsoup.org/t/scrolling-in-a-non-enterable-read-only-text-field/1480.md?page=2)