System.EventHandler created but event not fired

I'm having this exact same problem:

http://groups.google.com/group/micr...d072e420a5a96ea
I'm having problems with dropdownlists in a random fashion, some of
them work, and some dont, and the code for eventhandler binding is
there.

for example:

private void InitializeComponent()
{
this.cbBranches.SelectedIndexChanged += new
System.EventHandler(this.cbBranches_SelectedIndexC hanged_1);
..
..
..
}

SelectedIndexChanged_1 never gets called
anyone ever solved this?Make sure InitializeComponent is being called. (breakpoint)

Are you setting the AutoPostBack property to True?

If you set it to false, then the code will only run when you do a postback
(which could be several different things triggering a postback)

<lauralucas@.gmail.comwrote in message
news:1154448495.232168.8670@.s13g2000cwa.googlegrou ps.com...

Quote:

Originally Posted by

I'm having this exact same problem:
>
>

http://groups.google.com/group/micr...d072e420a5a96ea

Quote:

Originally Posted by

>
I'm having problems with dropdownlists in a random fashion, some of
them work, and some dont, and the code for eventhandler binding is
there.
>
for example:
>
private void InitializeComponent()
{
this.cbBranches.SelectedIndexChanged += new
System.EventHandler(this.cbBranches_SelectedIndexC hanged_1);
.
.
.
}
>
SelectedIndexChanged_1 never gets called
anyone ever solved this?
>

AutoPostBack property!!! that was it!! thanks a lot!! =D
sloan wrote:

Quote:

Originally Posted by

Make sure InitializeComponent is being called. (breakpoint)
>
Are you setting the AutoPostBack property to True?
>
If you set it to false, then the code will only run when you do a postback
(which could be several different things triggering a postback)
>
>
>
>
<lauralucas@.gmail.comwrote in message
news:1154448495.232168.8670@.s13g2000cwa.googlegrou ps.com...

Quote:

Originally Posted by

I'm having this exact same problem:

http://groups.google.com/group/micr...d072e420a5a96ea

Quote:

Originally Posted by

I'm having problems with dropdownlists in a random fashion, some of
them work, and some dont, and the code for eventhandler binding is
there.

for example:

private void InitializeComponent()
{
this.cbBranches.SelectedIndexChanged += new
System.EventHandler(this.cbBranches_SelectedIndexC hanged_1);
.
.
.
}

SelectedIndexChanged_1 never gets called
anyone ever solved this?

You should go post your new found knowledge at that other post.

To keep making the world a better place.

<lauralucas@.gmail.comwrote in message
news:1154453257.813172.113540@.b28g2000cwb.googlegr oups.com...

Quote:

Originally Posted by

AutoPostBack property!!! that was it!! thanks a lot!! =D
sloan wrote:

Quote:

Originally Posted by

Make sure InitializeComponent is being called. (breakpoint)

Are you setting the AutoPostBack property to True?

If you set it to false, then the code will only run when you do a

postback

Quote:

Originally Posted by

Quote:

Originally Posted by

(which could be several different things triggering a postback)

<lauralucas@.gmail.comwrote in message
news:1154448495.232168.8670@.s13g2000cwa.googlegrou ps.com...

Quote:

Originally Posted by

I'm having this exact same problem:
>
>

http://groups.google.com/group/micr...d072e420a5a96ea

Quote:

Originally Posted by

Quote:

Originally Posted by

Quote:

Originally Posted by

>
I'm having problems with dropdownlists in a random fashion, some of
them work, and some dont, and the code for eventhandler binding is
there.
>
for example:
>
private void InitializeComponent()
{
this.cbBranches.SelectedIndexChanged += new
System.EventHandler(this.cbBranches_SelectedIndexC hanged_1);
.
.
.
}
>
SelectedIndexChanged_1 never gets called
anyone ever solved this?
>

>

System.Net.Webclient screen scraping: how to gracefully handle 403 (and other) er

