User Controls (Active X) - Da Process
in [Visual Basic]
|
From: Ralph on 6 Sep 2009 23:30 Webbiz wrote: <snipped> > > This is what I want to avoid. It makes the objects dependant on a > outside variable. I was hoping his could have been inherited. I > believe I read that VB6 cannot do real inheritance (bummer). > I should let this go, but it is a weekend... <grin> I get annoyed everytime I hear the expression "VB cannot do *real* inheritance". This comes from two sources. One is the ancient litany of the "Four Pillers of OO" by us object-oriented enthusiasts; whereby we chanted "Abstraction", "Encapsulation", Inheritance", and "Polymorphism"; or sometimes "Abstraction", "Encapsulation", "Modularity", and "Hierarchy"; or sometimes any number of variations depending on what buzzword or word-of-the-day we might want to include. But we always managed to insert some kind of reference to "Inheritance" as one of them. The second comes from the fact that our first exposure to OOPL was often through a language that supported implementation inheritance. That is a code construct where one could take a short-cut in defining new objects that inherited from other objects. eg, Class A Public MethodOne Public MethodTwo Class B Public MethodThree we could say something like this Class C::A::B ... Object obj = New C and end up with an object that would look like we defined it using ... Class C Public MethodOne Public MethodTwo Public MethodThree that is a real niffy little way of re-using a lot of code. Note that this "inheritance" only exists in code, when the program runs there is no object created from Class A or Class B - all we get is a "C" object. VB doesn't support that kind of short-cut. What we need to do using VB is use "Interface" inheritance. (Ironically implemented by using the "Implements" keyword.) A lot more work than what it takes in other OOPLs, but the final result is exactly the same. Interface inheritance makes sense in VB because objects from Classes, Forms, UserControls, etc. use COM protcols - and COM doesn't allow implemetation inheritance either. (but you can 'Implement' or interface inherit from any of them.) Also note that "Interface" inheritance is often less easily done in other OOPLs as it is in VB. More modern OOPLs offer short-cuts for both. [Aside: those of us who have been teaching OO for the last 30 years deeply regret having forced the "Four Pillars" down unsuspecting throats. There are at most only three pillars, and we should never have defined any of them based on an OOPL construction technique. So accept this as a public formal apology. <grin>] -ralph
From: Ralph on 6 Sep 2009 23:33 Ralph wrote: http://books.google.com/books?id=SUDQfzTnctgC&pg=PR1&dq=mcsd+in+a+nutshell#v=onepage&q=&f=false -ralph
From: Eduardo on 6 Sep 2009 23:39 Webbiz escribi�: > On Sun, 06 Sep 2009 20:19:52 -0300, Eduardo <mm(a)mm.com> wrote: > > Yo escribi� inline as well. :-) > > > <snip> > >>> 5. For basic functionality, it needs to be PASSED an array of type >>> DATA_ARRAY (user defined type). >> Use a class and a collection instead. >> Or use one base Class and another Class containing the array of classes >> of the first type (in a property). > > I'm not sure I understand the suggestion above. But I think I'm going > to forego the UDT DATA_ARRAY in module and use Larry's suggestion of a > DATA CLASS that's sole purpose is to hold the data for retrieval. Is > this anything close to what you are talking about above? Yes, I think we are talking about the same idea. >>> 6. If possible, since each instance of this User Control will use the >>> SAME arrDataArray() as DATA_ARRAY, it would be cool if this could be >>> passed once, to the first object created, and then each new object >>> created already has this connection. Possible? >> Yes, put a public variable in a standard module to hold a reference to it. > > This is what I want to avoid. It makes the objects dependant on a > outside variable. As you exposed the problem, that all the classes will need the same array of data and you wanted to supply it just only once at the beginning, I think that would do the work. If you sitiation is just like that, I don't see the problem of having that data in a module. If you are doing all this in an ActiveX project, it is a module in the ActiveX Control project, it's not as module in the client project (exe), so it's not outside the ActiveX project. It's outside the Class module, yes, but you'll need something "outside" anyway if you are going to share data between instances of the class. Of couse, it's a very simple way to accomplish that, there are more sophisticates ways depending on your needs.
From: Eduardo on 6 Sep 2009 23:51 Eduardo escribi�: > Webbiz escribi�: >> On Sun, 06 Sep 2009 20:19:52 -0300, Eduardo <mm(a)mm.com> wrote: >> >> Yo escribi� inline as well. :-) >> >> >> <snip> >> >>>> 5. For basic functionality, it needs to be PASSED an array of type >>>> DATA_ARRAY (user defined type). >>> Use a class and a collection instead. >>> Or use one base Class and another Class containing the array of >>> classes of the first type (in a property). >> >> I'm not sure I understand the suggestion above. But I think I'm going >> to forego the UDT DATA_ARRAY in module and use Larry's suggestion of a >> DATA CLASS that's sole purpose is to hold the data for retrieval. Is >> this anything close to what you are talking about above? > > Yes, I think we are talking about the same idea. Or you could still stay using UDTs if you want to. In that case you'll need to declare the UDT in both projects and use CopyMemory to copy each UDT in the array. I have code for that if you need it.
From: Ralph on 7 Sep 2009 00:18
Webbiz wrote: > On Sun, 06 Sep 2009 20:19:52 -0300, Eduardo <mm(a)mm.com> wrote: > > Yo escribi� inline as well. :-) > > > <snip> > >>> >>> 5. For basic functionality, it needs to be PASSED an array of type >>> DATA_ARRAY (user defined type). >> >> Use a class and a collection instead. >> Or use one base Class and another Class containing the array of >> classes of the first type (in a property). > You could also simply expose the DATA_ARRAY or DATA_Object or Collection through the UserControl. An ActiveX OCX is not limited to one object, nor do all exposed methods and properties have to deal specifically with 'visual' elements. -ralph |