Property Overloading

Property Overloading

• CFIG

  well I think it would be nice if the toolstrip progress bar inherited from the progress bar and a toolstripcontrol interface, but that is just me.

  as for "Write your own class that wraps both controls (i.e. both are private members) with a property that selects the context. Provide public methods/properties that forwards to one of these controls based on the context (or fires an exception if that operation is not applicable). "

  I don't think that would elimate needing two seperate properties (the class I'm making is a development tool, and there for are not acting upon the same progressbars every time)

  I think what I have to do is in the set() mehthod set a bool varible to tell the main class which control to act upon

  
  

• Amin_msw

  Unless the ToolStripProgressBar inherits from ProgressBar, no not really.
  
  

• moreOncoding

  Sure.  Say MyPB1 and MyPB2 were two classes that wrapped classes PB1 and PB2, respectively, where both are Controls.  You want to abstract the functionality of PB1 and PB2, so you make methods in your new interface IMyPB.

  using namespace System;

  ref class PB1 // In your case, this is class ProgressBar, part of .NET
  {
  public:
     void Foo()
     {
        Console::WriteLine( "In PB1::Foo()" );
     }
  };

  ref class PB2  // In your case, this is class ToolStripProgressBar, part of .NET
  {
  public:
     void Foo()
     {
        Console::WriteLine( "In PB2::Foo()" );
     }
  };

  interface class IMyPB  // You write this with the common functionality
  {
  public:
     virtual void Foo() abstract;
  };

  // MyPB1 inherit PB1's functionality and implements IMyPB
  ref class MyPB1 : public PB1, IMyPB
  {
  public:
     virtual void Foo() // implements IMyPB::Foo()|
     {
        PB1::Foo(); // delegate to actual class
     }
  };

  // MyPB2 inherit PB2's functionality and implements IMyPB
  ref class MyPB2 : public PB2, IMyPB
  {
  public:
     virtual void Foo() // implements IMyPB::Foo()
     {
        PB2::Foo(); // delegate to actual class
     }
  };

  // Example exercise of an abstract method
  int main(array<System::String ^> ^args)
  {
     MyPB1^ myPB1 = gcnew MyPB1();
     IMyPB^ thePB = myPB1; // simulate client's abstract handle
     thePB->Foo(); // call the abstract method
     return 0;
  }
  

  
  

• Jerod Moemeka

  What you are trying to do is polymorphically access both types of controls--or, in other words, make the specific control type more opaque to the client. My original suggestion would not have satisfied the requirement that all controls inherit from System.Windows.Form.Control.

  But instead if you created a class that derived from ProgressBar, it would still inherit System.Windows.Form.Control yet allow you to also implement an interface that exposes common functionality of both types of progress bars to the client. This implementation would delegate to the corresponding ProgressBar methods and properties underneath it.

  Brian

  
  

• andrewtan00

  wow that's a complex solution to a simple problem!

  but thank you very much for all your help!

  
  

• billb59

  that sound good, but how would I go about doing it

  What is the purpose of inheriting both controls first

  
  

• abp07

  This might be what Zoltan was trying to say, but here's my advise.  Write your own class that wraps both controls (i.e. both are private members) with a property that selects the context.  Provide public methods/properties that forwards to one of these controls based on the context (or fires an exception if that operation is not applicable). 

  Making one flavor of a control inherit from another is not always a good idea--it would only make sense of one is a specialization of another and perhaps that's not the case here.  A design approach could be to have both controls implement a common interface, but that also complicates the framework.

  Brian

  
  

• Eljdee1

  well I guess I just have to make two seperate properties

  I think the root of the problem here is that the toolstripprogress bar does not inherit from the progress bar. Shame on you .NET makers!

  
  

• KitGreen

  What if I make a template, would that work (if so, I don't really know how to make a template so help with that would be appreciated)
  

• Cyber Sinh

  Yeah it is. But in the end you have a client that only needs to know about IMyPB.
  

• ro88o

  I don't understand the interface part, would I inherit this interface form the progress bar or create it form scratch I am confused.

  I would really appreciate if you could show em a simplified example in code.

  
  

• http&amp;#58;&amp;#47;&amp;#47;www.ilkon.com

  Unfortunately writing a template isn't really going to help either, because if you do it at the class level, you'll end up with two separate classes - one with the property to return the progressbar, and one to return the other one. At run time, you'd only be using one of them - so that won't work.

  The previous post, that suggested using inheritance, is really your best bet - but then if you can't rewrite one of the classes then that's also a nono.

  You could introduce a struct into your code that has two members, the progressbar and the other one (sorry can't remember what it was now!) and modify your property to return one of those. Then you just check which one is not null at runtime. It's a bit of a hack though.

  I'm guessing you're writing C++/Cli, in which case you can do something very funky, and return an Object^ and reflect out the type of the instance that's been returned at runtime. If you cannot possibly know which one is going to be returned in advance, then that's what I'd do.

  
  

• polease

  Or you could have two classes of your own inherit from these controls (given that they are not sealed), respectively. In addition, implement an interface common to each that exposes the common functionality. Your clients don't need to know which control is in effect since it is given a pointer to the interface.

  
  
• Property Overloading