<textarea> content size causing submit buttons to be inactive in XY HTML form

[Dustydog]

What kind of limit am I running into here?

My form works perfectly until the text data in the textarea passes a certain point, which causes the submit buttons to become inactive until I delete the contents of, or reduce the text data in, the textarea.

I'm trying to read a shortish size file, see the information in a larger form, and possibly edit the text data for the file that was read into the textarea and write it back if I made any changes. (As kind of a side feature to what I'm doing.)

(I don't think posting the long code involved would be useful. I've been careful, and it works fine if the text file read for the initial data is small enough or I reduce the length once it's displayed. It's never very long.)

What other pitfalls might I not be aware of with things like this, using XY's HTML feature?

And what conversions happen to the text encoding going from a file (sometimes ASCII, sometimes UTF-8 or Windows 1252, sometimes something else) to an XY HTML form, then back to a file using readfile -> variable -> HTML form -> variable -> writefile?

Is the limit I'm bumping into a byte limit? Should I try to convert the text at some point to something compact like ASCII to give myself more room? Or does using HTML and XY force other defaults on me that I can't really get around?

I'm sorry if this is documented somewhere and I missed it. Thank you in advance to anyone who takes the time to comment.

[highend]

No code = no comment

Additionally, provide a text file that leads to that issue and one that does not...

[Dustydog]

Well, it's not just the textarea, but the entire length of the return string. Just filled in a couple of text boxes to great length, and that does it too.

[Dustydog]

So, I guess the short question is: What is the maximum length of the return string one can get from an XY HTML form?

[highend]

Again, no code = no comment...

[Dustydog]

"No code = no comment."

There's no reason for that, and I found it a bit, well, it doesn't matter.

All that's going on is it's a fairly large form with some text boxes and a textarea (along with a some check boxes). I'm evidently running into a maximum length for the total return string that I wasn't aware existed. I'll figure it out for myself. You obviously are unaware of a string length limit yourself.

Code wouldn't have helped - it's the length of the of the return string that matters. The code runs fine as long as the return string doesn't bump into this mysterious limit. The entire script is very long, over-commented, contains debugging code, and is certainly in an alpha stage. It's also something that's only of use to myself. The html code could be more elegantly laid out, but it's correctly written. I'll polish it later. The return variables are created properly (and dynamically) and have no problems at all after the form actually submits.

All that happens is if the return string is too long, the form submit buttons on the form do not do anything except show that they're being pressed until the amount of data contained in the form is reduced below this limit. I'm not sure if text encoding matters anywhere and it's a byte limit, or if it's a character limit (I suspect character limit). I don't know enough about how HTML forms work. I thought it was just the textarea until a logical error in my code returned quite a lot of text in some text boxes (my regexes were returning a full-length "haystack" in an outlying case that, when stacked together, were inserting quite a lot of text), which produced the same problem, and had the same solution: Reduce the amount of data in the form - which I can do interactively, i.e. first the submit buttons don't do anything, then they work fine after some interactive deletions.

It was confusing to me because I thought it was just the textarea as the text boxes generally had a similar amount of data in them. I thought perhaps the textarea was changing size based on its text encoding at first - now, I think it's probably a character count, so I'll test for that. If that changes, I'll test for byte size.

You're a bright, knowledgeable man who's very good at this. Your assistance would have been appreciated even if it were, "I'm not sure if there's a limit. Better test the entire return string size." Or, "Text encoding all gets changed to ***** in an html form regardless of what it was originally." Or, "Well, since it's all run through XY before it goes in the form, text encoding will be the same." Or, "It's a byte count limit, and text encoding does matter." Or, "You need to use URL encoding even if it looks funny within your text areas. It could be that." Or, "There are certain illegal characters that could be in your return string that you have to watch out for."

