Character Display Limit Text Field/Variable (missing text after 100k)

Hi all,

Windows Pro 10 running 4D v17.2 (I think).

We’ve run into a situation where … If we display a text field or variable on a form and scroll to the bottom of the text area then any text beyond approx. 100,000 characters is not showing.

If I prepend text to it then it still seems to maintain this char. length by deleting text at the bottom.

No code is running?

If I copy the text and paste into TextWrangler all the text is there. Just can’t see anything beyond approx. 100,000 chars. Is this normal?

Anyone seen this? Have a workaround?

Thanks,
John…

Hi John,
I’ve never noticed that limit of 100K, but each time I’ve tried to display a “big” text in a text area, I found it was really too slow to be useable. I use a listbox to display rows from text in that situation.

It was one of those things back in the late 80’s where a note field was added to a table/screen. Then the client wanted to prepend by date and a short description. There was an understood limit of 32k. Or so I thought!

Anyway, changing this text into a listbox would not be easy. What I really need to know is if there is a built in limit that 4D hasn’t made us aware of?

Tks,
John…

Here’s a link to a Knowledge Base Tech Tip which describes your experience as being “reasonable”.

https://kb.4d.com/assetid=77735

Evidently the data is there, you just can’t see it.

Tom Benedict

It has been in the documentation for a while.

https://doc.4d.com/4Dv15/4D/15.6/Field-and-variable-objects.300-3836755.en.html

Under “Display”

Note: Text variables and fields in forms are designed to display contents of a “reasonable” size. Beyond several tens of thousands of characters (depending on the system), only part of the text will be accessible in the form.

The actual limit is 100,000 on Windows, a bit higher (383,046) on Mac. This, as I understand, is to protect the per-window allocated memory space as well as the cost of redraw.

Note that control/command+A to “select all” does select the entire text, even the part that has been truncated for display. You can paste that text at the top or in middle of text that is truncated for display; the full content will be merged. In that sense, a form object is like a “window” that gives you access to the actual text that can be much bigger.

Hi Tom,

Yeah I found that one and showed it to my client. So now they want me to figure out what limits can be changed to.

And yes I know the data is there but not helpful if it cannot be seen.

Appreciate,
John…

Hi Miyako,

Yes I found that doc and the tech tip. The question now is based upon “The documentation mentions this limitation but does not give any precise limits (because the limit can be revised if necessary)”.

The question that’s not answered is if this will actually change the limit on windows beyond the 100k limit? And the only way I can se to change is to change the field from saving in a record to saving in the data file or on disk.

Is that how it works?

Thanks,
John…

I think “changing the limits” in this context means implementing your own lazy loading system that makes sense for the application’s use case, all within the current hard constraint.

Since the guard is on the user interface, the threshold for saving inside record/inside data file/external file is unrelated to this arbitrary limit.

So I guess we need to find an ‘unreasonable’ solution! :wink:

Does a web area have the same limit? Is ‘lazy loading’ easier with a web page? Maybe a Javascript function already exists in some library?

Tom

Hi Miyako,

That makes sense and is kind of what I thought.

I think I need to move them from trying to store a “book”, slight exaggeration, in a text file to saving in a 4D Write Pro area. I can emulate a text field.

Thanks,
John…

Why not to try to use WP for that? As it is a word processor, this limit would be not acceptable, I suppose it works.

I suppose you means Write Pro in “embedded mode”?

I would first make sure if the limitation doesn’t exist there too, before doing anything else.

Hi Miyako,

I was planning on creating a 4D Write Pro area on the form the same size as the text field. No menu’s or layout properties revealed. Just a large white area. A button would need to be rewrite so that it prepended date and time for the next comment.

As to whether or not it can display over 100K… Yes I have to make sure it can do that!!!

Appreciate,
John…

Hi John,
you mean it must be editable by user?

It is actually quite easy. Use TEXT TO ARRAY and hide the gridlines in the listbox. I have implemented one and it looks good. Let me know if you want the code.

Hi Arnaud,

Yes it must be editable and look and act like a a text field. It’s not my desire but the client who has, in my opinion, misused the text field for two decades. They were supposed to use the Diary for capturing and documenting. But I guess they found it easier to use the text field.

Anyway, I will be testing 4D Write Pro without a menu and other doc properties and confirm - per Miyako’ s suggestion - that it can handle large amounts of text. I’m pretty sure it’s not an issue but I haven’t tested yet.

Appreciate,
John…

Hi David,

Yes I know that as I use that command all the time. First it’s not what this client wants and maybe you can sort of get it looking like a text area. But 4D Write Pro seems like a much better solution.

Appreciate,
John…

Hi All,

(WIndows 10 Pro, 4D v17.2)

For those who remember the context…

So I changed the UI to an embedded Write Pro object. On load I get the text field to the WP area and when Saved it is stored back in a text field. So now…

The limitation seems to have increased 122,196 characters. Anything beyond just doesn’t show up.

If I Save the text as a WP document (object) and reopen all the pasted text is displayed.

Both are WP Areas. Why a difference in display characteristics? Is it because “text” versus an object are handled differently by 4D?

I am still trying to avoid converting the text field into an object field. But that might be the answer if I know we can rely upon WP displaying all the text.

Any insights? Thoughts?

Appreciate,
John…

In the form you use, is the original text field still here?
If yes, try to remove it.

Could be a blob field too, and most probably better for network traffic:

  • on close
    wp to text
    text to blob
    compress blob
  • on open
    expand blob
    blob to text
    text to wp

… provided the customer does not request bold and colored text …