locked
Generic inheritance on Forms RRS feed

  • Question

  • Hell0. Im afraid Im a bit late, but I found this post searching on the web looking for an answer to my problem, wicht it seems is the same as the original post.

    I have this situation:

    -Cne "Car" class.

    - One BaseForm (of T)

    - Then I've got another InheritedForm :

        Public Class InheritedForm Inherits BaseForm (of Car)

    The result is an error on the Designer saying: "Cannot create an instance of BaseForm[T] because Type.ContainsGenericParameters is true.

    I tried with the solutions you gave, but the problem doesnt fix. I cannot view my InheritedForm<of Car>...

    I dont know if anybody will read my post. But... any idea????



    Tuesday, March 9, 2010 3:39 PM

Answers

  • If I understand your question correctly, someone blogged about a solution here:

    http://madprops.org/blog/Designing-Generic-Forms/

    The code example is in C#, but the concept should be the same for VB.

    Hope this helps.
    www.insteptech.com ; msmvps.com/blogs/deborahk
    We are volunteers and ask only that if we are able to help you, that you mark our reply as your answer. THANKS!
    • Proposed as answer by Vladimir.Ilic Thursday, March 11, 2010 7:16 PM
    • Marked as answer by Jing0 Tuesday, March 16, 2010 12:43 PM
    Tuesday, March 9, 2010 4:05 PM
  • Hi Xomu,

    you are right, that's the limitation of VS IDE because the form loader in design instantiates the base form.
    For the same reason you can not design a form that inherits directly from an abstract form.
    It's a shame though.

    But Deborah's solution looks very applicable to me ... requires only couple of lines of code and a "fake" class ... how does it break your architecture (otherwise from forcing you to add a needless class) ? 
    I can't see any other limitation this approach that would enforce to the application architecture.

    best regards,
    Vladimir
    • Marked as answer by Jing0 Tuesday, March 16, 2010 12:43 PM
    Tuesday, March 9, 2010 11:35 PM

All replies

  • If I understand your question correctly, someone blogged about a solution here:

    http://madprops.org/blog/Designing-Generic-Forms/

    The code example is in C#, but the concept should be the same for VB.

    Hope this helps.
    www.insteptech.com ; msmvps.com/blogs/deborahk
    We are volunteers and ask only that if we are able to help you, that you mark our reply as your answer. THANKS!
    • Proposed as answer by Vladimir.Ilic Thursday, March 11, 2010 7:16 PM
    • Marked as answer by Jing0 Tuesday, March 16, 2010 12:43 PM
    Tuesday, March 9, 2010 4:05 PM
  • Thanks a ot Deb0rahK.

    It seems it works but, it breaks any idea of acrchitecture I could have because It forces you to create one additional class for each form<T>  you want to inherit.

    I suppose thats a limitation of the VS IDE

    Thanks anyway
    Tuesday, March 9, 2010 4:43 PM
  • Hi Xomu,

    you are right, that's the limitation of VS IDE because the form loader in design instantiates the base form.
    For the same reason you can not design a form that inherits directly from an abstract form.
    It's a shame though.

    But Deborah's solution looks very applicable to me ... requires only couple of lines of code and a "fake" class ... how does it break your architecture (otherwise from forcing you to add a needless class) ? 
    I can't see any other limitation this approach that would enforce to the application architecture.

    best regards,
    Vladimir
    • Marked as answer by Jing0 Tuesday, March 16, 2010 12:43 PM
    Tuesday, March 9, 2010 11:35 PM
  • Hello Vladimir.

    I have tried DeboraKs solution and I confirm it worKs. Refering to the architecture, apart from having to create an additional class each form you want to inherit, the final programmer has to know that the IDE of VS has this limitation inheriting "generic forms".

    I mean, obviously its a "solution", understanding as "solution" the fact of avoiding the problem without thinking on anything else.


    Thanks a lot to both of you

    Thursday, March 11, 2010 1:37 PM
  • OK, let's call it a good "work around" for the VS Windows Form designer limitation which I don't think will be resolved in any newer version of VS since MS has turned to WPF and Silverlight.

    And as every work around this one has its drawbacks such as creating an additional "fake" class and developers being informed about it.

    I was wandering if it caused some architectural problems with your application design, because I can't think of any (other then before mentioned).
    It would be beneficial to other community members facing the same problem and reading this thread to know in advance what they would have to give up if the apply it.

    best of luck 
    Thursday, March 11, 2010 3:14 PM
  • Remember,  Windows Forms preceded Generics. 
    The Form Designers were not designed with Generics in mind at all.

    Mark the best replies as answers. "Fooling computers since 1971."
    Thursday, March 11, 2010 3:17 PM
  • Thaks all of you for your replies.

    I have coded that "work around" ;) , and I have arrived to the conclusion that it could be an advantadge to have one class just with basic logic code.

    That fake class could turn to be useful, like a partial class, and in the real form, you would have a couple of events that would call the methods on the other class.


    And about the architecture I could have, it doesnt break any logic rule. Just gives me one more logic layer on that "fake" class.


    So, lets just think positively


    Thanks

    ;)

    Thursday, March 11, 2010 6:02 PM