|
Thanks again, Pillai
Joe Pluta wrote:
Last post on this for a while, I am heading out of town.
The text-transform is pretty cool, but it only changes how the data is rendered; it does not change the actual data. Even though it shows as upper case in the field, it will be sent to the host as whatever case was typed. (Don't believe me? Try the HTML at the end of this post.) However, a combination of this and an event that actually changes the text on exiting the field might do the trick. However, that was NOT what you were showing us, Pillai.
The reason, though, that I like doing things one character at a time is that I can filter out unwanted keystrokes as well, in effect acting like a 5250 keyboard shift. Some people like that. I can also easily identify the end of the field and jump to the next field, something HTML doesn't readily do.
My point is that IE allows me to update and/or cancel user events as I see fit, and I wish Mozilla would do the same. If Mozilla would give as much functionality to their DOM as IE does, then I wouldn't have to choose between the two.
Joe
<HTML><HEAD></HEAD><BODY> <form> <input type=text name=joe size=50 length=50 style="text-transform : uppercase;"> <input type=submit> <br> <span onclick="this.innerHTML=joe.value;"> Click here to see the real data </span> </form> </body></html>
achieve :From: Narayanan R Pillai
Pardon my ignorance, I am a bit lost about what we are trying to
In 5250, when I use the DDS keyword, CHECK(LC) lower case charactersare
allowed. In the absence of this keyword, irrespective of the "shift"of
the keyboard, only upper case input is used. I normally achieve thisin
HTML/CSS with the style="text-transform:uppercase;" syntax. And thisis
casesupported on firefox, IE, Netscape and Opera.
I have never tried to dynamically change lower case input to upper
doin a 5250 screen ( I have never had the requirement to do so and whenever casing mattered XLATE was enough to handle most situations ).
Having said this, my question still remains : What am I missing ? What are the ugly workarounds that are required ? and why ?
The only reason I am so interested in this debate, is that we try to
make our applications as browser neutral as possible, although the
company is standardized on IE. And we do this so that the "Internet
Business Development" team does not say that the AS/400 slobs cannot
it, and it does not ( IMHO ) cost us any more to do this correct.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.