473,320 Members | 1,799 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Another GridView Bug -> PagerSettings.Visible

The PagerSettings.Visible property is not being handled properly by the
GridView control.
The value assigned to this property is not applied until after a postback.
Simplest test :
.aspx containing a single gridview - enable paging and give enough data
to page.
add checkbox with auto postback enable
add button with auto postback enable
in the GridView1_PreRender method add the following :
GridView1.HeaderRow.Enabled =
GridView1.PagerSettings.Visible =
CheckBox1.Checked;
note that the header should be enabled when the pager is visible and the
header should be disabled whetn the pager is hidden.

When you 1st view the page the header is disabled ( correct ) and the pager
is visible ( incorrect )
click the button and now the the header is disabled ( correct )and the pager
is hidden ( correct )
click the button as many times as you like , things remain as they shoud be.

Click the checkbox - now the header is enabled ( correct ) and the pager is
still hidden ( incorrect )
click the button and now the the header is enabled ( correct ) and the pager
is visible (correct )
click the button as many times as you like , things remain as they shoud be.

repeated clicking of the checkbox results in the header and pager being in
opposite 'phase'.

Having written my share of custom web controls, it is pretty obvious what
the problem is.
Has this been fixed with SP1 ? I am currently trying to install the update
but after about 6 hours I am not having much success.
Gerry
Feb 23 '07 #1
8 7696
Gerry,
You should look for this in the Product Feedback site, for a couple of
reasons:
1) other people may have already submitted it (or something very similar)
and you can see the status of the alleged "bug" - including workarounds, if
any.
2) If it's a legitimate bug and nobody has submitted it, you have the honor
of being the first.

This page lists the different feedback sites by technology:

http://connect.microsoft.com/Main/co...ContentID=2220

Cheers,
Peter

--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net


"gerry" wrote:
The PagerSettings.Visible property is not being handled properly by the
GridView control.
The value assigned to this property is not applied until after a postback.
Simplest test :
.aspx containing a single gridview - enable paging and give enough data
to page.
add checkbox with auto postback enable
add button with auto postback enable
in the GridView1_PreRender method add the following :
GridView1.HeaderRow.Enabled =
GridView1.PagerSettings.Visible =
CheckBox1.Checked;
note that the header should be enabled when the pager is visible and the
header should be disabled whetn the pager is hidden.

When you 1st view the page the header is disabled ( correct ) and the pager
is visible ( incorrect )
click the button and now the the header is disabled ( correct )and the pager
is hidden ( correct )
click the button as many times as you like , things remain as they shoud be.

Click the checkbox - now the header is enabled ( correct ) and the pager is
still hidden ( incorrect )
click the button and now the the header is enabled ( correct ) and the pager
is visible (correct )
click the button as many times as you like , things remain as they shoud be.

repeated clicking of the checkbox results in the header and pager being in
opposite 'phase'.

Having written my share of custom web controls, it is pretty obvious what
the problem is.
Has this been fixed with SP1 ? I am currently trying to install the update
but after about 6 hours I am not having much success.
Gerry
Feb 23 '07 #2
Hi Gerry,

In addtion to Peter's comments, whilst data has been bound, all rows have
been already created based on values you provider at the binding stage (if
PagerSetting.Visible was set to false, pager was not rendered, and even if
you change it to true later in page execution it won't force gridview to show
pager). It's also true for postback, because gridview rebuilds itself based
on information stored in viewstate. To resolve the problem, you need to
rebind the data again:

// if autpostback is set to true you can handle CheckChanged event
protected void myCheckBox_CheckedChanged(object sender, EventArgs e)
{
bool checked = ((CheckBox) sender).Checked;

myGridView.PagerSettings.Visible = checked; // or !checked;
myGridView.DataSource = dataSource;
myGridView.dataBind();
}

Hope this helps

--
Milosz
"Peter Bromberg [C# MVP]" wrote:
Gerry,
You should look for this in the Product Feedback site, for a couple of
reasons:
1) other people may have already submitted it (or something very similar)
and you can see the status of the alleged "bug" - including workarounds, if
any.
2) If it's a legitimate bug and nobody has submitted it, you have the honor
of being the first.

This page lists the different feedback sites by technology:

