Inheriting FpSpread / Visual Studio Error

Posted by: relizon1 on 8 September 2017, 1:06 pm EST

  • Posted 8 September 2017, 1:06 pm EST

    I tried to add some custom functionality to the grid by inheriting from it but unfortunately, I am getting errors. Below is the simple code I am using:


    ---------------------------------------


    class MyGrid : FpSpread
    {
        public MyGrid() : base()
        {
            SheetView defaultSheet = new SheetView();
            this.Sheets.Add(defaultSheet);
        }
    }


    ---------------------------------------


    As soon as you try to drop the gird on the form you get a Visual Studio error and the whole eviroment shoots donw.


    As far as I can tell, the problem happens when I try to add the SheetView into the spread control.


    What is the problem?


    Thank you.

  • Replied 8 September 2017, 1:06 pm EST

    Hello,


    Trying to make a subclassed control for use at design time is not recommended.  Subclassed controls are good solutions for extending the Spread's public interface with new run-time functionality, but trying to extend its design time functionality is much harder because most of the classes that Spread uses for design time support are not public.  You would need to basically reimplement anything you wanted to override or change in the design time support for the control. 


    You would need to implement the ISupportInitialize.EndEdit method to put your code for changes to the Spread control.

  • Replied 8 September 2017, 1:06 pm EST

    I don’t get it, why would adding a new SheetView in the controls constructor be any different than adding a SheetView during regular runtime?


    Why exactly is trying to make a subclassed control for use at design time is not recommended? Looks to me that you guys decided to create a new SheetView *automatically* every time someone drops the grid on a form so that the grid looks nice when it’s first dropped on the form. I would imaging that that it the reason why I having all these problems, is it?


    I am trying to create a custom grid control that someone can drop on their form and have it all configured and ready to go as soon as the grid is dropped on the form. This is not unreasonable at all. This is the perfect way to achieve consistency among all users of this specialized grid.


    Is there another event that I can trap or method that I can override where I can achieve what I am looking to do with ease??


    Thanks.

  • Replied 8 September 2017, 1:06 pm EST

    New FpSpread controls are always created with am empty collection of sheets so that the code in the InitializeComponent method can create and add the sheets.  When you drop the control on a form at design time, it starts out empty, and the ControlDesigner for FpSpread (which is an internal class) adds a new Sheet to the control in its InitializeNewComponent method override, so that the new control starts out with a default sheet.  Then, when the form is serialized to code, the CodeDomSerializer classes for the various classes in the object model for FpSpread (which are also internal classes) render code in the InitializeComponent method that will create and add the sheet(s) to the control.

    The easiest way to make a pre-configured template FpSpread is to use the Spread Designer tool to set up the workbook the way you want it, and then save it to XML.  Then you can load that XML into new instances of FpSpread at run-time with one line of code.

    To do what you describe, making an inherited control that comes up that way initially, would be much harder to do.  You could create a ControlDesigner for your subclass, and implement your code to create your default sheet(s) in its InitializeNewComponent method.  The hard part is keeping the other design time functionality working -- you would need to also override the other methods in ControlDesigner with code that calls into the FpSpread's ControlDesigner class, and since that is not public, that requires using reflection.

    If you do not mind losing all of the Spread's design time functionality, and really want to limit the user so that they cannot change any of the formatting or properties in the FpSpread, then you can create a UserControl that just contains a FpSpread set up the way you want, and make it fill the UserControl.  You would need to add whatever properties and methods you want exposed at design time on your UserControl, but you would have control over how the FpSpread gets initialized in a new instance of your UserControl.  It would be very simple to make a UserControl containing a FpSpread that has a string property that specifies the path of filename of a Spread XML file to use as a template -- the property set method can call the FpSpread.Open method with that file.
  • Replied 8 September 2017, 1:06 pm EST

    Ok, since I really have no idea of all the nasty details that go on when a control (farpoint control or any other) is dropped on a windows form, I am not going to go there because I would first need to understand that process before I can start asking question.


    When I fist started working on this project I create a UserControl just like you suggested on the last paragraph, but then I changed it to have it they way I have it now.


    Creating a user control means that I have to map all of the methods/properties from my custom control to the hosted grid, this is overkill since all I really want is to achieve some initial state and then have the users of the grid perform some additional formatting.


    Oh well, such is life.


    Thanks.

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels