Help w/Decision - embedded controls vs inherited forms
I have a VB6 app which contains an architecture that I am very proud of and has proven to be very extensible. I now need to take that piece of the app over to winforms and am trying to decide whether to continue using this architecture or use some new tools that the framework has given me.
Here's the deal.
The app is for a lab. They do many many tests. Many different TYPES of tests. So I have one
form that acts as a container for many different activex controls that I embed into the form
at runtime as needed. So if the user has chosen TestA, the code embeds mycontrols.TESTA nto frmMainLab. The main form has all of the common controls and functionality. The activex
controls have all of the controls and functionality that are specific to that control.
In addition, the data is all stored in one sql server table. I have designed it so that I can choose from a series of char fields, a series of numeric fields and a series of memo fields to store the data that is entered into the controls. THe memo fields are used to persist any grid data. (That is another very cool thing I figured out a bunch of years ago that still makes me grin.)
So this all works beautifully. Whenever we need to add a new test to the pot, all I need to do is create a new control which takes anywhere from 15 min to 1 1/2 hours tops. After that, the application knows that it exists and is able to embed it and use it.
It works so very well!
And now...drum roll... I have to do a new app for the tablet pc that will be another means for the lab technicians to do the same data entry. I am definitely going to do it in .net because we want to use the UI that I have already done a bunch of their new apps in.
However, I am looking at this archtecture and also thinking about the great presentation on Windows Forms Inheritence that Ken Getz gave to our user group earlier this week. I know that I can still get all of the reusability, etc if I go with inherited forms. And I will have a large collection of forms instead of the same number of user controls.
But I still believe that the embedded controls design is the best for this, even in the .net world.
A few reasons:
1) I could actually just put a wrapper around those existing controls and use them in the .net app. Although this worries me. I feel like it has to be all .net to be "clean and pure". But, I
could do that and not have to re-write all of those pieces in .net. I actually think I want someone to convince me to go this route! (Though I have no problem rewriting the controls.
More hands on .net coding is good good good.) But of course, I would be doing my client a
disservice (or working a lot of unbillable hours) if I don't leverage all of the work I have already done. OK I'm almost convinced.
2) I like that the controls are contained in a separate library. I just modify and redeploy that instead of the exe. THis is clean and tight to me.
3) I think that in this case, the inherited forms will actually add a lot of overhead.
There might be something else in the framework that I am not looking at. A third or even
fourth option.
So if anyone has any feedback that is more solid than the instinct that I am going on , I
would really be interested in hearing it.
Thanks
Julie
Hi Julia, I'm a little confused. What advantage would inheritance give you in your case? As I understand it from reading your post, you are displaying custom controls at the click of a button for testing, correct? Can you explain exactly what benefits you think you'd be getting from inheritance...again, I'm just a little slow! ;)
And yes, inheritance does come at a cost. One or two levels of inheritance doesn't usually give you that much overhead though. Also, one of the really good reasons to use it, is to reuse functionality (and visual design too) in a simple way. Oh yah, and also, I'm not sure if this helps you any, but whether it's a Form or a UserControl, they both can take advantage of inheritance. Any Class can and any Class that inherits from Control (which both Form and UserControl do) can take advantage of visual inheritance.
That's cool that you got to see, Ken speak. I'm sure it was great! :)
Erik-
My point exactly! I don't see an advantage with inheritence and am trying to make sure that I am not missing something here.
I know inheritence would enable me to have a master form and then create other forms with that as it's base. I am not talking about multiple levels of inheritence. Just one base form and many children. It is an option that I didn't have in VB6, which is how I came up with my BRILLIANT method!! <g>
re: your other point, just fyi in my particular case, there is no point to inherit within the user controls. They are completely unique.
My inclination/intuition is to stick with the embedded controls.
I was hoping someone would be able to say:
"yes you are right. And here is/are the exact reason(s) why the embedded controls are better"
or
"ah, but Julie, you are ignoring x y and z which are the reasons that inheritence is clearly the way to go."
I let Ken know I would be posting this so it will be interesting (for hopefully more than myself) to see what he has to say.
julie
I re-read your original post a few times and I just can't see any reason you'd want to use inheritance. At least Form inheritance.
If I were you, I would do everything in my power to *not* rewrite the existing ActiveX controls. This seems like the ideal scenario to use the built in support for ActiveX controls.
One catch though, there is no way to create a Windows Forms ActiveX wrapper at runtime, a wrapper needs to be generated by the VS.NET designer or by the aximp.exe command line tool.
To port the app you have described, I would:
1. Create a Windows Forms Form that has the equivilent functionality of your VB6 main form.
2. Run aximp.exe over all of your ActiveX controls to generate the appropriate wrapper classes.
3. Test all the exisitng controls in the new Form to make sure everything that used to work still does.
Make sense?
- mike
Just another note, even though this is resolved:
We kind of did a similar thing with an app we developed. Basically we have an assembly defined for each of multiple "modules" in our application. We have a base panel class that is in our main application assembly. We wrote panels in all our module assemblies that inherited from our base panel in our main assembly. (We did have some functionality on each panel we wanted to be able to expose in the base class, like Print, Search, etc... which may not apply to you). We then basically designed the app to load up any assemblies defined in the app.config and pull the panel types out of them and build a menu dynamically so the user could click anything in the menu and the app woudl load the panel out of the assembly and place it in our apps main form. It worked out very nicely being able to add assemblies at any time and being able to consume them (with the app.config change of course, you could always just save the assembly locations and panel type names in a db and have immediate access to them). This is basically your "Brilliant" architectures implementation in .net, and it would alleviate the need for the activex wrappers, etc...
Paul Tyng