http://connect.microsoft.com/Main/co...ContentID=2220

Cheers,
Peter

--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net


"gerry" wrote:
The PagerSettings.Visible property is not being handled properly by the
GridView control.
The value assigned to this property is not applied until after a postback.
Simplest test :
.aspx containing a single gridview - enable paging and give enough data
to page.
add checkbox with auto postback enable
add button with auto postback enable
in the GridView1_PreRender method add the following :
GridView1.HeaderRow.Enabled =
GridView1.PagerSettings.Visible =
CheckBox1.Checked;
note that the header should be enabled when the pager is visible and the
header should be disabled whetn the pager is hidden.

When you 1st view the page the header is disabled ( correct ) and the pager
is visible ( incorrect )
click the button and now the the header is disabled ( correct )and the pager
is hidden ( correct )
click the button as many times as you like , things remain as they shoud be.

Click the checkbox - now the header is enabled ( correct ) and the pager is
still hidden ( incorrect )
click the button and now the the header is enabled ( correct ) and the pager
is visible (correct )
click the button as many times as you like , things remain as they shoud be.

repeated clicking of the checkbox results in the header and pager being in
opposite 'phase'.

Having written my share of custom web controls, it is pretty obvious what
the problem is.
Has this been fixed with SP1 ? I am currently trying to install the update
but after about 6 hours I am not having much success.
Gerry

Feb 24 '07 #3
I'm not sure if you are saying that this not a bug - if so i beg to disagree
or at least to say that this a very very poor design.
Why handle the PageSettings property any different than any other property
on the control ? We can set any other property in PreRender and have it take
effect on the current request without requiring a post back or a rebind.
The real problem is that the designers of this control decided to treat the
PagerRow different than the other non-data rows - HeaderRow & FooterRow.
My workaround for this was to have the PagerSettings.Visible property always
set to true ( which should not be required ) and capture the pager row
object in the RowCreated event, then I use this PagerRow object to set pager
visibility rather than the PagerSettings property whihc is then consistant
with how we handle the properties of the HeaderRow & FooterRow.
The PagerRow should have been setup as an exposed property the same as
HeaderRow & FooterRow - I don't see any good reason why it wasn't.

Gerry

"Milosz Skalecki [MCAD]" <mi*****@DONTLIKESPAMwp.plwrote in message
news:BB**********************************@microsof t.com...
Hi Gerry,

In addtion to Peter's comments, whilst data has been bound, all rows have
been already created based on values you provider at the binding stage (if
PagerSetting.Visible was set to false, pager was not rendered, and even if
you change it to true later in page execution it won't force gridview to
show
pager). It's also true for postback, because gridview rebuilds itself
based
on information stored in viewstate. To resolve the problem, you need to
rebind the data again:

// if autpostback is set to true you can handle CheckChanged event
protected void myCheckBox_CheckedChanged(object sender, EventArgs e)
{
bool checked = ((CheckBox) sender).Checked;

myGridView.PagerSettings.Visible = checked; // or !checked;
myGridView.DataSource = dataSource;
myGridView.dataBind();
}

Hope this helps

--
Milosz
"Peter Bromberg [C# MVP]" wrote:
>Gerry,
You should look for this in the Product Feedback site, for a couple of
reasons:
1) other people may have already submitted it (or something very similar)
and you can see the status of the alleged "bug" - including workarounds,
if
any.
2) If it's a legitimate bug and nobody has submitted it, you have the
honor
of being the first.

This page lists the different feedback sites by technology:

http://connect.microsoft.com/Main/co...ContentID=2220

Cheers,
Peter

--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net


"gerry" wrote:
The PagerSettings.Visible property is not being handled properly by the
GridView control.
The value assigned to this property is not applied until after a
postback.
Simplest test :
.aspx containing a single gridview - enable paging and give enough
data
to page.
add checkbox with auto postback enable
add button with auto postback enable
in the GridView1_PreRender method add the following :
GridView1.HeaderRow.Enabled =
GridView1.PagerSettings.Visible =
CheckBox1.Checked;
note that the header should be enabled when the pager is visible and
the
header should be disabled whetn the pager is hidden.

