User Controls (Active X) - Da Process
in [Visual Basic]
|
From: Tom Shelton on 8 Sep 2009 21:54 On 2009-09-09, Eduardo <mm(a)mm.com> wrote: > 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. You're wrong. Stil - it wouldn't be considered good practice. If it doesn't have a ui, then a component is usually more appropriate. -- Tom Shelton
From: Eduardo on 8 Sep 2009 22:08 Tom Shelton escribi�: > On 2009-09-09, Eduardo <mm(a)mm.com> wrote: >> 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. > > You're wrong. So you can have invisible UCs in .Nxt? Do you have the InvisibleAtRuntime property? > Stil - it wouldn't be considered good practice. What is bad about the practice of being able to set properties at design time? Is only good practice to set properties at design time if the object is visible on the screen? Why? > If it doesn't > have a ui, then a component is usually more appropriate. Being a component has nothing to do with being visible or not visible at runtime. It has nothing to do with UIs or not UIs.
From: Tom Shelton on 8 Sep 2009 23:18 On 2009-09-09, Eduardo <mm(a)mm.com> wrote: > Tom Shelton escribi�: >> On 2009-09-09, Eduardo <mm(a)mm.com> wrote: >>> 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. >> >> You're wrong. > > So you can have invisible UCs in .Nxt? Do you have the > InvisibleAtRuntime property? > Ah, I see what you mean. We don't have that through a property, we have that through through the base class. UserControl or Component. Component is a non-ui designable object (like a timer control in vb.classic). UserControl is a graphical control (actually, you don't have to inherit for UserControl for a graphical control... You can create a custom control by inheriting directly from control and then handling it's windows creation parameters, and then overriding the wnd proc)... In other words, we have it - just in a different (and far more flexible) way. > > Stil - it wouldn't be considered good practice. > > What is bad about the practice of being able to set properties at design > time? Nothing. VS.NET has full designer support for components (custom property editors, etc, etc.) > Is only good practice to set properties at design time if the object is > visible on the screen? Why? > No. Not at all. I was refering to the use of UC's for non-graphical components. In .NET that's not really good practice. You could do it. You could force a .NET uc to always be invisible at runtime - just handle the VisibleChanged event and use the DesignMode property to determine if your in runtime or design mode. > > If it doesn't > > have a ui, then a component is usually more appropriate. > > Being a component has nothing to do with being visible or not visible at > runtime. It has nothing to do with UIs or not UIs. Which is what I said. -- Tom Shelton
From: Webbiz on 9 Sep 2009 02:53 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. > >> >> 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. You have a form. When you start the program, a stock market price chart fills that form. You decide to add an indicator that will display BELOW that chart. So when you open the indicator, it creates a pane/canvas below the chart, thus causing the chart to shorten in height so the indicator canvas can have some small space below the chart to draw the indicator. You decide to add another indicator. Same thing. When you open it, the chart canvas AND any already opened indicator canvas will resize to allow for the new indicator to have some space at the bottom of the form. So each time you add an indicator, the previous indicator canvas/panes resize to accomodate the new indicator canvas/pane. When you delete an indicator, again the existing indicator canvas/panes will expand to fill up the empty space. That's basically it. I did describe this same thing in two earlier posts. > >"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). > If I managed the sizing of the different instances (indicators) in the form's code, why bother than with this custom control? I could then just use pictureboxes and put all the indicator methods into a module. But while that will work of course, I'd have to remember all these steps each time I wanted to reuse this setup (place control on form, copy module to new project directory, etc. etc.). If the managing code could be part of the control itself, I would only need to add it to the new project knowing I ported all I need over with that one act of adding a control. That would be nice. And if I needed to make additions, I'd like to know it won't break code elsewhere. I think what I'm going to do at this juncture is to write some example ActiveX controls so I can ask more intelligent questions on this later. Thanks. Webbiz
From: Webbiz on 9 Sep 2009 03:18
On Tue, 8 Sep 2009 19:24:34 -0500, "Larry Serflaten" <serflaten(a)usinternet.com> wrote: > >"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? 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? > >> 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. #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? > >> 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. 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 (yes, I'm still studying the text), I'm not sure how to formulate my question correctly. So I guess I'll hold off on that until I've read a bit more. > >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. 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. > >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) I'm going to have to get back on this about the UC. In my mind right now, I think of the UC as a control you create for the current project as opposed to one I can drop into any new projects later. And I think of the ActiveX control as the one I would need if I want something to drop into other projects later on. The terminology on this isn't clear at this very moment. >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. See. The above isn't clear to me. ActiveX project. UC project. ActiveX control. UC control. >(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. Okay. I don't want to wear out your patience on this so I'll leave it with this last question just for clarification because I'm a bit confused. 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? Thanks for your time. Webbiz > >LFS > > > > > |