DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 2 12 LastLast
Results 1 to 15 of 20

Thread: Inherited Forms Problem

  1. #1
    Join Date
    Dec 2009
    Posts
    15

    Inherited Forms Problem

    I cannot get the designer view of forms to show. The message I'm getting is The Service System.Windows.Forms.Design.IEEventHandlerService already exists in the service container. Parameter Name: serviceType

    I've googled it and others have had this problem but no where could I find an explanation of what it means or how to overcome it. The problem didn't occur until I built in some inherited forms so I assume it is connected to this. Any help or guidance would be appreciated.

  2. #2
    Join Date
    Feb 2004
    Location
    Longueuil, Québec
    Posts
    577
    Strange error, since the IEEventHandlerService is not event documented. I have used inherited forms extensively in the past and never had that one.

    I suspect that something might be corrupted in the files generated by Visual Studio when you compile your application.

    Try the Clean option in the Build menu. This has got me out of "strange errors" a few times.
    Jacques Bourgeois
    JBFI
    http://www3.sympatico.ca/jbfi/homeus.htm

  3. #3
    Join Date
    Dec 2009
    Posts
    15
    Thanks JB.
    I have tried cleaning and building; all to no avail. I decided to take a version of the project before I started building in the inherited forms and to just redo. This time I ran into another problem; one I didn't even have before. I added in one inherited form and then I added another form that I wanted to inherit from the one I just put in. I couldn't get that form to come up on the list of the ones I could choose from. That's really strange. I closed the project and reopened. I closed Visual Studio and reopened. The only thing I didn't do was reboot and I may try that. So, to say I'm having some problems with inherited forms would be an understatement.

    Maybe it's because I'm trying to retrofit and refactor and change things that have been in place for quite a while. Maybe I wouldn't be having these problems if I had just used the inherited forms to start with and built them in as I went along.

    I appreciate your words JB and if you have any other advice/thoughts they would be welcome. If I get anything figured out I'll put something up so that maybe someone else could benefit.

  4. #4
    Join Date
    Feb 2004
    Location
    Longueuil, Québec
    Posts
    577
    Ah, new information there: cascading inheritance. Form2 inherits from Form1. Form3 inherits from Form2. And you have to take into account that as any other form, Form1 also inherits from System.Windows.Forms.Form

    Form -> Form1 -> Form2 -> Form3

    First of all, although you can do that (most of the framework is built that way), it is usually a pain to maintain (I know from experience). It is very hard to know what you can change in Form1 without breaking Form3. And it can be hard to debug Form3 because exceptions in that form might be triggered by some code in Form2 or in Form1.

    The fact that you do not see Form2 when trying to create an inherited form is probably due to the face that the designer that eases you into the process only list the forms that inherits directly from System.Windows.Forms.Form. Analyze what you need to do to determine if you really gain by using cascading inheritance with those forms.

    If you really want to do it, use the interface to make Form3 inherit from Form1. Then go into the generated code, in the line following the declaration of the class, and change the Inherits clause to point to Form2. If you are in Visual Studio 2005 or more, that line is not directly in the code for the Form, but in the partial class that is hidden by default in the Form3.Designer.vb file.

    But expect to have problems displaying Form3 in the Visual Studio designer. This is clearly stated in the documentation... if you happen to find the right page:

    When inheriting forms, keep in mind that issues may arise with regard to event handlers being called twice, because each event is being handled by both the base class and the inherited class. For more information on how to avoid this problem, see Troubleshooting Inherited Event Handlers in Visual Basic .NET.

    If you have 3 forms, that means that each event is called thrice, making the problem even worst.

    And since the development environment must execute code in the 3 forms in order display the third one in design, good luck.

    Visual Inheritance, as Microsoft calls the possibility of seeing a form that inherits from another one in the designer is a great thing that, as far as I know, does not exists in other development environments. But it has its limits, and I think that this is were you got stuck.

    The framework can handle what you are doing, but the IDE cannot.
    Jacques Bourgeois
    JBFI
    http://www3.sympatico.ca/jbfi/homeus.htm

  5. #5
    Join Date
    Dec 2009
    Posts
    15
    Wow, what a great response JB. Thanks so much for taking the time to post that. It helps me a lot.

    You understand my problem perfectly. I was planning cascading those forms at least four, and possibly five deep. I had it working and it was compiling and working fine but then the designed failed to show the forms. I knew that that would not be acceptable because I would want to make a change or two to the design of the forms in the near future.

    And I saw those event handlers being called twice. I thought that looked really wacky and now I understand why.

    I think you're totally right in that this is where I got stuck. The IDE designer is just not up to snuff in this area, if in fact it should be. I did go into the code of the designer.vb and tried to manually put in 'inherits form3' but there was already inherits.systems.forms.form in there and it told me only one inherits was permissible.

    I may give it one more go but much more likely I'm going to forget about this. I've got a million other things that need being done to this code. Maybe, in a year or two, MS will improve things so that these problems won't occur and if I feel a strong inclination; I can try again. But, it's definitely not the end of the world if I never get this particular problem resolved. Not having inherited forms is not a deal killer in any way.

    Thanks so much JB for your excellent post. kj

  6. #6
    Join Date
    Feb 2004
    Location
    Longueuil, Québec
    Posts
    577
    You're welcome. I happen to have a low time on my training schedule in January, so I have time to give more detailed informations. Having to put some concepts in words, specially when it is not in your first language, helps a lot your own understanding.

    As most languages, and for good reasons, VB does not support multiple inheritance (inherithing from 2 classes at the same time).

    Remove the Inherits System.Windows.Forms.Form if you want to inherits from "Form2". Since Form2 inherits from Form, Form 3 automatically catch that when it inherits from Form2.
    Jacques Bourgeois
    JBFI
    http://www3.sympatico.ca/jbfi/homeus.htm

  7. #7
    Join Date
    Dec 2009
    Posts
    15
    JB, your posts are very articulate, exact, and clear. You do better using a second language than I do with my first (and only) language.

    I should have figured out that subsequent forms would inherit the systems.windows.forms.form import from the parent. Thanks for letting me know that. I may come back to trying these multiple inheritances at some point and I'll remember that.

    JB, are you by chance training VB programmers? I'm would like to find a class specificially geared to object oriented programming in VB. That would be fun. If you know of such a class please let me know.

    Thanks for your help. kj

  8. #8
    Join Date
    Feb 2004
    Location
    Longueuil, Québec
    Posts
    577
    I do train VB programmers, this is my main source of revenue. But I do it in the Montreal area and am not aware of the training market outside of the province of Quebec.

    Look for technical training schools geared toward experienced programmers in you area. Around here, these courses are also sometimes offered in colleges, but those are usually given by teachers that have very little experience in the field are are usually good for beginners, not adequate for programmers who already work in the field. The specialized training centres cost more, but the good ones are worth the extra money.

    By the way, I am giving the exact course that you are looking for next week. If you happen to be in Montreal, are OK with a training session given in French, and have a few hundred bucks to spare , I would be glad to have you in my class.
    Jacques Bourgeois
    JBFI
    http://www3.sympatico.ca/jbfi/homeus.htm

  9. #9
    Join Date
    Dec 2009
    Posts
    15
    I wish I could attend your class JB. That would be great. But, the Montreal and French are sorta showstoppers for me. Montreal is a most beautiful city and French a most beautiful language but I am sorely deficient in both travel money and language ability.

    I took VB 101 and 102 here in North Carolina but now I need 201 and 202. I'll keep looking.

    Thanks for all the help today JB and have fun next week in the class. kj

  10. #10
    Join Date
    Jan 2010
    Posts
    33

    Post

    Quote Originally Posted by JBourgeois View Post
    As most languages, and for good reasons, VB does not support multiple inheritance (inherithing from 2 classes at the same time).
    This is true for Java as well.

    Can you tell me the good reasons as to why not?

  11. #11
    Join Date
    Feb 2004
    Location
    Longueuil, Québec
    Posts
    577
    Ouch! I feared that one, you bring me back to my C++ days.

    Why most languages do not permit multiple inheritance?

    Anybody who was around at the beginning of the 90's remembers vaguely the debate about whether multiple inheritance should be included in C++. What anybody remembers precisely is that it was a pretty intense debate. Books were written on the subject.

    Lets try to write a book in a few paragraphs .

    C++ finally won and got multiple inheritance, but almost everybody regretted it afterward. The main problem is that multiple inheritance enables human beings called programmers to make things very complicated when they try to simplify their work. Give them a tool to make things complicated, and they will. And they did.

    At first view, multiple inheritance makes you life easier. Take a class that does part of the job, another that does another part of the job, a third one if needed, and fuse them together to make a fourth that does all the job. Simplifies the work of the programmer, does it?

    Classes are objects (not really true, but OK for the discussion). Take 3 objects: a hammer, a saw and a screwdriver. Find a way to fuse them together. What do you get? A hammer that cuts and is good with screws as much as it is with nails. That is a dream, that is multiple inheritance.

    You will never find a tool like that at Home Depot, because efficient tools are dedicated to one job. You can have a screwdriver that, with different adapters, will drive different kind of screws. But a screwdriver is designed to turn things, not to hit them, and trying to create a tool that does both is possible, but will never be as efficient as having specific tools. Maybe worse, you won't be able to saw while the screwdriver is at the repair shop. And an object that does 3 things is prone to break at least 3 times more often, making you loose the 3 tools at the same time.

    We are talking about object programming, we should be thinking as if we were working with objects. Right?

    Quite philosophical for a discussion about programming, but philosophy is an essential first step when trying to understand object programming.

    Let's get closer to code now.

    Multiple inheritance is almost as useless for code as it is for tools. Seems good at first tought, but bad when you try it. It makes for code that is hard to understand, debug and maintain.

    Lets look at a scenario where multiple inheritance is permitted.

    Class A has a method called Toto (the French equivalent of foo in English).

    Class B also has a method called Toto that does something completely different.

    Class C inherits from both class A and class B.

    So, class C automatically inherits the Toto method... but which one? When you call Toto on class C, does it call Toto in A or in B?

    There has to be a way in the language to define that.

    (I do not know how they ended up doing that in C++, I switched to VB while they were debating. Deciding whether to use = or ==, or + against & takes years in standardized languages, imagine how long it took them to decide whether to accept multiple inheritance or not. That is one of the reasons I have been using VB since 1992, even if it was seen as a "bad" language by the purists at the time... and still today. VB is not "pure", but it keeps pace with the changing world.)

    Now, later, somebody creates a new class E that inherits from C and D. Remember that C has a method called Toto, but the code might come from A or B. D also happens (or not) to have a method called Toto, and if it has one, knows if it actually contains the implementation of that method or inherited it from one of the many classes it inherits from (remember that we are in a scenario where multiple inheritance is possible)

    Class E works wonderfully well, up to the arrival of Windows Z. Suddenly, it gives a "pink screen of death" when you call E.Toto (pink is supposed to replace blue or black in the next version of Windows ).

    Where does the problem come from. Is the Toto method called on E defined in A,B,C,D or E itself? Or in another one that D inherited from but of which we were not aware because of a lack of documentation. Maybe the Toto in C is in fact the Toto from B, while the Toto in D comes from A. Then, you need to know if the Toto in E comes from C or D to know if the problem comes from code that is implemented in A or B.

    Good debugging.

    It can be very difficult if not impossible to correct the problem in E, since it becomes very hard to know where it originated. Even more so since most of the time, you inherit from code that is already compiled and you do not have access to the source code to know who calls who underneath the cover.

    And if you find that my example of mixing 5 classes is far fetched, just think that the simple TextBox, maybe the class that is the most used in all of the universe, is the sixth class in its series : Object -> MarshalByRefObject -> Component -> Control -> TextBoxBase -> TextBox.

    That is a lot of classes inheriting from each other to construct a TextBox that seems so simple.

    But if there is a problem with a property in the TextBox class in the next version of Windows, simply follow the straight path to know where that property is defined or overriden. If each of those classes was inheriting from 3 others, the resolution of the problem would be a lot worse.

    Language designers have worked for years, even decades, to design languages that were free of "spaghetti code", where you have to follow through dozens of GoTo, GoSub and Return to find out what happened in the source code of a program. Object programming was one way out.

    Multiple inheritance just brought back the confusion with a vengeance: in compiled code. And just as pastas nowadays are not always spaghetti and straight, modern code is more complex than when they were trying to clean up the languages. Adding the complexity of multiple inheritance is just too much for it to be worth the trouble.

    So as far as I know, except for a few languages used only by scholars (those that make impossible things in video games), C++ is the only language in use that permits multiple inheritance, and is used only by the kind of programmers that think "since it's there, I must use it".

    There have been a few debates in years past about removing multiple inheritance from the C++ standard, and it is still there because it would break already existing code. And the most common response to that affirmation has been "removing it would only breaks code that is already broken".
    Jacques Bourgeois
    JBFI
    http://www3.sympatico.ca/jbfi/homeus.htm

  12. #12
    Join Date
    Jan 2010
    Posts
    33

    Post

    Can you support any of these claims?

    At scholarly level, you really need to be referencing to something. This can be your own work / research / invention / schema / protocol / algorithm / whatever, but you need to provide evidence that it is true in order to support your claims.

    Without claims substantiated with reasoning and support your argument is void.

  13. #13
    Join Date
    Jan 2010
    Posts
    33

    Post The way I see it

    At current, the way I see it is a bit like this ...

    I am rebuilding a Turbo Charged Mazda MX6, and I want more power at the wheels. The vehicle was originally engineering by a large team of experts to produce 100KW of power. I am just one person arguing with this team of professionals, that this vehicle can reliably deliver 200HP at the wheels with modifications. Will it? I don't know.

    You, on the other hand, are arguing with Microsoft! -- Bill Gates the second richest man in the world. You are only just one person, and no one will listen to you without supported claims.

  14. #14
    Join Date
    Jan 2010
    Posts
    33

    Post A Good Argument

    Here's an example of a "good argument" (unsupported though)

    Multiple inheritance is a desirable trait of OOP (object orientated programming) - because it allows the programmer to be able to reuse generic code.

    Every object has colour, width, height, coordinates and generic parts / martial that are often non specific. Other classes could inherit this super class.

    Objects are useless without methods, accessors and mutators. These 3 specifics are not always object specific. There may be instances where it is plausible to inherit this class too.

    A hammer may use the same method as a saw. The method could be something as simple as randomly blitting the object to the screen. On the other hand, the method might be more specific -- the saw might be used to cut up your dead body, and the hammer might be used to crack your skull. In this instance, because the method is so specific, you really would not want to inherit it. These guys are dead.

  15. #15
    Join Date
    Jan 2010
    Posts
    33

    Post Not for that argument.

    Personally, I don't yearn for VB.NET to be multiple inheritance compatible.

    In fact, I just RUN straight with discrete classes mostly ...

    But I am only one person, and I feel that there would be a time and a place for multiple inheritance in some projects.

Similar Threads

  1. VB 6.0 forms problem
    By deena2209 in forum VB Classic
    Replies: 1
    Last Post: 11-24-2006, 02:24 PM
  2. login problem
    By dbrook007 in forum ASP.NET
    Replies: 0
    Last Post: 11-06-2006, 05:54 AM
  3. Problem with Forms
    By Nik in forum .NET
    Replies: 1
    Last Post: 11-22-2002, 11:41 AM
  4. Reliability Problem
    By elise in forum Java
    Replies: 0
    Last Post: 10-30-2002, 05:40 AM
  5. Problem with Inherited Forms?
    By TK Herman in forum .NET
    Replies: 6
    Last Post: 09-11-2001, 10:14 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center