When you 1st view the page the header is disabled ( correct ) and the
pager
is visible ( incorrect )
click the button and now the the header is disabled ( correct )and the
pager
is hidden ( correct )
click the button as many times as you like , things remain as they
shoud be.

Click the checkbox - now the header is enabled ( correct ) and the
pager is
still hidden ( incorrect )
click the button and now the the header is enabled ( correct ) and the
pager
is visible (correct )
click the button as many times as you like , things remain as they
shoud be.

repeated clicking of the checkbox results in the header and pager being
in
opposite 'phase'.

Having written my share of custom web controls, it is pretty obvious
what
the problem is.
Has this been fixed with SP1 ? I am currently trying to install the
update
but after about 6 hours I am not having much success.
Gerry

Feb 26 '07 #4
After looking at subclassing the GridView control to fix this short-coming ,
it appears that maybe the problem is that the PagerSettings.PropertyChanged
event is never fired
Accoroding to the docs this is where the rebind should be happening with
databound controls.

So for now my subclass handles the PagerRow property under the resttriction
that PagerSettings.Visible is not used at runtime.

Gerry
"gerry" <ge**@canada.comwrote in message
news:ek**************@TK2MSFTNGP02.phx.gbl...
I'm not sure if you are saying that this not a bug - if so i beg to
disagree or at least to say that this a very very poor design.
Why handle the PageSettings property any different than any other property
on the control ? We can set any other property in PreRender and have it
take effect on the current request without requiring a post back or a
rebind.
The real problem is that the designers of this control decided to treat
the PagerRow different than the other non-data rows - HeaderRow &
FooterRow.
My workaround for this was to have the PagerSettings.Visible property
always set to true ( which should not be required ) and capture the pager
row object in the RowCreated event, then I use this PagerRow object to set
pager visibility rather than the PagerSettings property whihc is then
consistant with how we handle the properties of the HeaderRow & FooterRow.
The PagerRow should have been setup as an exposed property the same as
HeaderRow & FooterRow - I don't see any good reason why it wasn't.

Gerry

"Milosz Skalecki [MCAD]" <mi*****@DONTLIKESPAMwp.plwrote in message
news:BB**********************************@microsof t.com...
>Hi Gerry,

In addtion to Peter's comments, whilst data has been bound, all rows have
been already created based on values you provider at the binding stage
(if
PagerSetting.Visible was set to false, pager was not rendered, and even
if
you change it to true later in page execution it won't force gridview to
show
pager). It's also true for postback, because gridview rebuilds itself
based
on information stored in viewstate. To resolve the problem, you need to
rebind the data again:

// if autpostback is set to true you can handle CheckChanged event
protected void myCheckBox_CheckedChanged(object sender, EventArgs e)
{
bool checked = ((CheckBox) sender).Checked;

myGridView.PagerSettings.Visible = checked; // or !checked;
myGridView.DataSource = dataSource;
myGridView.dataBind();
}

Hope this helps

--
Milosz
"Peter Bromberg [C# MVP]" wrote:
>>Gerry,
You should look for this in the Product Feedback site, for a couple of
reasons:
1) other people may have already submitted it (or something very
similar)
and you can see the status of the alleged "bug" - including workarounds,
if
any.
2) If it's a legitimate bug and nobody has submitted it, you have the
honor
of being the first.

This page lists the different feedback sites by technology:

http://connect.microsoft.com/Main/co...ContentID=2220

Cheers,
Peter

--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net


"gerry" wrote:

The PagerSettings.Visible property is not being handled properly by
the
GridView control.
The value assigned to this property is not applied until after a
postback.
Simplest test :
.aspx containing a single gridview - enable paging and give enough
data
to page.
add checkbox with auto postback enable
add button with auto postback enable
in the GridView1_PreRender method add the following :
GridView1.HeaderRow.Enabled =
GridView1.PagerSettings.Visible =
CheckBox1.Checked;
note that the header should be enabled when the pager is visible
and the
header should be disabled whetn the pager is hidden.

When you 1st view the page the header is disabled ( correct ) and the
pager
is visible ( incorrect )
click the button and now the the header is disabled ( correct )and the
pager
is hidden ( correct )
click the button as many times as you like , things remain as they
shoud be.

Click the checkbox - now the header is enabled ( correct ) and the
pager is
still hidden ( incorrect )
click the button and now the the header is enabled ( correct ) and the
pager
is visible (correct )
click the button as many times as you like , things remain as they
shoud be.

repeated clicking of the checkbox results in the header and pager
being in
opposite 'phase'.

Having written my share of custom web controls, it is pretty obvious
what
the problem is.
Has this been fixed with SP1 ? I am currently trying to install the
update
but after about 6 hours I am not having much success.
Gerry


Feb 26 '07 #5
after more digging, i have dropped the subclass altogether as it turns out
that there is in fact a PagerRow object - more precisely there are 2 of them
TopPagerRow & BottomPagerRow.

For now I will ignore the PagerSettings.Visible property and use the
PagerRow properties to set their visible property.

Gerry
"gerry" <ge**@canada.comwrote in message
news:Oq***************@TK2MSFTNGP05.phx.gbl...
After looking at subclassing the GridView control to fix this short-coming
,
it appears that maybe the problem is that the
PagerSettings.PropertyChanged event is never fired
Accoroding to the docs this is where the rebind should be happening with
databound controls.

So for now my subclass handles the PagerRow property under the
resttriction that PagerSettings.Visible is not used at runtime.

Gerry
"gerry" <ge**@canada.comwrote in message
news:ek**************@TK2MSFTNGP02.phx.gbl...
>I'm not sure if you are saying that this not a bug - if so i beg to
disagree or at least to say that this a very very poor design.
Why handle the PageSettings property any different than any other
property on the control ? We can set any other property in PreRender and
have it take effect on the current request without requiring a post back
or a rebind.
The real problem is that the designers of this control decided to treat
the PagerRow different than the other non-data rows - HeaderRow &
FooterRow.
My workaround for this was to have the PagerSettings.Visible property
always set to true ( which should not be required ) and capture the pager
row object in the RowCreated event, then I use this PagerRow object to
set pager visibility rather than the PagerSettings property whihc is then
consistant with how we handle the properties of the HeaderRow &
FooterRow.
The PagerRow should have been setup as an exposed property the same as
HeaderRow & FooterRow - I don't see any good reason why it wasn't.

Gerry

"Milosz Skalecki [MCAD]" <mi*****@DONTLIKESPAMwp.plwrote in message
news:BB**********************************@microso ft.com...
>>Hi Gerry,

In addtion to Peter's comments, whilst data has been bound, all rows
have
been already created based on values you provider at the binding stage
(if
PagerSetting.Visible was set to false, pager was not rendered, and even
if
you change it to true later in page execution it won't force gridview to
show
pager). It's also true for postback, because gridview rebuilds itself
based
on information stored in viewstate. To resolve the problem, you need to
rebind the data again:

// if autpostback is set to true you can handle CheckChanged event
protected void myCheckBox_CheckedChanged(object sender, EventArgs e)
{
bool checked = ((CheckBox) sender).Checked;

myGridView.PagerSettings.Visible = checked; // or !checked;
myGridView.DataSource = dataSource;
myGridView.dataBind();
}

Hope this helps

--
Milosz
"Peter Bromberg [C# MVP]" wrote:

Gerry,
You should look for this in the Product Feedback site, for a couple of
reasons:
1) other people may have already submitted it (or something very
similar)
and you can see the status of the alleged "bug" - including
workarounds, if
any.
2) If it's a legitimate bug and nobody has submitted it, you have the
honor
of being the first.

This page lists the different feedback sites by technology:

http://connect.microsoft.com/Main/co...ContentID=2220

Cheers,
Peter

--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net


"gerry" wrote:

The PagerSettings.Visible property is not being handled properly by
the
GridView control.
The value assigned to this property is not applied until after a
postback.
Simplest test :
.aspx containing a single gridview - enable paging and give
enough data
to page.
add checkbox with auto postback enable
add button with auto postback enable
in the GridView1_PreRender method add the following :
GridView1.HeaderRow.Enabled =
GridView1.PagerSettings.Visible =
CheckBox1.Checked;
note that the header should be enabled when the pager is visible
and the
header should be disabled whetn the pager is hidden.

