User Controls (Active X) - Da Process
in [Visual Basic]
|
From: Larry Serflaten on 6 Sep 2009 03:26 "Webbiz" <nospam(a)forme.thanks.com> wrote > The snags I'm dealing with (the holes in my knowledge) is how to make > one object instance know that there are others and how much space it > is taking up. To solve complex problems, you need to reduce them to basic fundamentals and work back from there. You haven't indicated yet, who is responsibe for drawing your charts and indicators. You are trying to make dynamic panels, but haven't revealed if they are to be unique objects (they draw themselves) or just blank panels (drawn by the form). None the less, look at it this way. Your input is a dynamic array of data, and your output is a dynamic list of panels. Lets compre that with another control that has a dynamic display.... If you need a list of text items, you put a Listbox (or similar) on the form and the items are all listed within the control. You can add, delete, and sort the text items, through properties of the control. Relate that to what you want to do. Instead of a dynamic list of text, you are looking to create a dynamic list of panels. What you are trying to do is have all the code that makes a dynamic list, encapsulated within a single control. It appears you are thinking about having two (or more) controls on a form communicate with eachother to negotiate space. But if you look at the intrinsic controls, they don't really talk to eachother when you have several on a form, they are more or less in their own little world. When you create a control array, you get a different object that acts like an array, not like the intrinsic control. Its that array object that you are trying to capture, but yet stuff it into the control. That isn't how the list type controls work, is it? You are looking for a solution to a complex task, for which there may be several possible paths to take. You simply have to do some design work, before you try to write the code. By the sound of it (passing in the data array) you want the control to draw the different charts and panels. If the control needs to draw the charts, then not only does it need to know the data, but is also needs to know what charts are to be drawn on which panels. How are you going to indicate that? If you add code to draw a chart, and code to draw a scale, and code to draw a waveform, and code to draw whatever else, then your control is limited to whatever types of drawing you include in the control. Are you reusing the same types of charts over and over? Just how many different chart or indicator types can you think of, that may be needed? If there are several different types of charts, (do ya think? ;-), would it be better to pass your control a PanelItem, that knows how to draw itself, and let the control just manage where it sits in the list? In that scenareo, you can keep creating panel items, (different charts and indicators that draw themselves on the control) and let the control manage where they sit on the user control. So again, think the project through, all the way, so that you outline the tasks that need to be performed. From that task list, you can then _start_ to think about code structure, where the objects are, what has to be passed back and forth, etc. Then conduct your thought experiments of actually putting the control on a form and using it. What is your form going to do, what is your control going to do, what has to be set at design time, and what at runtime, etc. You can then ask yourself - Is your design complete? Do you need to 'solve a few more problems'? And so on, until you are confident in how it is all going to work. Then start writing your code..... Good luck LFS
From: Ralph on 6 Sep 2009 04:15 Webbiz wrote: > Thanks to all who responded to this thread. > > I figured I'd respond in a single post. Yep, this one. > > There was mention of creating an ActiveX IF you wanted to reuse for > other applications or the web. I'm puzzled by this. If the purpose is > not to reuse, why bother with User Controls to begin with, with the > exception of wanting to improve or change the functionality of an > existing control? > The basic advantage of using a UserControl object is the same as packaging any functionality within an object - abstraction and encapsulation. I like to write code, test it, and forget it, and not worry that some innocent change in one place might impact elsewher. This is tougher to do with code scattered about a Form. Easier when confined to one module. > I've got a task in mind for this User Control experiment. > <snipped> I'll skip your specs, it is sufficient to say Yes - all very doable. You can create four general classes of UserControls 1) Owner-draw controls 2) Aggregate controls 3) Invisible Controls 4) Container Controls The last two appear to be what you are looking for. For example, many 'resize controls are an invisible control you drop on a Form then forget it, it automatically takes care of re-sizing every control on the Form when the Form is resized, the Form itself has no work to do. If you wanted to visually pre-define the space before placing the controls, you might consider a container control. Anyway, I see a lot of reading and fiddling in your future. <grin> -ralph
From: Webbiz on 6 Sep 2009 18:55 On Sun, 6 Sep 2009 02:26:37 -0500, "Larry Serflaten" <serflaten(a)usinternet.com> wrote: > > >"Webbiz" <nospam(a)forme.thanks.com> wrote > >> The snags I'm dealing with (the holes in my knowledge) is how to make >> one object instance know that there are others and how much space it >> is taking up. > >To solve complex problems, you need to reduce them to basic fundamentals >and work back from there. > >You haven't indicated yet, who is responsibe for drawing your charts and >indicators. You are trying to make dynamic panels, but haven't revealed >if they are to be unique objects (they draw themselves) or just blank >panels (drawn by the form). Good questions. I wasn't sure what to disclose. Suppose that the object now has access to the data array. Suppose the object has several methods, each that displays the data in the array in different ways. There is a BarChart method, Candlestick method, etc. The default method is to draw a BarChart, and to use just the last 150 data records from the UDT DataArray. If the user does something to initiate a SCROLL, this is sent to the object and it responds by redrawing the chart, but shifted, so it looks like it scrolled. Now the user decides he wants to add an indicator. So another instance of the object is created, it automatically takes up some space at the bottom of the form, causing the existing object(s) to shrink up to fit it. This time, however, a different method is ran from this object following its creation, to draw some sort of indicator based on the data indexed in DataArray. Due to scrolling, the new object will need to know the Start and Stop index being used in DataArray for display, so it will match up. If the object is deleted, the drawing area goes away and the existing objects will up the space left open. In time, I'll want to add some responses to events that will allow changing the order of these displays, or the individual height, with the remaining objects responding by shrinking or expanding their height to adjust for the change. That's what I'm striving for. > >None the less, look at it this way. Your input is a dynamic array of >data, and your output is a dynamic list of panels. Wouldn't by input in the above case be static? An array of a fixed number of records? >Lets compre that with another control that has a dynamic display.... > >If you need a list of text items, you put a Listbox (or similar) on the form >and the items are all listed within the control. You can add, delete, and >sort the text items, through properties of the control. > >Relate that to what you want to do. Instead of a dynamic list of text, >you are looking to create a dynamic list of panels. What you are trying to >do is have all the code that makes a dynamic list, encapsulated within a >single control. It appears you are thinking about having two (or more) >controls on a form communicate with eachother to negotiate space. >But if you look at the intrinsic controls, they don't really talk to eachother >when you have several on a form, they are more or less in their own >little world. When you create a control array, you get a different object >that acts like an array, not like the intrinsic control. Its that array object that >you are trying to capture, but yet stuff it into the control. That isn't how the >list type controls work, is it? > >You are looking for a solution to a complex task, for which there may be >several possible paths to take. You simply have to do some design work, >before you try to write the code. > >By the sound of it (passing in the data array) you want the control to >draw the different charts and panels. If the control needs to draw the charts, >then not only does it need to know the data, but is also needs to know what >charts are to be drawn on which panels. How are you going to indicate >that? A call to the method in charge of handling that. > If you add code to draw a chart, and code to draw a scale, and code >to draw a waveform, and code to draw whatever else, then your control >is limited to whatever types of drawing you include in the control. Are you >reusing the same types of charts over and over? Yes! That is exactly what I wish to do. There is a finite number of different chart types I would like it to handle, and a finite number of indicator drawing types. If later I wish to add a new one later, I'll just add a new method to the mix. Eventually, however, it will have its total compliment. There isn't any unknown things that need to be drawn. All prefigured only. Just how many different >chart or indicator types can you think of, that may be needed? > Right now, I'm looking at 5 charting types. As for indicators, it can be as many as say 20. >If there are several different types of charts, (do ya think? ;-), would it be >better to pass your control a PanelItem, that knows how to draw itself, and >let the control just manage where it sits in the list? In that scenareo, you >can keep creating panel items, (different charts and indicators that draw >themselves on the control) and let the control manage where they sit on >the user control. That's more external interaction that the control would be dependant on than what I'd like to see. I'm thinking that after a whole lot of time goes by and I've not used the control, but want to today, I'd have to remember all these different things I have to add to the form or send to the control, etc. Instead, it seems that if all I had to do is give it a dataarray and then just select methods built into the object with nice descriptive names, it would make it easy to have the foundation of a new charting application up quickly, where I can then add to the program to make it unique and new. >So again, think the project through, all the way, so that you outline the tasks >that need to be performed. From that task list, you can then _start_ to >think about code structure, where the objects are, what has to be passed >back and forth, etc. Then conduct your thought experiments of actually >putting the control on a form and using it. What is your form going to do, >what is your control going to do, what has to be set at design time, and >what at runtime, etc. You can then ask yourself - Is your design complete? >Do you need to 'solve a few more problems'? And so on, until you >are confident in how it is all going to work. Then start writing your >code..... Here's the deal on that Larry. Without having the big picture as to what all VB6 will allow me to do, I tend to limit the creativity of the application, or make it less compact, efficient or resuable. My limited experience limits my mental design. When someone here says "you can try and do this...", a light goes on in my head and then NEW POSSIBILITIES start to form. Then I am a step closer to my ideal design. What I described at the beginning of this message is basically what I'd like to do. How to do it is another thing. As you said, the objects exist separately. So then, this moves me to my question as to whether objects from the same class can be made to KNOW what each are doing as well as to REACT to them in some way (to make the auto sizing work, for example)? Thank you! Webbiz > >Good luck >LFS > > > >
From: Webbiz on 6 Sep 2009 19:00 On Sun, 6 Sep 2009 03:15:34 -0500, "Ralph" <nt_consulting64(a)yahoo.com> wrote: >I'll skip your specs, it is sufficient to say Yes - all very doable. > >You can create four general classes of UserControls >1) Owner-draw controls >2) Aggregate controls >3) Invisible Controls >4) Container Controls > >The last two appear to be what you are looking for. >For example, many 'resize controls are an invisible control you drop on a >Form then forget it, it automatically takes care of re-sizing every control >on the Form when the Form is resized, the Form itself has no work to do. >If you wanted to visually pre-define the space before placing the controls, >you might consider a container control. > >Anyway, I see a lot of reading and fiddling in your future. <grin> > >-ralph > I've got several VB6 books. They don't cover the same things. Do you know a great source of information for beginners that has a lot of focus on the above you discuss? A recommended book perhaps that is as easy to follow as VB6 for Dummies or VB6 in Plain English (easiest reads that don't make your eyes go cross)? Thanks! Webbiz
From: Eduardo on 6 Sep 2009 19:19
My answer is inline: Webbiz escribi�: > Thanks to all who responded to this thread. > > I figured I'd respond in a single post. Yep, this one. > > There was mention of creating an ActiveX IF you wanted to reuse for > other applications or the web. I'm puzzled by this. If the purpose is > not to reuse, why bother with User Controls to begin with, with the > exception of wanting to improve or change the functionality of an > existing control? > > I've got a task in mind for this User Control experiment. > > Before, I was using PictureBoxes. But someone suggested that with a > User Control there is no need. So I'm proceding on that basis. > > Details: > > 1. To be able to reuse this for more than one program. > > 2. To easily drop this into a new project and start using it right > away. Then create a separate project, an ActiveX Control rather that using the usercontrol inside the standard projects. For testing purposes, while you are working with the Usercontrol, add a new standard project (and so you create a project group) to test it. Menu File, Add project. Then go to the right panel where there is the list of projects, forms, modules, etc, and right click on the standard project and set it as the Start Up project. > > 3. Rather than being a visible control on the form, it simply provides > me with the ability to create instances (objects) from it that are > each independant of the other, YET are aware of the other in order to > share form space. Set Usercontrols's property InvisibleAtRuntime to True. > > 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). > > 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. > The snags I'm dealing with (the holes in my knowledge) is how to make > one object instance know that there are others and how much space it > is taking up. Also, how to adjust the others to make room for the new > one. Each of these objects will take up some form space for the > purpose of drawing lines, waves, etc. > > Example: Say I create a User Control called Canvas. > > I plop this baby on my form so that it becomes part of my new project. > > I then create a new object from this control (I'm assuming you can do > this). > > When I create the object, it notes that it's the only instance of the > UC and takes up all the space of the form for drawing. > > I then create another object from this control. It also checks and > finds there is one other. So it calculates what space it wants on the > form and adjusts the drawing area of the first object. Then it claims > what's left. > > Each time a new object is created, the same thing happens. Anytime one > of these objects is destroyed, the others reclaim the newly opened > space. From within your Usercontrol you can check if there are other instances of it in the form. dim ctl as control For Each ctl in Parent.Controls If TypeName (ctl) = TypeName(Me) Then ' Here you have one instance If ctl is Me then ' It is this one End If End If Next ctl > Please tell me I'm not on drugs thinking this is possible (we'll, > perhaps I am anyway. ;) > > > It just seems like a pretty cool thing to be able to just drop one of > these babies into a new project and as soon as you create an object > from it it is ready to display your line drawings. And you create > another object and it automatically shares form space. I'd think this > would simplify the creation of a charting program that the user can > add new indicator windows, delete them when no longer in use, and have > each contain their own type of indicator/drawing. I'm telling you how to accomplish what you say you want to do, but I don't fully understand the whole of what you are doing, so I don't know if it's the best approach. |