RE: Development standards for the World -- MIDRANGE-L

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>
 

> From: Narayanan R Pillai
> 
> Pardon my ignorance, I am a bit lost about what we are trying to
achieve :
> 
> In 5250, when I use the DDS keyword, CHECK(LC) lower case characters
are
> allowed. In the absence of this keyword, irrespective of the "shift"
of
> the keyboard, only upper case input is used. I normally  achieve this
in
> HTML/CSS with the style="text-transform:uppercase;" syntax. And this
is
> supported on firefox, IE, Netscape and Opera.
> 
> I have never tried to dynamically change lower case input to upper
case
> in 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
do
> it, and it does not ( IMHO ) cost us any more to do this correct.

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.