|
|
You're in the
dotnet windows forms
group:DataGridView inheritance
dotnet windows forms:
I have just found that there is a feature in VS .NET which deliberately
stops me making a DGV "protected" in an ancestor class and then modifying its properties in inherited classes. I can see why this problematic for MS and therefore why it has not been implemented. However, I could do with a suggestion on how best to move forwards with what I need to do..... I have an ancestor UserControl which contains a single DGV and lots of methods/properties to allow me to "talk" with that DGV from a containing form. I then need around 30 UserControls inherited from that ancestor. They all need to offer the same methods/properties, but will need different data connections from their instance of the DGV. They will also need different columns displayed, with different headings and so on. I could obviously bin the OO approach altogether and just copy my control 30 times - but I am fearful of then needing to make every change 30 times in the future. Suggestions please! Thanks, Nick.
Thinking of one way for myself (maybe). Would it make sense to "paint" each
DGV separately (eg on a form)and then paste the code from the designer into my inherited class somewhere? [quoted text, click to view] "Nick Locke" <nick@nicklocke.co.uk> wrote in message news:HKOdnYVrEoQvyKvbRVnygQA@eclipse.net.uk... >I have just found that there is a feature in VS .NET which deliberately >stops me making a DGV "protected" in an ancestor class and then modifying >its properties in inherited classes. I can see why this problematic for MS >and therefore why it has not been implemented. However, I could do with a >suggestion on how best to move forwards with what I need to do..... > > I have an ancestor UserControl which contains a single DGV and lots of > methods/properties to allow me to "talk" with that DGV from a containing > form. > > I then need around 30 UserControls inherited from that ancestor. They all > need to offer the same methods/properties, but will need different data > connections from their instance of the DGV. They will also need different > columns displayed, with different headings and so on. > > I could obviously bin the OO approach altogether and just copy my control > 30 times - but I am fearful of then needing to make every change 30 times > in the future. > > Suggestions please! > > Thanks, Nick. >
You don't have to inherit a DataGridView to create a new class. You can
create a container class that implements and exposes a DataGridView. -- HTH, Kevin Spencer Microsoft MVP Printing Components, Email Components, FTP Client Classes, Enhanced Data Controls, much more. DSI PrintManager, Miradyne Component Libraries: http://www.miradyne.net [quoted text, click to view] "Nick Locke" <nick@nicklocke.co.uk> wrote in message news:HKOdnYVrEoQvyKvbRVnygQA@eclipse.net.uk... >I have just found that there is a feature in VS .NET which deliberately >stops me making a DGV "protected" in an ancestor class and then modifying >its properties in inherited classes. I can see why this problematic for MS >and therefore why it has not been implemented. However, I could do with a >suggestion on how best to move forwards with what I need to do..... > > I have an ancestor UserControl which contains a single DGV and lots of > methods/properties to allow me to "talk" with that DGV from a containing > form. > > I then need around 30 UserControls inherited from that ancestor. They all > need to offer the same methods/properties, but will need different data > connections from their instance of the DGV. They will also need different > columns displayed, with different headings and so on. > > I could obviously bin the OO approach altogether and just copy my control > 30 times - but I am fearful of then needing to make every change 30 times > in the future. > > Suggestions please! > > Thanks, Nick. >
[quoted text, click to view]
Kevin Spencer wrote: > You don't have to inherit a DataGridView to create a new class. You can > create a container class that implements and exposes a DataGridView. Kevin, if I am understanding correctly, you are saying that I don't need to create a User Control, put a DGV on it and then use that as an ancestor class for all of my objects. Rather, I think you are suggesting that I create a customised DGV (encapsulating all of my functionality) and then I just plonk one of those onto each of my target user controls and/or forms. Am I on the right wavelength? So, to "create a container class that implements and exposes a DataGridView", I was hoping that when I did this: Public Class CustomDGV Implements System.Windows.Forms.????? End Class I would just be able to implement a DGV like that. I am showing my ignorance here, but need a bit more of a pointer. Thanks, Nick
Have I answered my own question - is it just:
Public Class CustomDGV Inherits System.Windows.Forms.DataGridView End Class Thanks?! [quoted text, click to view] "Nick Locke" <nick@nicklocke.co.uk> wrote in message news:_MqdnYd-Q6eyOKrbRVnyjwA@eclipse.net.uk... > Kevin Spencer wrote: > >> You don't have to inherit a DataGridView to create a new class. You can >> create a container class that implements and exposes a DataGridView. > > Kevin, if I am understanding correctly, you are saying that I don't need > to create a User Control, put a DGV on it and then use that as an ancestor > class for all of my objects. Rather, I think you are suggesting that I > create a customised DGV (encapsulating all of my functionality) and then I > just plonk one of those onto each of my target user controls and/or forms. > Am I on the right wavelength? > > So, to "create a container class that implements and exposes a > DataGridView", I was hoping that when I did this: > > Public Class CustomDGV > Implements System.Windows.Forms.????? > > End Class > > I would just be able to implement a DGV like that. I am showing my > ignorance here, but need a bit more of a pointer. > > Thanks, > > Nick > > >
That is one solution. The other is to create a class that implements and
exposes a DataGridView, such as the following (forgive my C#): public class DataGridViewContainer : UserControl { private DataGridView _View; public int ViewWidth { get { return _View.Width; } set { _View.Width = value; } } public DataGridView View { get { return _View; } } // etc. } -- HTH, Kevin Spencer Microsoft MVP Printing Components, Email Components, FTP Client Classes, Enhanced Data Controls, much more. DSI PrintManager, Miradyne Component Libraries: http://www.miradyne.net [quoted text, click to view] "Nick Locke" <nick@nicklocke.co.uk> wrote in message news:Do6dnVLCeZSNNKrbnZ2dnUVZ8vednZ2d@eclipse.net.uk... > Have I answered my own question - is it just: > > Public Class CustomDGV > > Inherits System.Windows.Forms.DataGridView > > End Class > > Thanks?! > > "Nick Locke" <nick@nicklocke.co.uk> wrote in message > news:_MqdnYd-Q6eyOKrbRVnyjwA@eclipse.net.uk... >> Kevin Spencer wrote: >> >>> You don't have to inherit a DataGridView to create a new class. You can >>> create a container class that implements and exposes a DataGridView. >> >> Kevin, if I am understanding correctly, you are saying that I don't need >> to create a User Control, put a DGV on it and then use that as an >> ancestor class for all of my objects. Rather, I think you are suggesting >> that I create a customised DGV (encapsulating all of my functionality) >> and then I just plonk one of those onto each of my target user controls >> and/or forms. Am I on the right wavelength? >> >> So, to "create a container class that implements and exposes a >> DataGridView", I was hoping that when I did this: >> >> Public Class CustomDGV >> Implements System.Windows.Forms.????? >> >> End Class >> >> I would just be able to implement a DGV like that. I am showing my >> ignorance here, but need a bit more of a pointer. >> >> Thanks, >> >> Nick >> >> >> > >
[quoted text, click to view]
Nick Locke wrote: > Public Class CustomDGV > Inherits System.Windows.Forms.DataGridView > > overriden and/or additional functions, methods, events etc > >End Class [quoted text, click to view] Kevin Spencer wrote: > That is one solution. The other is to create a class that implements and > exposes a DataGridView, such as the following (forgive my C#): > > public class DataGridViewContainer : UserControl > { > private DataGridView _View; > > public int ViewWidth > { > get { return _View.Width; } > set { _View.Width = value; } > } > > public DataGridView View { get { return _View; } } > // etc. > } Thanks Kevin, that certainly does help. Any views (from Kevin or anyone), whether there are reasons to choose one approach over the other (hidden gotchas, etc)? Thanks
When you implement a DataGridView rather than inheriting it, you have more
control over what is exposed and what is not. That's about the only advantage I can think of. -- HTH, Kevin Spencer Microsoft MVP Printing Components, Email Components, FTP Client Classes, Enhanced Data Controls, much more. DSI PrintManager, Miradyne Component Libraries: http://www.miradyne.net [quoted text, click to view] "Nick Locke" <nick@nicklocke.co.uk> wrote in message news:rYidnZju39o6faXbRVnyiwA@eclipse.net.uk... > Nick Locke wrote: > >> Public Class CustomDGV >> Inherits System.Windows.Forms.DataGridView >> >> overriden and/or additional functions, methods, events etc >> >>End Class > > > Kevin Spencer wrote: > >> That is one solution. The other is to create a class that implements and >> exposes a DataGridView, such as the following (forgive my C#): >> >> public class DataGridViewContainer : UserControl >> { >> private DataGridView _View; >> >> public int ViewWidth >> { >> get { return _View.Width; } >> set { _View.Width = value; } >> } >> >> public DataGridView View { get { return _View; } } >> // etc. >> } > > Thanks Kevin, that certainly does help. Any views (from Kevin or anyone), > whether there are reasons to choose one approach over the other (hidden > gotchas, etc)? > > Thanks >
That helps. Kevin, thanks for all of your help with this.
Nick [quoted text, click to view] "Kevin Spencer" <unclechutney@nothinks.com> wrote in message news:uvVwYAXjHHA.4520@TK2MSFTNGP02.phx.gbl... > When you implement a DataGridView rather than inheriting it, you have more > control over what is exposed and what is not. That's about the only > advantage I can think of. > > -- > HTH, > > Kevin Spencer > Microsoft MVP
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |