0

First of all, as I am using VB6, please confine your kind suggestions to techniques applied to VB6.

alt text

I have a set of controls related to each other as the above figure shows. It includes several treeviews, a split bar, a listview, a subform( a usercontrol), and etc.

When I click or change the treeview nodes in the left, the right controls will change their display accordingly, and vice versa.

The data behind the scene is maintained in an Access database.

This set of data management and display is used in several different applications. So I wrote several classes to implement the logic and include these classes modules again and again in my applications.

So I am actually REUSE my classes in a "copy and paste" mode. It works but it have problems. If I make a change in a class, I have to change it in several applications.

These days I am thinking about making them into the so-called ActiveX components. But I am not sure which kind of ActiveX components should I develop to reuse the whole architecture.

In a nutshell, I want to know how can I reuse it more gracefully than just "copy and paste". Below is some ideas or expectation of the new "graceful REUSE", but not confine to them.

(1) I hope it looks like an ActiveX control which has a property page so that I can set some properties of it during design time.

(2) For different applications, the subform in the right may display different information and has different controls and may need extra coding and designing.

(3) Also I may need to code some new behaviour for the treeview and listview for different applications. This requirement make a whole usercontrol for the whole form not suitable. because MSDN said “References to ActiveX controls，should never be returned to client applications。"

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
SlowGrace
  • 15
  • 1
  • 1
  • 7

3 Answers3

2
  • Create a ActiveX DLL (not control)
  • Define a Interface for the form in
    the DLL
  • Move all your logic into one or more class in the DLL and have the routines interact with the form through the interface
  • Implement the Interface in the form
  • One initialization of the app have the form register itself with the ActiveX DLL

This will effectively eliminate copy and paste between the different apps.

For example for my metal cutting application I have a Shape Form, a Shape Screen class, and a bunch of shape classes. Two of the methods of the shape class are DrawScreen which has a parameters of type ShapeScreen, and GetValues which also has a parameter of type ShapeScreen.

DrawScreen uses the method of ShapeScreen to setup the entry screen and Shape Screen setup the Form through the IShapeForm interface. The GetValues uses Shape Screen methods to get the entered shape values which in turns uses the IShapeForm to get the values from the form.

This setup proved useful when we had to develop different shape entry forms in response to customer requests. The new form just implemented the IShapeForm interface and the rest of the software was untouched.

RS Conley
  • 7,196
  • 1
  • 20
  • 37
  • It sounds "graceful", thank you. As I am not quite acquainted with ActiveX dll and the concept of interface. Could you please give some further explanation? ShapeScreen is a class in the dll, and it has an interface called IShapeForm. And where are the shape classes? Are they in your dll also? In short, I just cant make out how to "Implement the Interface in the form "? Does it has anything to do with polymorphism? – SlowGrace Jul 30 '09 at 17:54
  • Would you please give me several lines of codes to illustrate the whole architechture? – SlowGrace Jul 30 '09 at 18:01
  • Or do you mean there is a class called IShapeForm in your dll? All classes in your dll will interact with IShapeForm when they need do so with the real form. And when I use the dll, I shall register a real form to the IShapeForm class. Yes, I guess this is your meaning. – SlowGrace Jul 30 '09 at 18:04
  • Would you please give some peudo-codes to illustrate the below two tasks? (1)"Shape Screen setup the Form through the IShapeForm interface." (2)"uses the IShapeForm to get the values from the form." – SlowGrace Jul 30 '09 at 18:08
  • If you google this, "vb6 activex control tutorial", it might help. – Gutzofter Jul 31 '09 at 04:17
  • Dan Appleman's book *Developing COM/ActiveX components with Visual Basic 6* is excellent. Or just read the VB6 programmer's guide, it actually explains the basics very well. http://msdn.microsoft.com/en-us/library/aa240845(VS.60).aspx – MarkJ Sep 24 '09 at 09:37
0

Maybe I should encapsulate each of the controls to a user control, and then make a virtual ActiveX control (no visual interface) to organize these controls into a united thing.

SlowGrace
  • 15
  • 1
  • 1
  • 7
0

It looks like what you have is a view, domain logic, and data. Your major problem I foresee is item two, it is not static in appearance and logic from app to app. Maybe what you need is two separate controls? Left panel and right panel. The right panel probably is going to implement some type array of controls, since they are not going to be static.

Gutzofter
  • 2,003
  • 23
  • 26