User Controls (Active X) - Da Process
in [Visual Basic]
|
From: Eduardo on 9 Sep 2009 03:52 Webbiz escribi�: > On Tue, 08 Sep 2009 20:13:35 -0300, Eduardo <mm(a)mm.com> wrote: > > >> 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). > > I'm going to have to play with ActiveX project before I fully > understand what it means to 'share' using a module in the ActiveX > control itself. It's the same as in an exe project, if you have a public variable in a module, you can read and write to it from anywhere in the project. And about the design decisions, if you want to encapsulate the algorithm of arrangement (and not having it in the form), then go for the option of one Usercontrol for all the indicators. It would be in some way similar to a tabbed control, where you have many tabs in one control. Each tab can have properties, as Caption, etc. And about the array of UDTs, if the data is really fixed, and if you only need that data for the indicators (inside the usercontrol project), store all those values as constants. In that case you don't need to pass that data from the form.
From: Eduardo on 9 Sep 2009 04:10 Eduardo escribi�: > Webbiz escribi�: >> On Tue, 08 Sep 2009 20:13:35 -0300, Eduardo <mm(a)mm.com> wrote: >> >> >>> 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). >> >> I'm going to have to play with ActiveX project before I fully >> understand what it means to 'share' using a module in the ActiveX >> control itself. > > It's the same as in an exe project, if you have a public variable in a > module, you can read and write to it from anywhere in the project. > > And about the design decisions, if you want to encapsulate the algorithm > of arrangement (and not having it in the form), then go for the option > of one Usercontrol for all the indicators. > > It would be in some way similar to a tabbed control, where you have many > tabs in one control. Each tab can have properties, as Caption, etc. > > And about the array of UDTs, if the data is really fixed, and if you > only need that data for the indicators (inside the usercontrol project), > store all those values as constants. > In that case you don't need to pass that data from the form. But what I still think you should manage in the form's code is the size and position of the chart and the "indicators" control (your usercontrol). I think that adding your control (the usercontrol) to the form should not automatically shorten the height of the chart. Because... what are you going to do when the form resizes? I would arrange the two controls in the resize event of the form.
From: Schmidt on 9 Sep 2009 08:21 "Webbiz" <nospam(a)forme.thanks.com> schrieb im Newsbeitrag news:jcjea59l6vapq76ct8fk3dpnsrpem8u2dr(a)4ax.com... > I'm going to have to play with ActiveX project before I fully > understand what it means to 'share' using a module in the > ActiveX control itself. It's about binary encapsulation - the different VB6-Project- Types will create different, freestanding Binaries finally. And a public Var in a *.bas is visible throughout the whole binary (the whole Files... as e.g. *.ctl, *.cls, *.frm in *that* specific project). So, Binaries (*.exe, *.dll, *.ocx) are isolated - now, how do they talk with each other... Over COM-mechanisms --> Class-Interfaces of *Public* Classes (and a Usercontrols *.ctl-File represents a Class too). Since I mentioned, that you can communicate "cross- Binary" only over Public Classes, it becomes clear, that VB6 Std-Exes are "passive" in their functionality, since they may not contain Public Classes (represented in *.ctl and *.cls-Files) - only Private Classes are allowed - so they are only "consumers" of Public Classes (Class- or COM- Interfaces), defined in other Binaries (ActiveX-Dlls or -OCXes). That's usually not a problem, since Std-Exes are normally the "End-Point", where everything is glued together, they don't need to be "active parts", consumable by other Binaries themselfes (if you need that, this is the usecase for ActiveX- Exes, which may/must contain Public Classes/Interfaces). Regarding your problem... Your Usercontrol(-Class) (if you place it in a separate OCX-Project) offers both - a Public Class-Interface (defined in its *.ctl-File) and a visual (container-)representation in the consuming Binary (the Form in your Exe). Now the visual area, which your Control does consume on your hosting Form needs to be dynamically resizable, depending on the count of additional "indicator-stripes", but that does not mean, that you need to include more than one Control on your Form - you can handle the additionally drawn "stripes" in the "mother-control" yourself - and just resize that Parent-Control appropriately. A stripe could be encapsulated (since it is a "visual Part" too) in an additional *Private* *.ctl within your Main- OCX-project. VB6-ProjectGroup Std-Exe-Project Form, consuming ucChart-Ctl (OCX) OCX-Project ucChart (the public Mother-Control) ucStripe (the private "Indicator-Sub-Ctls") IIndicatorInterface cIndicatorImplementation1 cIndicatorImplementation2 ... That's basically the rough layout in terms of "File-Modules". Try to isolate especially the interface between Form and ucChart in a way, that it is as small as possible - the Form should not need to know that much about the internal workings within the OCX-project - it should pass Data, tell the needed Stripe-Type that needs to be shown in addition and maybe receive some Events from your OCX-hosted Control - not more. Everything else (additional Child-Classes, to handle different Stripe-Types - OCX-global *.bas modules) should be hidden and placed within the Chart-OCX- Project. If you need more flexibility especially with your different indicator-stripes, then you should reduce the private Sub-Ctl ucStripe to a more or less dumb "drawing-box", hosted as a Ctl-Array within ucChart - the concrete drawing-code-implementation could go into another separated Binary, an ActiveX-Dll, only responsable to handle the different Indicator-Drawings as a kind of plugin (talking with the OCX-project over a defined Interface). What helps in such cases is, if you concentrate on the "component-design" first, not that much on the concrete implementation. Define a small TestProject-Group with fresh project- types first, which only draws a Sin-Wave for example inside ucChart - and very basic "indicator-stuff" in one or two "stripe-types" - just try to put the interaction together in the first step - then enhance the interfaces to your real needs - and after these interfaces are defined, try to fill-up the structure with your real implementation in the last step. You could post "Step-1" (your ProjectGroup-layout with a very, very basic drawing-implementation) as a link into the group, so that others can take a look at and maybe "reorder" and restructure a bit. Post real code - then there's a better understanding for all others, where you want to end up finally. Olaf
From: Eduardo on 9 Sep 2009 08:42 Tom Shelton escribi�: > On 2009-09-09, Eduardo <mm(a)mm.com> wrote: >> Tom Shelton escribi�: Then in VB6 we have usercontrols and "components" with the same object, the usercontrol. With the property InvisibleAtRuntime the UC can become a component. (based in your explanation, but surely must be other differences) Can you place one of these "components" instances on a form?
From: Larry Serflaten on 9 Sep 2009 09:21
"Webbiz" <nospam(a)forme.thanks.com> wrote > I'm thinking that if the control being added had the brains built-in > to detect the existing controls, it would then make sure the other > indicators adjusted their sizes in order to accomodate the newly > created one. Otherwise, I'd have to write code to do the checking each > time I created a new indicator object, which isn't as cool as having > these guys 'react' appropriately when they are added or deleted. Is > this not possible? It most certainly is possible, but (IMO) its going to be more headache than other paths. To give you an overview, you have group of peers trying to re-arrange themselves, rather than having one section (code path) controlling the group. The trouble arrises when you try to negotiate finite space. Who gets priority? If you add one more, do they all give up some space, and how much? Eventually you have to get them all to agree on who gets what, and you have to do that using code from each of the UC's, Again, IN MY OPINION, having the UC manage the space, and using the classes to draw the images would be far less problematic. > #2 is certainly doable and I understand how nice and clean that would > be. But then this would mean that each time I wanted to do this again > in a new project, I have to copy over all those classes. Not as clean > as just adding a control. Or am I missing something? You are correct, there "could" be more to the project, but as you see below, you could include them in the UC project. You could also put them in their own DLL project, (more mud for the mix!) > >A UC project can contain other (public or private) classes. Your > >UC project could contain the UC, a data class and some number of > >chart and indicator classes. > > Okay, that then answers the issue I raised above. Everything I need > can be contained in the UC project. Since I'm apparently still fuzzy > on the difference between User Control and ActiveX Control I'm going to try to simplify this a bit by saying, when you put a user control in a project by itself, (including any modules or associated classes) and compile it as a separate entity, it becomes an ActiveX control. Its the 'separate project compiled by itself' that makes it different than the user control you would just add in your main project. Because the ActiveX control is a separate entity, it has to be registered, and distributed everywhere your program goes. That is some baggage you can avoid if you just add a UC to a project. When added to a project it gets compiled right along with the main form and all the rest, so there is no other distribution/registering needed. > I looked for that Bar.zip file you referred to and could not find it > during a search on the drive. So I don't think I ever got it. http://www.usinternet.com/users/serflaten/bars.zip This was a quick demo of using classes, it still has a few glitches (minimizing causes an error because I forgot to test for it in the resize code, etc...) but look more at what classes were added and what they accomplish to get the task done. In your case, you would substitute a UC where I have a form. Try to add a new class to the project that draws a border around its alotted space.... ;-) > By taking the suggestion to create a separate class for each > individual indicator, so that I have say 30 of them, what is the best > way to add them to any new project I decide to write? Please don't say > I have to add all 30 of then individually to each project by going to > Project | Add Class Module. That's no fun. > > Is this UC project the way to group them all together into some nice > package that is easily added to any exe project? There are a number of ways to do what you want. But the way I see it, making the User Control the manager and having separate classes to do the drawing would be a fairly simple route to take. You could put the UC in a project by itself, and group the classes in a project by themselves. The UC project would handle the data, and the space assignment for the different classes. The drawing classes would all support a common interface and draw directly on the UC surface. One of the decisions yet to make would be, how does the form indicate what chart/indicator to use? Does it say here is a chart class, use it, or does it tell the UC; I want you to create and use chart type X? One way the form supplies the reference to a class, and the other the UC calls up a specific class based on a request from the form. (Should the classes all sit with the UC?) With that all said, there are some common (GoF) patterns that might address your situation. I am not learned enough about them all to know if there are such patterns that would fit well, but it could be researched.... http://en.wikipedia.org/wiki/Design_Patterns_(book) LFS |