I'm not a stupid man. I did quite a lot of things to try to figure this out on my own and got frustrated before posting as I was operating under a misconception about what the problem was. I tried things like removing all characters that weren't a \w, limiting the size of the data in the textarea when creating the form, cutting the text from the textarea, changing the encoding, and pasting it back, reducing the total form size before display, and etc. etc. I also grepped the help pdf and change file in quite a few ways looking for an answer, as well as looking on the net at large.

You've been very helpful in the past. Thank you for that. I use some of your scripts, or portions thereof, thank you for that too. And thank you for your time monitoring this forum.

[highend]

You could have written just some simple test code to find the maximum return string length...

Code: Select all

    $count = 2067;

    $content = strrepeat("a", $count);

    $html = <<<>>>
<html>
    <body>
        <form method="get" action="xys:">
            <textarea name="c" cols="85" rows="27">$content</textarea>
            <input type="submit" name="submit" value="S"
        </form>
    </body>
</html>
>>>;

    $result = html($html, 800, 600, "Return limit...");
    text "Limit: " . strlen($result) . " chars...<crlf 2>String:<crlf>" . $result;

Raise the $count limit...

[Dustydog]

Here are my results:

STRLEN HTML RETURNED SUCCESSFULLY:

Total for Form: 9321
Characters in String Returned: 2079
Bytes, writefile "r": 4,158

***
Another file had the same approximate character count (that one was approximately strlen 2075), but I didn't check the byte count.
***
XY often throws an error if it submits precisely on the first character after deleting one at a time until it submits, i.e. delete one more character and it's fine:

"The webpage cannot be displayed
Most likely cause:
Some content or files on this webpage require a program that you dont have installed.
What you can try:
Search online for a program you can use to view this web content.
Retype the address.
Go back to the previous page"

[highend]

Bytecount? For what?

Form return values are encoded. The string len matters. Chars that
need to be encoded enlarge the return value. Instead of returning
¥, you'll get %C2%A5 which effectively reduces the amount of
possible input chars by factor 6...

[Dustydog]

And yes, I use test code all the time, of course.

[Dustydog]

I don't know for what, but I thought it would be interesting. Certainly didn't take much time to look at.

[admin]

Interesting, here the highest value that allows for a return is 2062.

Code: Select all

$count = 2062;

No idea why. Has nothing to do with XYplorer.

[Dustydog]

So, basically, the final answer is approximately <2080 characters of url encoded text at two bytes per character. For some things, this is pretty short.

So, to estimate if a form is likely to submit, and if it's primarily an informational form that may or may not require editing in several fields,one would need to add together the seeded information, after using urlencode, add variable lengths (the shorter the better if there are quite a few, which was a place I personally saved quite a bit of submit data), add an additional character for the '=' for variables if there are enough to bother, and add in an estimate of how much the form is likely to grow at maximum. (Also, don't have unnecessary check boxes selected by default or return values that are longer than absolutely necessary for check boxes, radio buttons, etc. Reducing redundancy in some text boxes was another area where I personally saved space. Automating appropriate edits with a check box, or marking those that were made view-only for later editing could also save space.)

Within XY, if it looks like it may be too large, changing the html dynamically to make some of the content simply for display (if you do need to see it) and editing it at a different point - such as a textarea block - as there's no limit on display length, would be another reasonable technique. (Using the 'disabled' attribute dynamically would be one easy way.) One could also use the maxlength attribute in some of the fields - possibly dynamically, based on how large the form is.

(Apparently using java to intercept submit doesn't work, and I know so little Java that I can't get very creative with it at this point. I'm also pretty clueless as to what to expect will work and won't with Java within XY - it's kind of try it and see for me. I wish I knew more about what I could get it to do here. If anyone has some insight, it would certainly be appreciated.)

[Dustydog]

No clue either, admin, which is why I used my own form to count bytes rather than just shove data into a single field. Wanted to see where I was wasting space partly - and anything else unusual that I didn't know about.

[highend]

Or just use multiple forms...
Java? You mean javascript. XY uses the IE engine so everything that works
within that browser should work within a XY form