5 years ago, RichardSRussel posted a feature request for scrollable, non-editable text fields:
Permit Scrolling in a Non-Enterable (Read-Only) Text Field
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?
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
We simply check the ‘Prohibit modification of value during data entry’ in the field options.
Works very well.
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.
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")
)
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..
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.
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.
Hi Torsten
That’s correct, I was interpreting the following from your existing post.
If you wish for it to be selectively editable, then you’re back to the problem.
Regards
Andy
Yes FileMaker should provide a way to have non-editable text field scrollable . . .
I use a WebViewer as a workaround. Does the job.
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.
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.
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
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)
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.
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)
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.
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.
Yes - but 2 fields wherever viewing the whole content is needed... It would be so cool to have the functionality nativ