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:
If you tab out of the text field, the scroll position jumps back to 0
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).
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?
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?
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):
replace the selection (string expression) with [attribute yellow (string expression + unusual symbol)]
I like to use micron is µ (right alt+m) or section § (right alt+o).
Commit
Return to field to select µ and delete µ: the cursor will be where the µ was.
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.
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?
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.
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!
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.
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
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.
Like would counting the qty of characters and setting a new selection... these kind of UI issues get me completely obsessed lol