Add export button to master page 2

[stephenk1973]

All my pages which reference my data.master display their data in Gridview1.

I would like to add an export button which exports this gridview on the footer of the master page. With current efforts Data.master doesn't seem like referencing Gridview1 as, i guess, i doesn't really know about it.

Is this possible to do? If so can some one point the way.

Thanks

Stephen

 

[ca8msm]

I haven't tried this but the Page class of the MasterPage should be able to get a reference to the actual page and then you can probably use FindControl to get a reference to the GridView. Have a try and see if that works...


____________________________________________________________

Need help finding an answer?

Try the Search Facility or read FAQ222-2244 on how to get better results.

 

[BoulderBum]

Can you put GridView1 in the MasterPage instead of the inheriting pages?

 

[stephenk1973]

Have never had to deal with classes before, am i heading in the right direction?? Currently on trying to export am having a problem "Object reference not set to an instance of an object". Is the object not being passed. So far i have.........

All help much appreciated.

Stpephen

On form............
Protected Sub btnExp_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles Button1.Click
Dim Gridview1 As GridView
Dim MyExport As New GridExport(Gridview1)
End Sub

Class.............
Public Class ExportGrd

Protected _Exgrid As GridView

End Class
Public Class GridExport
Inherits ExportGrd

Public Sub New(ByVal gvGrid As GridView)

_Exgrid = gvGrid

_Exgrid.AllowPaging = False
_Exgrid.AllowSorting = False

_Exgrid.DataBind()
''Not sure what to do here to ini
End Sub
End Class

 

[BoulderBum]

The GridView is still null when you're trying to set its properties. You need to set the reference to an instance.

Dim Gridview1 As GridView [b]= new GridView()[/b]

That said, I still don't see why you don't put a GridView in the MasterPage, expose it as a property, then just manipulate it from the Page. You'll actually save yourself some state headaches that way, too, because you'll be able to better tap into ASP.NET's ViewState without extra code.

 

[ca8msm]

To be honest I'd still go with the approach of getting a reference to the control from the master page as if the poster puts the GridView on the master page then it will exist on pages that don't necessarily need it.

Using the method I suggested above, I was easily able to get a reference to a GridView from a Button on a Master Page and (in this example) simply hide it:

    Protected Sub Button1_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles Button1.Click
        Dim gd As New GridView
        gd = Me.Page.Controls(0).FindControl("form1").FindControl("ContentPlaceHolder1").FindControl("GridView1")
        gd.Visible = False
    End Sub

You can obviously modify that example to do whatever you need to do to your GridView.


____________________________________________________________

Need help finding an answer?

Try the Search Facility or read FAQ222-2244 on how to get better results.

 

[BoulderBum]

My two cents is that while ASP.NET has a mechanism for setting the MasterPage type in a Page, there is to such mechanism for a reference going the other direction and its arranged that way for a good reason. You don't want a parent container assuming the structure and layout of a child containers because the approach is a little brittle.

For example, if you do something like:

Dim gd As New GridView
gd = Me.Page.Controls(0).FindControl("form1").FindControl("ContentPlaceHolder1").FindControl("GridView1")

There's already a sense that there's a lot of code needed to even get at the grid (an indexed collection and three function calls) but more importantly the approach lacks transparency and relies on several assumptions.

For example, if the grid id or nesting level of the grid changes (say if you put the grid in a panel) then the above code breaks. Granted you can just assume an id and use recursion, but performance suffers and it's impossible for a developer to tell what's going on just looking at the Page code.

Contrast this with a property or method of a MasterPage, where the code is clean, transparent and simple:

//in page
Master.StandardGrid.DataSource = //whatever;
Master.StandardGrid.DataBind();

//alternately
//Master.BindGrid( /* some data */ );

Given the approach, a developer can instantly tell what's going on by looking at the Page code, there's no need to worry about proper IDs or nesting as with FindControl() and it's easy to reposition the grid for all Pages by only changing the MasterPage (as opposed to changing the markup of every child).

True this adds a GridView for all pages even if they may not need it, but on the other hand memory allocation is cheap and the alternative code looks for a control that may not exist which feels more awkward in my view. That said, the original post said that all Pages contain the grid which may be a perfect reason to encapsulate the control in a MasterPage.

 

[ca8msm]

That said, the original post said that all Pages contain the grid which may be a perfect reason to encapsulate the control in a MasterPage.

Yeah, that's a good point (and something I'd overlooked) so it may be easier and "cleaner" to go with that solution. Thinking about it, it's probably not a good idea to do what I suggested (although it could be cleaned up so that it didn't break if the ID's changed or, as you said, if other controls such as panels were introduced). Using my solution would mean that if a page didn't have a GridView, then the process of actually finding the GridView would still have to take place and this may introduce an unnessary delay in loading the page (probably not much, but still unnessary).

Having said that, both methods work so I guess it's up to the devloper to decide which method would be best for their situation.


____________________________________________________________

Need help finding an answer?

Try the Search Facility or read FAQ222-2244 on how to get better results.

 

[stephenk1973]

Thank you. Have that all sorted now, simpler than i thought, as usual.

Had thought about putting the gridview in the master, but thought this might limit the formatting for each individual page. Though i always want to export gridview1, sometimes there is a gridview2 and 3 etc which 'dominate' the page.

Thanks again.

Stephen

 

[BoulderBum]

ca8msm,

I hear ya.

stephenk1973,

Since you're using ASP.NET 2.0, an easy way to handle formatting such that you give each page control over the format is through skins. Even if you have the grid in the MasterPage you can set a skin ID from the individual Page.

Having skins will also help share formatting across Pages without cluttering the markup with duplicated style information.