When you 1st view the page the header is disabled ( correct ) and the
pager
is visible ( incorrect )
click the button and now the the header is disabled ( correct )and
the pager
is hidden ( correct )
click the button as many times as you like , things remain as they
shoud be.

Click the checkbox - now the header is enabled ( correct ) and the
pager is
still hidden ( incorrect )
click the button and now the the header is enabled ( correct ) and
the pager
is visible (correct )
click the button as many times as you like , things remain as they
shoud be.

repeated clicking of the checkbox results in the header and pager
being in
opposite 'phase'.

Having written my share of custom web controls, it is pretty obvious
what
the problem is.
Has this been fixed with SP1 ? I am currently trying to install the
update
but after about 6 hours I am not having much success.
Gerry



Feb 26 '07 #6
I have a BoundField column which I am dynamically adding to the GridView.

BoundField boundField_Committed_date = new BoundField();
boundField_Committed_date.DataField = "Committed_date";
boundField_Committed_date.HeaderText = "Committed Dt";
boundField_Committed_date.DataFormatString = "{0:d}";
boundField_Committed_date.HtmlEncode = false;
boundField_Committed_date.SortExpression = "Committed_date";

I want to have the Visible property coming from the database and
automatically binded. Visible property of course does not accept a Column
Name. Is there any work around?
Feb 27 '07 #7
Good morning Gerry,

I disagree with you at some point. GridView control is based on templates
and a data source. Dealing with data you have to consider it's only known at
binding stage regardless if you use data table, data set or data reader. Most
of the content within a template is based on data and in most cases binding
stage is the only time you can build the control structure. And pager is a
perfect example because it linked straight to the data - it can only be
displayed if grid views contains any rows, it has to consider number of pages
etc., not as for footer and header, they can be shown regardless if
underlying data source contains any results. That’s why disagree with
statement "…The real problem is that the designers of this control decided to
treat the PagerRow different than the other non-data rows - HeaderRow &
FooterRow…", because it a hybrid between data row and non data row :)

Best Regards
--
Milosz
"gerry" wrote:
I'm not sure if you are saying that this not a bug - if so i beg to disagree
or at least to say that this a very very poor design.
Why handle the PageSettings property any different than any other property
on the control ? We can set any other property in PreRender and have it take
effect on the current request without requiring a post back or a rebind.
The real problem is that the designers of this control decided to treat the
PagerRow different than the other non-data rows - HeaderRow & FooterRow.
My workaround for this was to have the PagerSettings.Visible property always
set to true ( which should not be required ) and capture the pager row
object in the RowCreated event, then I use this PagerRow object to set pager
visibility rather than the PagerSettings property whihc is then consistant
with how we handle the properties of the HeaderRow & FooterRow.
The PagerRow should have been setup as an exposed property the same as
HeaderRow & FooterRow - I don't see any good reason why it wasn't.

Gerry

"Milosz Skalecki [MCAD]" <mi*****@DONTLIKESPAMwp.plwrote in message
news:BB**********************************@microsof t.com...
Hi Gerry,

In addtion to Peter's comments, whilst data has been bound, all rows have
been already created based on values you provider at the binding stage (if
PagerSetting.Visible was set to false, pager was not rendered, and even if
you change it to true later in page execution it won't force gridview to
show
pager). It's also true for postback, because gridview rebuilds itself
based
on information stored in viewstate. To resolve the problem, you need to
rebind the data again:

// if autpostback is set to true you can handle CheckChanged event
protected void myCheckBox_CheckedChanged(object sender, EventArgs e)
{
bool checked = ((CheckBox) sender).Checked;

myGridView.PagerSettings.Visible = checked; // or !checked;
myGridView.DataSource = dataSource;
myGridView.dataBind();
}

Hope this helps

--
Milosz
"Peter Bromberg [C# MVP]" wrote:
Gerry,
You should look for this in the Product Feedback site, for a couple of
reasons:
1) other people may have already submitted it (or something very similar)
and you can see the status of the alleged "bug" - including workarounds,
if
any.
2) If it's a legitimate bug and nobody has submitted it, you have the
honor
of being the first.

This page lists the different feedback sites by technology:

http://connect.microsoft.com/Main/co...ContentID=2220