Understand try/catch generally. What event(s) should I be trying to catch?
Thank you,
-KF
"bruce barker" <nospam@dotnet.itags.org.nospam.com> wrote in message
news:%23F79bSINHHA.3288@dotnet.itags.org.TK2MSFTNGP03.phx.gbl...
> please read chapter on try/catch
> -- bruce (sqlwork.com)
> kenfine@dotnet.itags.org.nospam.nospam wrote:For webclient or HttpWebRequest, it normally will throw a
System.Net.WebException, however, any exception can be handled by the super
class "Exception". So you can use either
try
{
}catch(Exception)
{
}
or
try
{
}catch(WebException)
{
}
Sincerely,
Steven Cheng
Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.

System.Threading.ThreadAbortException and Response.Redirect

I have implemented a log-system for exceptions in an ASP.NET
application using the Application_Error event in Global.asax.
ThreadAbortExceptions gets thrown everytime Response.Redirect is being
used with the second parameter set to true which, according to
Microsoft, is by design...

How do I get around this ? I would hate to have the log filled with
this exception on high-traffic sites. Setting the second parameter to
false is not an option.

I have tried with a try-catch block around the Response.Redirect call,
didnt help, the exception still gets "recorded".A couple options...

a - Don't set the 2nd parameter to true

b - Before logging the exception, check it's type and don't log
ThreadAbortExceptions

Karl

--
http://www.openmymind.net/
http://www.fuelindustries.com/
"Henrik Stidsen" <henrikstidsen@.gmail.comwrote in message
news:1157013808.231659.114100@.e3g2000cwe.googlegro ups.com...
I have implemented a log-system for exceptions in an ASP.NET
application using the Application_Error event in Global.asax.
ThreadAbortExceptions gets thrown everytime Response.Redirect is being
used with the second parameter set to true which, according to
Microsoft, is by design...

How do I get around this ? I would hate to have the log filled with
this exception on high-traffic sites. Setting the second parameter to
false is not an option.

I have tried with a try-catch block around the Response.Redirect call,
didnt help, the exception still gets "recorded".
Karl Seguin [MVP] skrev:

Quote:

Originally Posted by

A couple options...
a - Don't set the 2nd parameter to true

It would certainly be the easy way - but sometimes the world is not
that easy :(

Quote:

Originally Posted by

b - Before logging the exception, check it's type and don't log
ThreadAbortExceptions

Wouldn't I risk to throw out exceptions that I want to log or is
Response.Redirect the only (built-in) function that throws this
Exception ?
No, it isn't the only function, so yes, you'd risk throwing away meaningful
information.

Karl

--
http://www.openmymind.net/
http://www.fuelindustries.com/
"Henrik Stidsen" <henrikstidsen@.gmail.comwrote in message
news:1157030635.410199.270240@.i42g2000cwa.googlegr oups.com...

Quote:

Originally Posted by

Karl Seguin [MVP] skrev:

Quote:

Originally Posted by

>A couple options...
>a - Don't set the 2nd parameter to true

>
It would certainly be the easy way - but sometimes the world is not
that easy :(
>

Quote:

Originally Posted by

>b - Before logging the exception, check it's type and don't log
>ThreadAbortExceptions

>
Wouldn't I risk to throw out exceptions that I want to log or is
Response.Redirect the only (built-in) function that throws this
Exception ?
>

This will give more clarity: http://support.microsoft.com/kb/312629/EN-US/
"Henrik Stidsen" <henrikstidsen@.gmail.comwrote in message
news:1157013808.231659.114100@.e3g2000cwe.googlegro ups.com...
I have implemented a log-system for exceptions in an ASP.NET
application using the Application_Error event in Global.asax.
ThreadAbortExceptions gets thrown everytime Response.Redirect is being
used with the second parameter set to true which, according to
Microsoft, is by design...

How do I get around this ? I would hate to have the log filled with
this exception on high-traffic sites. Setting the second parameter to
false is not an option.

I have tried with a try-catch block around the Response.Redirect call,
didnt help, the exception still gets "recorded".
Siva M skrev:

Quote:

Originally Posted by

This will give more clarity: http://support.microsoft.com/kb/312629/EN-US/

I have read that - it seems the only way to avoid the exception is
this:
Response.Redirect(NewURL, False)
HttpContext.Current.ApplicationInstance.CompleteRe quest()

That seems like a bad workaround... :/