User Controls (Active X) - Da Process
in [Visual Basic]
|
From: Ralph on 8 Sep 2009 10:29 Webbiz wrote: <snipped> > > I'm starting to realize that my problem here is having TOO MANY > CHOICES!! Ahhhh! > Not really. Forget "How" to go about doing something and confine your design activities to "What" it is you want to do. What you "want" is a far shorter list. > 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. > This is an exception to avoiding "How". Since what you want to do is appears to be a UI widget, and you want to encapsulate as much of the functionality as possible - then a UserControl is in your future. > 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? > I would opt for an object, because 1) we know UDTs can be troublesome in some scenarios, whereas an object seldom is, and 2) there really is no such thing as read-only data except for constants. You're picking them up for somewhere and writing them to something. If using a Public/Global UDT - code to create will exist in one place, and code to read will exists in another. With an object we can combine both, and storage within one module. 3) I always opt for an object during development simply because they are more flexible. If I find good reasons later to use a UDT, then replacement is seldom an issue. 3) besides you talk about Indicators as though they are an object, so why dumb them down?
From: Webbiz on 8 Sep 2009 18:35 On Tue, 08 Sep 2009 05:23:54 -0300, Eduardo <mm(a)mm.com> wrote: >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 Okay. So create an OCX control. And instead of passing a UDT array, feed the data right into the control so it becomes the data containter. I have to assume then that only one object (instance) is going to be created using this control. Otherwise, I'd have to feed the data into each new object (instance). Therefore, if only one instance of this control, then all the methods for creating new indicators would have to be run from this one object. There would be no creation or deletion of indicators by creating or deleting objects. One object for all indicators and charts rather than an object for EACH indicator/chart. So making each indicator its own object is not a good idea? Thanks. Webbiz
From: Webbiz on 8 Sep 2009 18:53 On Tue, 8 Sep 2009 09:29:02 -0500, "Ralph" <nt_consulting64(a)yahoo.com> wrote: >> >> What would YOU do? Would you have your data in a module (UDT array), >> or in a class? Why? >> > >I would opt for an object, because >1) we know UDTs can be troublesome in some scenarios, whereas an object >seldom is, and >2) there really is no such thing as read-only data except for constants. >You're picking them up for somewhere and writing them to something. If using >a Public/Global UDT - code to create will exist in one place, and code to >read >will exists in another. With an object we can combine both, and storage >within one module. >3) I always opt for an object during development simply because they are >more flexible. If I find good reasons later to use a UDT, then replacement >is seldom an issue. >3) besides you talk about Indicators as though they are an object, so why >dumb them down? > > There are two things being discussed here. 1. Where should the data reside? 2. How should the indicators be treated? So what I gather from all the posts so far on this that creating a DATA class to hold the data would be best than to create a UDT. Easy to do. DONE. :-) While the data issue seems pretty cut and dry, now comes problem two. I assume that the indicator class will be separate of the data class. What might be best way to deal with the add/deletion of different indicators where each needs to know the existence of others already displayed so as to share form space? 1. Create a single class to accomodate all possible indicators -or- 2. Create a separate class for each new indicator? Q. If I do the data and indicator classes separately, then creating a single OCX appears out of the question. Or am I mistaken? Thanks. Webbiz
From: Eduardo on 8 Sep 2009 19:13 Webbiz escribi�: > Okay. So create an OCX control. And instead of passing a UDT array, > feed the data right into the control so it becomes the data > containter. > > I have to assume then that only one object (instance) is going to be > created using this control. Otherwise, I'd have to feed the data into > each new object (instance). You can feed the data into each instance of the control or you can share the data in a module of the ActiveX project (as I suggested before). > > Therefore, if only one instance of this control, then all the methods > for creating new indicators would have to be run from this one object. > There would be no creation or deletion of indicators by creating or > deleting objects. One object for all indicators and charts rather than > an object for EACH indicator/chart. > > So making each indicator its own object is not a good idea? I think you have to be clear what you want to do with all this. If you are already clear, and if you want my opinion, please describe as simple as possible what is the objetive, I mean, what do you want to achieve. "A problem well stated is a problem half solved" If I knew exactly what the goal is, I could refine my opinion. But without knowing too much, and guessing a little, I told you that I would manage each "indicator" with one Usercontrol instance (or object), and I would use the Usercontrol window for drawing, and I would leave the code for arranging the different instances (or indicators) in the form to the form's code, as it is the more standard way in VB. I think of it as a chart control, that has a window, and you see the chart drawn in that window (the usercontrol in this case). > Thanks. > > Webbiz
From: Eduardo on 8 Sep 2009 19:21
Webbiz escribi�: > Q. If I do the data and indicator classes separately, then creating a > single OCX appears out of the question. Or am I mistaken? No. If you are going to use the Usercontrol in just one exe project, you don't need to place it in an ActiveX project (ocx). In that case you just could have the Usertcontrol in the exe project. Then you can use that Usercontrol in that exe project as many times as you like, in any form of the project. The advantage of putting the Usercontrol in another project, in an ActiveX project (ocx), is that you can use it in any exe project. Usercontrol <> ActiveX project PS: go to menu Project, and see that you can add an Usercontrol to a normal project. |