User Controls (Active X) - Da Process
in [Visual Basic]
|
From: Karl E. Peterson on 8 Sep 2009 20:18 Ralph wrote: > "Good artists copy. Great artist steal", Pablo Picasso Hey, you stole that from my old website! <vbg> -- ..NET: It's About Trust! http://vfred.mvps.org
From: Larry Serflaten on 8 Sep 2009 20:24 "Webbiz" <nospam(a)forme.thanks.com> wrote > 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? Step 1. Remove that thought from your head. There's no need to force a tunnel vision of the issue. Keep an open mind to all possibilities, etc... Who says each needs to know about the others? Does the command button know you've added a textbox to the form? > 1. Create a single class to accomodate all possible indicators -or- > > 2. Create a separate class for each new indicator? I was never fond of the 'kitchen sink' approach. I prefer a more modular design, so I favor #2. > Q. If I do the data and indicator classes separately, then creating a > single OCX appears out of the question. Or am I mistaken? 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. When I need to design some functionality, I generally take a look at what else out there looks similar to what I need to do. Taking note of the good and the bad, I get an idea of what I want to support. In your case, take a look a the Align property of a picturebox. Add a few pictureboxes to a form, and set their Align properties. Do the pictureboxes talk to eachother to accomplish what they do, or, would you think the form actually handles their placement? Also realize that there are no 'objects' on the screen, its _all_ just so many pixels made to look like separate windows and controls and whatnot. What makes a difference is how you handle them in code. What I suggested in my Bars example (in the previous discussion from some time ago) was that you use an interface (class) to define what a chart is and an event sync (class) to handle user input. With an interface defined, your UC can communicate with every type of chart/indicator class in the same way. You can keep creating new charts and indicators, and as long as they support the interface, the UC will be able to manage them. In that scenareo, the UC module handles the creation and positioning of the chart classes, and the class modules handle the drawing. Once you get the positioning code done (in the UC module) you shouldn't need to mess with it again. When you need a new indicator you create a class that draws the image, and supports the common interface. As I and others have suggested, you could draw right on the User Control, so that all your charts and indicators could be more simply controlled in any form code that has to position them. (It only needs to position the UC) About the only decision that might need more consideration is, should the chart and indicator classes reside in the UC project, or should they be kept separate? If you put them in the UC project then adding classes to the UC project requires a re-compile of the project, potentially breaking earlier code that uses the UC. (You'd have to be careful to keep compatibility). If they are outside the UC then the UC never changes (no compatibility issues) but you need to keep a library of indicator classes that need to be added to any of your other projects. A bit like adding controls to the VB toolbox. LFS
From: Karl E. Peterson on 8 Sep 2009 20:26 Webbiz wrote: > On Sat, 5 Sep 2009 18:21:01 -0700, Bee <Bee(a)discussions.microsoft.com> > wrote: > >>2 cents from an old guy. >>Only use a user control if you have to, i.e. need the same functionality in >>multiple place in the same project. The learning curve is high and there are >>got-yahs. > > Hello Bee. > > Don't know if you read my long-winded "wish list" for this control. I haven't, but have just skimmed the thread. > But I think that is what I need it for. > > Now I'm assuming we are not talking about plopping multiple controls > on the form. I just want the functionality to be 'duplicated' by > making new instances of the object or deleting them. They all will > need the same data array to do their job, and they all will need the > same routines to draw on their individual canvas area of the form. > > Does this quality in your opinion? I'm not hearing that you need to include a user-interface with the encapsulated functionality. If that's the case, the bar for using a UC rather than your dirt-standard CLS is pretty darned high, IMO. Used to be, there was a real purpose for invisible UCs. Users were too dumb to create a class instance in code, and this was an easy way to provide them with functionality. And really, that remains pretty much *almost* the only rationalization for writing a zero-UI UC to this day. (I qualify that just a bit, because there are features - such as AsyncDownload - that are only available within a UC.) -- ..NET: It's About Trust! http://vfred.mvps.org
From: Eduardo on 8 Sep 2009 21:31 Karl E. Peterson escribi�: > I'm not hearing that you need to include a user-interface with the encapsulated > functionality. If that's the case, the bar for using a UC rather than your > dirt-standard CLS is pretty darned high, IMO. Used to be, there was a real purpose > for invisible UCs. Users were too dumb to create a class instance in code, and this > was an easy way to provide them with functionality. And really, that remains pretty > much *almost* the only rationalization for writing a zero-UI UC to this day. > > (I qualify that just a bit, because there are features - such as AsyncDownload - > that are only available within a UC.) Another difference is that you have a reference to the form without having to set it to a property. Another one is that you have a design mode where you can set properties, and also have property pages. I think that invisible UCs are useful. I believe that .Nxt don't support invisible UCs any more (correct me if I'm wrong), so you lose that features. It's not good.
From: Eduardo on 8 Sep 2009 21:49
Karl E. Peterson escribi�: > Ralph wrote: >> "Good artists copy. Great artist steal", Pablo Picasso > > Hey, you stole that from my old website! <vbg> Because he's an artist |