Cheers,
Peter

--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net


"gerry" wrote:

The PagerSettings.Visible property is not being handled properly by the
GridView control.
The value assigned to this property is not applied until after a
postback.
Simplest test :
.aspx containing a single gridview - enable paging and give enough
data
to page.
add checkbox with auto postback enable
add button with auto postback enable
in the GridView1_PreRender method add the following :
GridView1.HeaderRow.Enabled =
GridView1.PagerSettings.Visible =
CheckBox1.Checked;
note that the header should be enabled when the pager is visible and
the
header should be disabled whetn the pager is hidden.

When you 1st view the page the header is disabled ( correct ) and the
pager
is visible ( incorrect )
click the button and now the the header is disabled ( correct )and the
pager
is hidden ( correct )
click the button as many times as you like , things remain as they
shoud be.

Click the checkbox - now the header is enabled ( correct ) and the
pager is
still hidden ( incorrect )
click the button and now the the header is enabled ( correct ) and the
pager
is visible (correct )
click the button as many times as you like , things remain as they
shoud be.

repeated clicking of the checkbox results in the header and pager being
in
opposite 'phase'.

Having written my share of custom web controls, it is pretty obvious
what
the problem is.
Has this been fixed with SP1 ? I am currently trying to install the
update
but after about 6 hours I am not having much success.
Gerry



Mar 1 '07 #8
Hi Milisz,
I disagree with your disagreement. ;-) A pager row is no more tied to the
data binding process than the header row especially if you have
AutoGenerateColumns set to true.
As it turns out I was partly wrong , as I stated in a followup post, the
pager rows are treated the same as the header and footer rows AS LONG AS you
always have the PagerSettings.Visible property set to true. So the real
problem is how the that the PagerSettings.Visible property is applied - if
you ignore it and use the actual PagerRow object(s) to set pager visiblility
then everything works as it should. imo , the pager row object(s) should be
created regardless of the PagerSettings.Visible property value and this
value should be applied to the created objects. The way this control works
, the PagerSettings.Visible property should have been called
PagerSettings.Exists. Visibility is a UI property, not a DB property
Gerry
"Milosz Skalecki [MCAD]" <mi*****@DONTLIKESPAMwp.plwrote in message
news:FB**********************************@microsof t.com...
Good morning Gerry,

I disagree with you at some point. GridView control is based on templates
and a data source. Dealing with data you have to consider it's only known
at
binding stage regardless if you use data table, data set or data reader.
Most
of the content within a template is based on data and in most cases
binding
stage is the only time you can build the control structure. And pager is a
perfect example because it linked straight to the data - it can only be
displayed if grid views contains any rows, it has to consider number of
pages
etc., not as for footer and header, they can be shown regardless if
underlying data source contains any results. That's why disagree with
statement ".The real problem is that the designers of this control decided
to
treat the PagerRow different than the other non-data rows - HeaderRow &
FooterRow.", because it a hybrid between data row and non data row :)

Best Regards
--
Milosz
"gerry" wrote:
>I'm not sure if you are saying that this not a bug - if so i beg to
disagree
or at least to say that this a very very poor design.
Why handle the PageSettings property any different than any other
property
on the control ? We can set any other property in PreRender and have it
take
effect on the current request without requiring a post back or a rebind.
The real problem is that the designers of this control decided to treat
the
PagerRow different than the other non-data rows - HeaderRow & FooterRow.
My workaround for this was to have the PagerSettings.Visible property
always
set to true ( which should not be required ) and capture the pager row
object in the RowCreated event, then I use this PagerRow object to set
pager
visibility rather than the PagerSettings property whihc is then
consistant
with how we handle the properties of the HeaderRow & FooterRow.
The PagerRow should have been setup as an exposed property the same as
HeaderRow & FooterRow - I don't see any good reason why it wasn't.

Gerry

"Milosz Skalecki [MCAD]" <mi*****@DONTLIKESPAMwp.plwrote in message
news:BB**********************************@microso ft.com...
Hi Gerry,

In addtion to Peter's comments, whilst data has been bound, all rows
have
been already created based on values you provider at the binding stage
(if
PagerSetting.Visible was set to false, pager was not rendered, and even
if
you change it to true later in page execution it won't force gridview
to
show
pager). It's also true for postback, because gridview rebuilds itself
based
on information stored in viewstate. To resolve the problem, you need to
rebind the data again:

