a growing dislike of custom user controls

[V. Jenks]

Long story as short as possible:

I have a page (aspx) that contains a user control
(ascx). In the form the user can enter a username and
password. If they do, the password box auto-posts-back
and checks to see if the user already exists in the
database.

If yes, the rest of the form fields on the page are
populated with that existing user's data.

If no, nothing happens, of course.

Everything works fine until I fire the submit button at
the bottom of the form. In the OnClick event handler for
the button, data is inserted and the user is redirected.

However, the event handler isn't fired first, for SOME
reason, the ontextchanged event handler for the password
box gets fired first, screws up my page, and creates a
bunch of errors.

First of all, why does that event fire when nothing
changes about this particular field that would fire the
event?

By all means, the OnClick event handler should be getting
fired, and it does, but only *after* the OnTextChanged
for the password box is fired (when logically, it
shouldn't have!)

Any ideas?

Thanks ahead of time!

-v

[B0nj]

Probably not much help to you, but I find explicitly configuing custom event/postback requirements for ascx controls is a pain in the arse. I've given up on it. ASP.NET server controls that only do a postback you're fine with, but anything else and you might aswell just copy the html and paste it.

[Kevin Spencer]

Hopefully, the following link should be of some help with your sequence
issue:

http://msdn.microsoft.com/library/de...nLifecycle.asp

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

"V. Jenks" <sp**@scientifik.com> wrote in message
news:55****************************@phx.gbl...

Long story as short as possible:

I have a page (aspx) that contains a user control
(ascx). In the form the user can enter a username and
password. If they do, the password box auto-posts-back
and checks to see if the user already exists in the
database.

If yes, the rest of the form fields on the page are
populated with that existing user's data.

If no, nothing happens, of course.

Everything works fine until I fire the submit button at
the bottom of the form. In the OnClick event handler for
the button, data is inserted and the user is redirected.

However, the event handler isn't fired first, for SOME
reason, the ontextchanged event handler for the password
box gets fired first, screws up my page, and creates a
bunch of errors.

First of all, why does that event fire when nothing
changes about this particular field that would fire the
event?

By all means, the OnClick event handler should be getting
fired, and it does, but only *after* the OnTextChanged
for the password box is fired (when logically, it
shouldn't have!)

Any ideas?

Thanks ahead of time!

-v

[matt]

I'm not sure but if this is relevant by might the root of this problem
in the way password fields are handled? You said the ontextchanged gets
fired even when the password hasn't changed. The password field will
always be blank on the form (as you can't populate a password field with
a value in html), until something is entered in the field. If you set a
value to a password field then it would always be changed unless someone
physically types the same value in to the password box on your form,
otherwise it would be considered to have changed as it will be posted
back as blank.

Not sure if that will be any help or not, but from your message it
sounds like a possible cause.

Matt
http://www.3internet.co.uk
"V. Jenks" <sp**@scientifik.com> wrote in message
news:55****************************@phx.gbl...

Long story as short as possible:

I have a page (aspx) that contains a user control
(ascx). In the form the user can enter a username and
password. If they do, the password box auto-posts-back
and checks to see if the user already exists in the
database.

If yes, the rest of the form fields on the page are
populated with that existing user's data.

If no, nothing happens, of course.

Everything works fine until I fire the submit button at
the bottom of the form. In the OnClick event handler for
the button, data is inserted and the user is redirected.

However, the event handler isn't fired first, for SOME
reason, the ontextchanged event handler for the password
box gets fired first, screws up my page, and creates a
bunch of errors.

First of all, why does that event fire when nothing
changes about this particular field that would fire the
event?

By all means, the OnClick event handler should be getting
fired, and it does, but only *after* the OnTextChanged
for the password box is fired (when logically, it
shouldn't have!)

Any ideas?

Thanks ahead of time!

-v

[V. Jenks]

Yes you can, by adding an attribute to the password
TextBox control (TextBox.Attributes.Add("value", item);)

This is what I'm doing, however, I'm encrypting it so it
can't be viewed by viewing the source.

Anyhow, that's irrelevant. Why isn't the button's click
event firing *first*!?

-----Original Message-----
I'm not sure but if this is relevant by might the root of this problemin the way password fields are handled? You said the ontextchanged getsfired even when the password hasn't changed. The password field willalways be blank on the form (as you can't populate a password field witha value in html), until something is entered in the field. If you set avalue to a password field then it would always be changed unless someonephysically types the same value in to the password box on your form,otherwise it would be considered to have changed as it will be postedback as blank.

Not sure if that will be any help or not, but from your message itsounds like a possible cause.

Matt
http://www.3internet.co.uk
"V. Jenks" <sp**@scientifik.com> wrote in message
news:55****************************@phx.gbl...

Long story as short as possible:

I have a page (aspx) that contains a user control
(ascx). In the form the user can enter a username and
password. If they do, the password box auto-posts-back
and checks to see if the user already exists in the
database.

If yes, the rest of the form fields on the page are
populated with that existing user's data.

If no, nothing happens, of course.

Everything works fine until I fire the submit button at
the bottom of the form. In the OnClick event handler for the button, data is inserted and the user is redirected.
However, the event handler isn't fired first, for SOME
reason, the ontextchanged event handler for the password box gets fired first, screws up my page, and creates a
bunch of errors.

First of all, why does that event fire when nothing
changes about this particular field that would fire the
event?

By all means, the OnClick event handler should be getting fired, and it does, but only *after* the OnTextChanged
for the password box is fired (when logically, it
shouldn't have!)

Any ideas?

Thanks ahead of time!

-v

.

[matt]

Yes good point! Not sure why I had thought the password couldn't have a
value assigned to it, although it's logical that you shouldn't be able
to as you say otherwise it's left to you to ensure any encryption, and
this is why you when you set the Text property that no value attribute
is output.

Having said that I think it's still the root of you problem. Setting
the value attribute using the syntax you mention is different to setting
the text value. It is the Text property of the textbox that is checked
against to determine the ontextchange event.

I suspect that if you change your code to set the Text property of the
password field as well as adding the value attribute to the password
field then you would find the ontextchanged event will not fire for the
password field, if it does then a workaround is to check whether the
button has been clicked.

One other thing I am not sure why you expect the onclick event to always
fire first.

Matt
"V. Jenks" <sp**@scientifik.com> wrote in message
news:5a****************************@phx.gbl...

Yes you can, by adding an attribute to the password
TextBox control (TextBox.Attributes.Add("value", item);)

This is what I'm doing, however, I'm encrypting it so it
can't be viewed by viewing the source.

Anyhow, that's irrelevant. Why isn't the button's click
event firing *first*!?

-----Original Message-----
I'm not sure but if this is relevant by might the root

of this problem

in the way password fields are handled? You said the

ontextchanged gets

fired even when the password hasn't changed. The

password field will

always be blank on the form (as you can't populate a

password field with

a value in html), until something is entered in the

field. If you set a

value to a password field then it would always be

changed unless someone

physically types the same value in to the password box

on your form,

otherwise it would be considered to have changed as it

will be posted

back as blank.

Not sure if that will be any help or not, but from your

message it

sounds like a possible cause.

Matt
http://www.3internet.co.uk
"V. Jenks" <sp**@scientifik.com> wrote in message
news:55****************************@phx.gbl...

Long story as short as possible:

I have a page (aspx) that contains a user control
(ascx). In the form the user can enter a username and
password. If they do, the password box auto-posts-back
and checks to see if the user already exists in the
database.

If yes, the rest of the form fields on the page are
populated with that existing user's data.

If no, nothing happens, of course.

Everything works fine until I fire the submit button at
the bottom of the form. In the OnClick event handler for the button, data is inserted and the user is redirected.
However, the event handler isn't fired first, for SOME
reason, the ontextchanged event handler for the password box gets fired first, screws up my page, and creates a
bunch of errors.

First of all, why does that event fire when nothing
changes about this particular field that would fire the
event?

By all means, the OnClick event handler should be getting fired, and it does, but only *after* the OnTextChanged
for the password box is fired (when logically, it
shouldn't have!)

Any ideas?

Thanks ahead of time!

-v

.