User Controls (Active X) - Da Process
in [Visual Basic]
|
From: Webbiz on 7 Sep 2009 21:00 On Sun, 6 Sep 2009 21:21:15 -0500, "Ralph" <nt_consulting64(a)yahoo.com> wrote: >Ralph wrote: >> >> The Book: "MCSD in a Nutshell", James Foxall, O'Reilly >> > >The complete title is: "MCSD in a Nutshell: The Visual Basic Exams" > Thanks. I found a copy for 1 cent. With shipping, 4 bucks. Look forward to checking it out.
From: Webbiz on 7 Sep 2009 21:13 Boy. I'm glad I'm also learning Visual C# 2008 on the side for some (real?) inheritance. Enjoyed the comments guys. Guess this is one of those subjects where fine points are debated over Starbuck's coffee. I'm at a chapter in one of my books that is dealing with this VB inheritance issue. It pretty much states that you can do the inheritance, but not the nice clean way you can with other OOP environments. Rather than just inheriting Object A's methods, you have to code Object B with a copy of Object A's methods (declare?). It sounds like an inconveniece issue. Webbiz On Mon, 7 Sep 2009 15:17:07 -0500, "Larry Serflaten" <serflaten(a)usinternet.com> wrote: > >"Ralph" <nt_consulting64(a)yahoo.com> wrote > >> Thus IMHO, when someone says ""VB cannot do real inheritance", what they are >> really saying is the VB OOPL cannot support a particular coding construct >> which is true. But unfortunately what they are often also implying with the >> use of the term *real* is that VB is somehow equally unable to provide an OO >> solution. > >OK I now understand what you disagree with. But you when you take things at >face value, the statement it true. If I give you a DLL that exposes a class and >that class has multiple interfaces, you can't inheirit from that class and get all the >other implemented interfaces. A full OOPL would be able to to that. So it >is entirely accurate to say VB doesn't support real inheiritance. It does go >part way with interface inheiritance, but it is a limited implementation. > >What you seem to be saying (using another scenareo) is that you'd disagree >with the statement that VB doesn't support pointers. That also is true, at >face value. But we all know that anything passed by reference is actually >passing a pointer, so you'd say VB does support pointers, just not the >'construct' that most would want to use. (eg; pointer arithmetics). > >There is a difference in what is supported, and what is able to be done. >When someone says something isn't supported, you take a position that >they are saying it can't be done. I'd suggest we stick with face value. If >they say it isn't supported, they mean it isn't supported. If they say it >can't be done, they mean it can't be done.... > ><shrug> >LFS >
From: Webbiz on 7 Sep 2009 21:37 On Sun, 6 Sep 2009 23:18:30 -0500, "Ralph" <nt_consulting64(a)yahoo.com> wrote: >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 > I'm starting to realize that my problem here is having TOO MANY CHOICES!! Ahhhh! With such flexibility comes hangover type symptoms. I'm going to fiddle with Active X controls and such just because I want to learn how to do it. But for a particular task, I'm so confused as to which way to go. Suppose that YOU had this problem, where the data (read-only) can be public. Protecting it is not an issue. And you had a fixed set of indicators that you'd like all wrapped up nice and tight in a single location. And when you wanted to add an indicator panel to your form, where others may or may not already be, you simply code something like "ShowXYInd" (with or without parameters) and it will plop that indicator on the form and adjust the others so they share form space, without you having to have more lines of code to adjust them each time you add or delete one. What would YOU do? Would you have your data in a module (UDT array), or in a class? Why? What would YOU do? Would you create a class to deal with the indicators, so each time you wanted to add an indicator you create an indicator object, so that each are independent? Or would you create a class and only create one object from it, and just call different methods from that object depending on what indicator you want, and somehow manage independance on the screen (form) for add/delete. What would YOU do? Would you copy your .cls file from one project to another when you wanted to reuse these features, thus having a number of copies on your drive (and having to remember you have it)? Or would you create a OCX control that you can attach to your new projects, or a DLL that you can add via reference? The charting project I've been working on for a few years now has been completed for the last couple years. Yet, I would like to add some more indicators to it. Problem is, adding just a single indicator requires hunting down a number of modules/routines to make the addition. I've been writing this program while I was learning the ropes, so I've not made it easy to upgrade/update. So now that it's completed, I'm thinking that if I can find a nice way to add new indicators without having to do this treasure hunt across dozens of modules, somehow encapsulate MOST of the things I need to do with indicators so that in the future when I want to add a new one I can simply find its centralized location and edit/tweak. Wish I could explain it better, but this object oriented programming sounds like the way to go if I can decide on the 'best' approach to do so. Thus all the questions above. Thanks for all your comments guys! Webbiz
From: Ralph on 7 Sep 2009 18:08 "Larry Serflaten" <serflaten(a)usinternet.com> wrote in message news:enNnUf$LKHA.3724(a)TK2MSFTNGP02.phx.gbl... > > "Ralph" <nt_consulting64(a)yahoo.com> wrote > > > Thus IMHO, when someone says ""VB cannot do real inheritance", what they are > > really saying is the VB OOPL cannot support a particular coding construct > > which is true. But unfortunately what they are often also implying with the > > use of the term *real* is that VB is somehow equally unable to provide an OO > > solution. > > OK I now understand what you disagree with. But you when you take things at > face value, the statement it true. If I give you a DLL that exposes a class and > that class has multiple interfaces, you can't inheirit from that class and get all the > other implemented interfaces. A full OOPL would be able to to that. So it > is entirely accurate to say VB doesn't support real inheiritance. It does go > part way with interface inheiritance, but it is a limited implementation. > > What you seem to be saying (using another scenareo) is that you'd disagree > with the statement that VB doesn't support pointers. That also is true, at > face value. But we all know that anything passed by reference is actually > passing a pointer, so you'd say VB does support pointers, just not the > 'construct' that most would want to use. (eg; pointer arithmetics). > > There is a difference in what is supported, and what is able to be done. > When someone says something isn't supported, you take a position that > they are saying it can't be done. I'd suggest we stick with face value. If > they say it isn't supported, they mean it isn't supported. If they say it > can't be done, they mean it can't be done.... > You're close. However, I would never say VB supports 'pointers'. A 'pointer' is a specific datatype which is lacking in VB. VB can work with 'addresses' if required, but while loosely referred to as 'pointers', they are not the same thing. -ralph
From: Eduardo on 8 Sep 2009 04:23
Webbiz escribi�: > On Sun, 6 Sep 2009 23:18:30 -0500, "Ralph" <nt_consulting64(a)yahoo.com> > wrote: Hi, I still don't know exactly what you are doing (I didn't read all your posts), but... I guess you are going to display some data or graph on the form with each one of those objects, so: Why don't you take a straight approach and make the Usercontrol visible at runtime and display the chart in the Usercontrol itself? I would let the arrangement of the multiple instances of the control (the usercontrol) to the programming in the form, as most other controls do. I would make the Usercontrol be in a separate ActiveX project (OCX) to reuse it in any project. And about passing the array of UDTs, I would provide a method in the Usercontrol to add the data, but in this way: Suppose the UDT is: Type UDT1 data1 as Integer data2 as String data3 as long End Type ' And you have the data array Public mUDTArray () as UDT1 (all above in the standard project, the project of the form) So, I would provide a method in the Usercontrol: Public Sub AddFixedData (nData1 as Integer, nData2 as String, nData3 as Long) ' and here you store the data in some way in the Usercontrol project. End Sub So, to pass the data from the form: Dim c as long for c = 0 to Ubound (mUDTArray) UsercontrolInstanceName.AddFixedData (mUDTArray(c).data1, _ mUDTArray(c).data2, mUDTArray(c).data3) Next c |