// if autpostback is set to true you can handle CheckChanged event
protected void myCheckBox_CheckedChanged(object sender, EventArgs e)
{
bool checked = ((CheckBox) sender).Checked;

myGridView.PagerSettings.Visible = checked; // or !checked;
myGridView.DataSource = dataSource;
myGridView.dataBind();
}

Hope this helps

--
Milosz
"Peter Bromberg [C# MVP]" wrote:

Gerry,
You should look for this in the Product Feedback site, for a couple of
reasons:
1) other people may have already submitted it (or something very
similar)
and you can see the status of the alleged "bug" - including
workarounds,
if
any.
2) If it's a legitimate bug and nobody has submitted it, you have the
honor
of being the first.

This page lists the different feedback sites by technology:

http://connect.microsoft.com/Main/co...ContentID=2220

Cheers,
Peter

--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net


"gerry" wrote:

The PagerSettings.Visible property is not being handled properly by
the
GridView control.
The value assigned to this property is not applied until after a
postback.
Simplest test :
.aspx containing a single gridview - enable paging and give
enough
data
to page.
add checkbox with auto postback enable
add button with auto postback enable
in the GridView1_PreRender method add the following :
GridView1.HeaderRow.Enabled =
GridView1.PagerSettings.Visible =
CheckBox1.Checked;
note that the header should be enabled when the pager is visible
and
the
header should be disabled whetn the pager is hidden.

When you 1st view the page the header is disabled ( correct ) and
the
pager
is visible ( incorrect )
click the button and now the the header is disabled ( correct )and
the
pager
is hidden ( correct )
click the button as many times as you like , things remain as they
shoud be.

Click the checkbox - now the header is enabled ( correct ) and the
pager is
still hidden ( incorrect )
click the button and now the the header is enabled ( correct ) and
the
pager
is visible (correct )
click the button as many times as you like , things remain as they
shoud be.

repeated clicking of the checkbox results in the header and pager
being
in
opposite 'phase'.

Having written my share of custom web controls, it is pretty obvious
what
the problem is.
Has this been fixed with SP1 ? I am currently trying to install the
update
but after about 6 hours I am not having much success.
Gerry



Mar 2 '07 #9

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: Carlos | last post by:
Hi all, I would like to know what is the most efficient way to redirect a gridview containing data to another page. It is kind of confirming an order which just needs to be re-displayed. Can...
12
by: Cindy Lee | last post by:
When I do a sorta on 1 table, then the other table goes back to the original order. What can I set so, it keeps the order of the other current gridview's order. I set all the gridview values...
1
by: mark4asp | last post by:
I moved a page to another web-site and now it's broke! I had 5 pages in their own web-site. These pages have now been moved to another web-site. Everything is fine except that one of the pages,...
2
by: giveDsolution | last post by:
Hope to find the solution ...........Actually my requirment is .I have a gridview, Onclicking the row of gridview (each row) another gridview will be opened under that partcular row. I want the...
2
by: Mic | last post by:
Hi, I have a GridView control that gets populated at runtime and I need to print its content. The simplest way I found was to use window.print() but this prints everything on the page. But if...
3
by: Dave | last post by:
I have an GridView on one page that will open a popup for the selected record. I've been told that there is a way that when the popup record is updated the GridView can be refreshed or Databind. ...
2
by: David C | last post by:
I have an aspx page with a GridView named gvTasks that has a linkbutton on each row that calls up another pop-up window using the following js function: function openTask(id, coid) { var surl...
0
by: =?Utf-8?B?S3VydCBvZiBTYW4gSm9zZQ==?= | last post by:
All- Please advise as to what's the best way to display data in a column in a grid view (and I'm using a dataset) in a table (say TABLE2) which: - is non-zero only if a boolian field in the...
1
by: gopim | last post by:
gridview inside another gridview using Asp.net C#
1
by: Andy B | last post by:
I have a wizard with multiple steps in it. On the first step, I have a gridView that shows the users current input for that particular step. The GridView is bound to an in memory object. When I...
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.