User Controls (Active X) - Da Process
in [Visual Basic]
|
From: Schmidt on 9 Sep 2009 13:28 "Eduardo" <mm(a)mm.com> schrieb im Newsbeitrag news:h88knf$f64$1(a)aioe.org... > Schmidt escribi�: > > "Larry Serflaten" <serflaten(a)usinternet.com> schrieb im Newsbeitrag > > Guys, do you really think it should get so complex, > using another dll or dlls? > > I would put everything in the OCX. Sure, that would be easier to handle/understand - even easier to handle, if everything remains in the Std-Exe project and is restructured there - Larrys example demonstrates that nicely. On the other hand, it needs some more discipline to write "well-isolated" code within a single project... splitting "App-Topics" into project-private Classes/Ctls already helps there of course, but the real separation of "certain App-Topics" into binary COMponents (standalone Projects) often enforces an even better isolation, an even better (re)thinking of the Class' Interfaces. It ensures (of course depending on the over-all projects CodeSize) faster compile times in the Main-App - and it offers easier potential reusability of Classes and Controls (with a simple mouseclick to add a COM-library Proj.Ref) - also a generally better and more stable IDE-behaviour, especially if such COMponents encapsulate SubClassing- or Timer-stuff or CallBacks or whatever). And with regfree loading a whole lot of potential "Dll-Hell" or Deployment/Registering-issues goes away - all that doesn't worth the effort, if one writes Apps, which compile to an Exe-File below 200kByte or so - and don't differ much from customer to customer (featurewise). But if you have to maintain different versions of an App in parallel, or want to offer and deploy, based on a "flexible featurelist" then you are thankful for each Code-Part, that is "moved out" of the Main-project tree. After all WebBiz knows best, what his App is supposed to do in the future, how large the current CodeVolume is, how flexible e.g. the "Indicator-Drawing" has to be, generally - how often something is (needs to be) changed and in which places these changes happen the most. What the potential customer-count could be, how easy he want's to make the Deployment/Maintenance/Update-cycle, etc... One has to balance the design- and implementation efforts with the potential maintenance/deployment-efforts in the future - each project is different, so there's no general recommendation of course, but VB6 is great in glueing COMponents together, even dynamic dependency- injection is possible, so why not split App-implementations a bit more (but as with everything, "don't overdo it"). Olaf
From: Webbiz on 9 Sep 2009 13:39 On Wed, 09 Sep 2009 05:10:45 -0300, Eduardo <mm(a)mm.com> wrote: >Eduardo escribi�: >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. You make a very good point. What am I going to do if the form resizes, which is very likely. I'm starting to 'see' the issue at hand here. Making these objects aware of the Form events sounds tricky and complicated. I suppose the way to deal with this would be to have in the Form_Resize() a check (container loop) to determine how many of these objects are on the form and to trigger each one's 'resize' method. Depending on the 'tag' of the object, it knows its relative place on the form and sizes accordingly? Good points! Thanks. Webbiz
From: Tom Shelton on 9 Sep 2009 14:22 On 2009-09-09, mayayana <mayaXXyana(a)rcXXn.com> wrote: >>> You realize you're just giving him a table to >> set up his .Net Tupperware party?* He's >> talking about something in .Net that apparently >> has the same name as something in VB, but isn't >> the same thing. >>> > >> They are essentially the same thing. > > Oh? >> >> Differences from what? From VB.CLASSIC UC? >>Yes, there are lots of differences. > Differences as in they have more advanced functionality :) > Ah, you must mean .Net and Tupperware are > essentially the same thing. But can .Net do > a burp-tight seal? :) Ok, they are essentially the same thing in spirit. They just do more. -- Tom Shelton
From: Webbiz on 9 Sep 2009 14:48 On Wed, 9 Sep 2009 08:21:55 -0500, "Larry Serflaten" <serflaten(a)usinternet.com> wrote: > >"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, I'm so glad you asked this question. This is what I was thinking. There is 'basically' only two things 'visually' that this (control?) must do. 1. Draw a stock price chart. or 2. Draw an indicator. The first time an object is created from cCanvas class, it becomes the 'base' or main object. Either the 'index' of 0 would identify it as so, or it's 'tag' could be "Main". Being the only and first object created from cCanvas at this time, it takes up all the available space on the form. Now, if later another object of cCanvas is created, it assumes the 'subordinate' position. We know this by (index?) or (tag?). Let's call ANY subordinate object created from cCanvas as oIndicator. The first and original object created as oChart. Each new oIndicator will be created with a default size. Let's say it is 1/10th the height of the form. When you create another oIndicator, it takes up 1/10th of the 'bottom' of the form, causing the other oIndicators and oChart to adjust. oChart is always the object that gives up its space. oIndicators do not give up their space automatically, only shift their position on the form to allow the new oIndicator to appear below them all. If 1/10th space is not available because oChart is already as short as allowable (and again, we do not shrink height of existing oIndicators), say oChart must not shrink more than 1/10th the form's height as well for safety reasons, a new oIndicator cannot be created and added. Now, if you decide to delete any oIndicator, the other oIndicators will shift down to fill up the opened space, but it is oChart that 'expands' in height to reclaim this newly available space. Bottom line: oChart, the first object created from cCanvas, is the ONLY object of this class that expands or shrinks to accomdate additional objects of cCanvas (oIndicator). And it is identified as being the zero indexed OR the one tagged as "Main" or "Mother" or whatever. There is a property within cCanvas that holds the 'Height' value. This way, IF the user decides to manually change the height of any of these oIndicator objects, then when there is any new oIndicator added or removed and all the others 'adjust' position, they will retain their 'height'. Only oChart will adjust automatically. And of course, oChart can NEVER be deleted as long as there are any oIndicator objects on the form. That's the current 'vision' I have on this. What'cha think? ======================== > >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've got to do some reading on "UC Project" in order to determine if this is a single entity (say, a single file) or a bunch of files. I'm hoping for an easy way to add reuse to new projects. If I have to remember to add a bunch of files, and which ones, I'm cooked. :-b > >> 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.... >;-) Thanks. I have downloaded and unzipped onto drive. I'll check it out shortly. >> 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? By default, when you load the data into the program, it creates the oChart object and displays the default chart type as it knows it is the first object created from this cCanvas class. By way of a 'menu', a user can request an indicator be added to the form. So the menu routine creates a new oIndicator object from cCanvas. It knows it is not the only object existing from cCanvas and thus DOES NOT display a chart. It just takes its place on the form, as oChart resizes to accomodate it. Because the user selected a menu item to add the oIndicator to the form, it also will now call the proper method within oIndicator to tell it what indicator to display. oIndicator.Oscillator(...paramenters...) ....and therefore the proper drawing is displayed within oIndicator. What do you think? >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) I have this book on my shelf. Never read it. Written by Cooper. Didn't know what to do with it when I got it. :-0 Thanks Larry. Webbiz > >LFS > >
From: Karl E. Peterson on 9 Sep 2009 15:00
Eduardo 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. Sort of, yeah. You can't sink events from the parent without setting up a circlejerk, right? > Another one is that you have a design mode where you can set properties, > and also have property pages. I tend to not view that in a very positive light anymore. I like explicitness everywhere now. I don't generally set very many visible control (or form) properties at design-time, either. It just reduces my ability to reuse/recycle the effort. > I think that invisible UCs are useful. But not for much. <g> -- ..NET: It's About Trust! http://vfred.mvps.org |