Getting viewstate value from readonly textbox in .NET2 (VB)

[ShaneFowlkes]

Hey guys...

I have a form that asks for several dates. I tried using asp calendar
controls to set values of the date textboxes which were readonly. I found
this annoying since each time I advanced a month and/or selected any date,
it posted back and refreshed the page. So, instead, I resorted to an old
javascript function I use a lot. The javascript creates a pop up (html)
window and sets the value of the textbox when the user picks a date. I had
done this many times in ASP.NET1. However, since upgrading to .NET2, I
noticed I was getting errors and the data I was trying to pull and save into
a db from the textboxes was coming up as null.

I did a little research and found out that this was a change made in .NET2.
Readonly textboxes can ONLY get their values from Viewstate or serverside
code, NOT client side like javascripts.

http://forums.asp.net/thread/1134316.aspx

The only way I can get my page to work is to set readonly to false (bad
idea). The above thread suggests that I use a PreRender sub for the
textbox(es). The suggestion is from a guy as MS. However, I added this sub
to my vb code behind file and nothing happened. The textbox is still wide
open.

Protected Sub txtStartDate_PreRender(ByVal Sender As Object, ByVal E As
System.EventArgs)

txtStartDate.Attributes("readonly") = "readonly"

End Sub



Any suggestions or advice? I really would like to use my javascript
calendar pop up functions to set the value of the textbox AND I'd like to
keep the txtboxes to readonly (duh). Any advice?



TIA!

-Shane

 

[Mike]

Sounds like a terrible MS idea. I wonder what their reasoning was?

Anyway, I would try to add a javascript event. try either an onfocus,
that just moves the focus to the calendar. Or an onkeypress that
ignores any keys.

Please let me know how well it works.

Michael Lang
XQuiSoft LLC
http://www.xquisoft.com/

 

[ShaneFowlkes]

So essentially redirect the focus off the textbox fields so they can never
stay in it long enough to type?

 

[Mike]

I found out why it was done. I take back my "terrible idea" comment.
It was to prevent security hacks. A read-only field typically should
not be changed by the user, and thus should not be needed on postback.
Of coarse, your property is not REALLY read-only from a business
perspective, you just want them to use the date-picker. Following are
some workarounds.

"Four Guys" say to use the disabled attribute, and use ASP.NET 2.0's
SubmitDisabledControls property to enable them just before postback.
They don't like the enabled attribute since it isn't on all controls.
http://aspnet.4guysfromrolla.com/articles/012506-1.aspx

"Scott" says you shouldn't read readonly fields and instead reread them
from the database. Good for some data like id's, but not good for your
date picker solution. I recommend others reading this post do not use
the other workarounds that Rick is using for id fields used on
postback. That defeats the purpose of the security fix.
http://scottonwriting.net/sowblog/posts/4965.aspx

"Rick" says to get the read-only value from a field using the request:
this.TextBox1.Text = Request[this.TextBox1.UniqueID];
west-wind.com/weblog/posts/3939.aspx
site was down for me. If it is at the time you read this, see the
google cached version:
http://72.14.203.104/search?q=cache...2.0+textbox+readonly&hl=en&gl=us&ct=clnk&cd=1

Michael Lang
XQuiSoft LLC
http://www.xquisoft.com/

 

[Mike]

yes. and another, maybe better javascript route...

onfocus="this.onblur();"

as suggested by Keith Patton in Rick Strahl's blog.
http://west-wind.com/weblog/posts/3939.aspx

http://blog.keithpatton.com/

Overall, I recommend trying the route in my other post where I
mentioned the 4Guys from Rolla approach.

Michael Lang
XQuiSoft LLC
http://www.xquisoft.com/

 

[ShaneFowlkes]

Thanks for your research. I'll look into it shortly and post my results
back to this thread.

Thanks!

 

[Mike]

Oops, major typo. I meant to say the 4Guys "don't like the readonly
attribute since it isn't on all controls.". The disabled attribute is
on all controls.

 

