TEXT FIELD EXPANSION

[Jeffrey Bloch]

I literally haven't asked this question in 10 years so I'm not sure if there's a solution to it whether new or just forgotten.

When I have a text input field on a layout (height specified to allow viewing of one-line of data only) and the user enters more text than expected, the field opens vertically. Is there a way to always maintain the set dimensions so that as the user types the field contents will scroll horizontally without any changes to the text box?

[comment]

I am not sure I understand your request. If you do not want the field to expand downwards when active to reveal additional text, you can format it to show a vertical scroll bar. If you like, you can choose to show it only when scrolling. 

 

[Jeffrey Bloch]

I don't want to expand or scroll vertically. The field is meant only to hold a person's name which, as you know, could easily extend past the expected/common name length. When this happens and a user is typing an unusually long name, I prefer the text box stays the set dimensions and the visible portion of the name will be the letters currently being typed. In other development languages I've seen where this is possible and holding down an arrow on the keyboard would scroll within the field horizontally to view overflow text.

[comment]

I believe that is the behavior you will get with the settings I mentioned, with one addition: while the field is active and the cursor is within its area, you can also scroll using the mouse wheel.

Personally I don't see what advantage this brings, but maybe that's just me.

 

[Jeffrey Bloch]

I think the confusion is that the scroll bar option is to allow vertical scrolling whereas I want horizontal scrolling. As you'll see in image #3, the text box expands vertically when there's overflow data (more than the dimensions show when unselected). In short, when I click into the field in image #3, I prefer that the borders and size remain exactly the same as when unselected and the user would user arrow keys to scroll horizontally to view data contained within.

[comment]

2 minutes ago, Jeffrey Bloch said:

I think the confusion is that the scroll bar option is to allow vertical scrolling whereas I want horizontal scrolling.

Ah. Indeed I missed that part. I don't believe that's possible with a Filemaker field. Might be possible with a web viewer input.

 

[Jeffrey Bloch]

11 minutes ago, comment said:

I don't believe that's possible with a Filemaker field

Indeed. It's been on developer's wishlists for nearly 20 years.

[Søren Dyhr]

18 hours ago, Jeffrey Bloch said:

Indeed. It's been on developer's wishlists for nearly 20 years.

Really, a database-tool should ideally endorse “one fact per field” and interfacing issues could easily become a nest of  option-itis in eagerness to following each new trend liturgically. Why tear a tool out of, what it's best at? this tool is not a wordprocessor, neither a spreadsheet. Converging technologies are always hyped by salesmen - but in reality is a feature like a can-opener attached to a frying pan of little use for mankind beyond the hypers.

Comment is right in suggesting the use of the web viewer, to accommodate such behaviours - if you turn on developer mode in your web browser are you most likely to meet heavy use of css and implementations of jquery in this particular corner of the example you have shows us, which means that it has not been absent.from the tool at all, just ignored by you.

These could perhaps be a nice places to start: https://www.filemakermagazine.com/videos/zero-awesome-jquery-tools-web-viewers

https://scarpettagroup.com/using-jquery-in-filemaker-part-4/

—sd

Edited February 16, 2024 by Søren Dyhr

[Jeffrey Bloch]

4 hours ago, Søren Dyhr said:

one fact per field

I had to reread your post several times to get an understanding of your points. ‘One fact per field’ is the methodology I subscribe to. People’s names though are of unpredictable length and doesn’t reasonably justify dedicating enough space to satisfy the longest potential need. 
The concept of utilizing a web viewer is over-simplified as web viewers have their own inherent limitations. For instance, I’d have to restructure other functionalities to allow for changing to web viewers; most importantly no other screen element can appear on top of a web viewer which is a trade-off far from acceptable. 

Edited February 16, 2024 by Jeffrey Bloch

[Søren Dyhr]

Only other thing i could think of is autoentering the fontsize, according to length of the wording below. I did at some point see a fonttype laying on its side, this allows rotation of the entire field… 

Edited February 16, 2024 by Søren Dyhr

[comment]

26 minutes ago, Søren Dyhr said:

autoentering the fontsize, according to length

Oh no, please! That would be even worse than the proposed "tunnel vision" type of field, where you need to hold an arrow key in order to scan a person's name. I don't know which "developer's wishlists" this has been on "for nearly 20 years" - it is certainly not on mine.

I believe a person's name should always be displayed in full. This is not difficult to accomplish efficiently with merged fields. And for data entry, you can provide a popover where the field is big enough to comfortably enter even "Wolfeschlegelsteinhausenbergerdorff" (look it up, it's a thing).

 

Edited February 16, 2024 by comment

[Søren Dyhr]

Getlayoutatrribut which plucks the reqired HTML from a position outside the layout containing all the css and jqueries required to paste in both the fields and the overlapning items … must be what this developer needs to perform his rask.

[Jeffrey Bloch]

7 hours ago, comment said:

for nearly 20 years

My wishlist. Browser-based entry fields and apps like FB have a fixed horizontal size. People with last names more than 20 characters should be on MySpace.  ; )