# Control Scrolling in Edit Field **URL:** \ **Category:** Questions\ **Created:** [May 9, 2021, 7:32pm UTC](https://the.fmsoup.org/t/control-scrolling-in-edit-field/2093 "2021-05-09T19:32:35Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![xochi](https://avatars.discourse-cdn.com/v4/letter/x/0ea827/32.png) [@xochi](https://the.fmsoup.org/u/xochi)\ **Post date:** [May 9, 2021, 7:32pm UTC](https://the.fmsoup.org/t/control-scrolling-in-edit-field/2093/1 "2021-05-09T19:32:36Z")
I have a calculated field which often contains several pages of styled text, so the vertical scroll bar is in heavy use. The user can select portions of the text, and with a keystroke (using script Triggers) change the style (for example, typing the H key will Highlight the selected text, turning it yellow). This works great but for these issues: 1. If you tab out of the text field, the scroll position jumps back to 0 2. I'm unable to get the field to refresh (no combination of Refresh Window, Refresh Object, etc. seems to work). The only solution is to exit the field (Go to Next Field) and then re-select the field. But this alters the scroll position (see #1). 3. Using script triggers, I am able to save and restore the text selection (so if you tab out and then tab back in, your selection is not lost) however the scroll position is always lost. @MonkeybreadSoftware : is this something you can help with? A way to set/restore the scroll position of a field? Anyone found a way to make this work? ---
**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:** [May 9, 2021, 7:49pm UTC](https://the.fmsoup.org/t/control-scrolling-in-edit-field/2093/2 "2021-05-09T19:49:54Z")
Why do you need it to refresh? To commit the change but let user continue to scroll and annotate that field? ---
**Author:** ![xochi](https://avatars.discourse-cdn.com/v4/letter/x/0ea827/32.png) [@xochi](https://the.fmsoup.org/u/xochi)\ **Post date:** [May 9, 2021, 9:04pm UTC](https://the.fmsoup.org/t/control-scrolling-in-edit-field/2093/3 "2021-05-09T21:04:18Z")
Correct, the user hits the H key to highlight the text, and a script runs which updates a related table (basically, it incluces the selection start, selection length, and attribute "yellow). I seem to be unable to convince FileMaker to actually update the field, as long as the field is selected and the cursror is within the field. I just realized that the field in question, though a calculated field set to "do not store calculation results" is also in a related table, not the base table that the layout is showing. I'll have to play with some options and see if that's part of the issue? Example: - user selects text in field: - user hits the H key - script runs and highlights the text with yellow - however, the field does not update (not shown) - the script then exits the field using Go To Next Field and then comes back to the field, and finally the field updates: ---
**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:** [May 9, 2021, 11:15pm UTC](https://the.fmsoup.org/t/control-scrolling-in-edit-field/2093/4 "2021-05-09T23:15:20Z")
To commit the change requires the field to loose focus. What I suggest you do is modify your script to something like the following (note that I haven't tried): 1. replace the selection (string expression) with [attribute yellow (string expression + unusual symbol)] 2. I like to use micron is µ (right alt+m) or section § (right alt+o). 3. Commit 4. Return to field to select µ and delete µ: the cursor will be where the µ was. ---
**Author:** ![Malcolm](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/malcolm/32/196_2.png) [@Malcolm](https://the.fmsoup.org/u/Malcolm)\ **Post date:** [May 9, 2021, 11:39pm UTC](https://the.fmsoup.org/t/control-scrolling-in-edit-field/2093/5 "2021-05-09T23:39:57Z")
Related data is not refreshed often. This is a performance oriented behaviour. If you create new related information and it affects the a calculated field that is in the related record set, then you will need to trigger an update. You may need to do something like, open a new window offscreen, touch the related record there to force that record to update, then return control to your editing window. ---
**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:** [May 10, 2021, 12:02am UTC](https://the.fmsoup.org/t/control-scrolling-in-edit-field/2093/6 "2021-05-10T00:02:46Z")
> [@xochi](#): > > If you tab out of the text field, the scroll position jumps back to 0 I am not in front of the computer to check that but if I remember correctly, this can be disabled in the portal setup dialogue. Wondering if the same option is available for regular fields scrollbar? ---
**Author:** ![xochi](https://avatars.discourse-cdn.com/v4/letter/x/0ea827/32.png) [@xochi](https://the.fmsoup.org/u/xochi)\ **Post date:** [May 10, 2021, 12:03am UTC](https://the.fmsoup.org/t/control-scrolling-in-edit-field/2093/7 "2021-05-10T00:03:21Z")
> [@Cecile](#): > > Return to field to select µ and delete µ: the cursor will be where the µ was. That's more or less what I'm doing, but the problem is that although the selection point can be restored (so the cursor is where the user last had it), the field's scroll position is lost. > [@Cecile](#): > > I am not in front of the computer to check that but if I remember correctly, this can be disabled in the portal setup dialogue. Wondering if the same option is available for regular fields scrollbar? Good idea - I should give that a try - there is zero need for a portal, but if the portal exposes the "don't scroll" behavior, it might work to put the field inside a portal showing 1 record. My memory of this feature is that it affects the scroll position of the portal, not necessarily the scroll position of fields within the portal. Worth a test in any case! ---
**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:** [May 10, 2021, 12:07am UTC](https://the.fmsoup.org/t/control-scrolling-in-edit-field/2093/8 "2021-05-10T00:07:20Z")
If you hit the right arrow right after the cursor is back in the field, does the scroll updates? ---
**Author:** ![xochi](https://avatars.discourse-cdn.com/v4/letter/x/0ea827/32.png) [@xochi](https://the.fmsoup.org/u/xochi)\ **Post date:** [May 10, 2021, 12:10am UTC](https://the.fmsoup.org/t/control-scrolling-in-edit-field/2093/9 "2021-05-10T00:10:47Z")
It does scroll so that the selected text is visible, but this behavior puts the selected text at the bottom of the edit field, not necessarily the same scroll position as the user may have been viewing. So it doesn't really do the job. ---
**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:** [May 10, 2021, 12:18am UTC](https://the.fmsoup.org/t/control-scrolling-in-edit-field/2093/10 "2021-05-10T00:18:22Z")
Did you try Malcolm’s suggestion? When you reactivate the original window do you lose the scroll position? Now I am having all sorts of ideas I would like to try but not 👩‍💻 Like would counting the qty of characters and setting a new selection... these kind of UI issues get me completely obsessed lol ---
**Author:** ![steve\_ssh](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/steve_ssh/32/160_2.png) [@steve\_ssh](https://the.fmsoup.org/u/steve_ssh)\ **Post date:** [May 10, 2021, 2:26am UTC](https://the.fmsoup.org/t/control-scrolling-in-edit-field/2093/11 "2021-05-10T02:26:44Z")
> [@Malcolm](#): > > You may need to do something like, open a new window offscreen, touch the related record there to force that record to update, then return control to your editing window. I like this suggestion of doing the update in a separate window. As @Malcolm said, this could be an offscreen window. I also have friends who would reach for PSOS if this happens to be a hosted solution, and another option may be available if this is a separation model, which is to trigger a script in the (usually hidden) data file. I might also consider a strategy that presents the scrolling text in a WebViewer, but I readily admit that this would require a certain amount of effort to set up to reach parity with what you already have. That said, once that point is reached, you might be able to solve the scrolling issue without much additional work. I'll put it this way: While I am not advocating that a WV would be best for you (I am not convinced that it is), if it were me, it would be among the options that I would consider. HTH.