[bruce barker \(sqlwork.com\)]

a better approach is to have client script set the readonly attribute
instead of the server. this handles the case where client script is
disabled. the user will still be enter the values, even though the
javascript calendar will not work.

i dislike the disable approach, as client script must enable them before
postback and this causes a flicker. also if the postback is slow, the users
can change values and post again.

-- bruce (sqlwork.com)

 

[ShaneFowlkes]

OK...after doing much reading (and confusion), I just decided to leave the
fields wide open. My datepicker served two purposes. 1- For convenience.
2 - Making sure the date was valid date. I'll just have to an additional
server-side edit to make sure the dates are legit. I'm still a little
disappointed in this change...but I guess it's better for security issues.

: /

Thanks for your research. I'll look into it shortly and post my results
back to this thread.

Thanks!

I found out why it was done. I take back my "terrible idea" comment.
It was to prevent security hacks. A read-only field typically should
not be changed by the user, and thus should not be needed on postback.
Of coarse, your property is not REALLY read-only from a business
perspective, you just want them to use the date-picker. Following are
some workarounds.

"Four Guys" say to use the disabled attribute, and use ASP.NET 2.0's
SubmitDisabledControls property to enable them just before postback.
They don't like the enabled attribute since it isn't on all controls.
http://aspnet.4guysfromrolla.com/articles/012506-1.aspx

"Scott" says you shouldn't read readonly fields and instead reread them
from the database. Good for some data like id's, but not good for your
date picker solution. I recommend others reading this post do not use
the other workarounds that Rick is using for id fields used on
postback. That defeats the purpose of the security fix.
http://scottonwriting.net/sowblog/posts/4965.aspx

"Rick" says to get the read-only value from a field using the request:
this.TextBox1.Text = Request[this.TextBox1.UniqueID];
west-wind.com/weblog/posts/3939.aspx
site was down for me. If it is at the time you read this, see the
google cached version:
http://72.14.203.104/search?q=cache...2.0+textbox+readonly&hl=en&gl=us&ct=clnk&cd=1

Michael Lang
XQuiSoft LLC
http://www.xquisoft.com/

 

[ShaneFowlkes]

Last post! =)

On second thought, I'll just use a CompareValidator to ensure the valid
date.

OK...after doing much reading (and confusion), I just decided to leave the
fields wide open. My datepicker served two purposes. 1- For convenience.
2 - Making sure the date was valid date. I'll just have to an additional
server-side edit to make sure the dates are legit. I'm still a little
disappointed in this change...but I guess it's better for security issues.

: /

Thanks for your research. I'll look into it shortly and post my results
back to this thread.

Thanks!

I found out why it was done. I take back my "terrible idea" comment.
It was to prevent security hacks. A read-only field typically should
not be changed by the user, and thus should not be needed on postback.
Of coarse, your property is not REALLY read-only from a business
perspective, you just want them to use the date-picker. Following are
some workarounds.

"Four Guys" say to use the disabled attribute, and use ASP.NET 2.0's
SubmitDisabledControls property to enable them just before postback.
They don't like the enabled attribute since it isn't on all controls.
http://aspnet.4guysfromrolla.com/articles/012506-1.aspx

"Scott" says you shouldn't read readonly fields and instead reread them
from the database. Good for some data like id's, but not good for your
date picker solution. I recommend others reading this post do not use
the other workarounds that Rick is using for id fields used on
postback. That defeats the purpose of the security fix.
http://scottonwriting.net/sowblog/posts/4965.aspx

"Rick" says to get the read-only value from a field using the request:
this.TextBox1.Text = Request[this.TextBox1.UniqueID];
west-wind.com/weblog/posts/3939.aspx
site was down for me. If it is at the time you read this, see the
google cached version:
http://72.14.203.104/search?q=cache...2.0+textbox+readonly&hl=en&gl=us&ct=clnk&cd=1

Michael Lang
XQuiSoft LLC
http://www.xquisoft.com/